Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/v/0.38.0/llms.txt
Full corpus: https://docs.registrystack.org/v/0.38.0/llms-full.txt

# Security self-assessment

> A CNCF TAG Security-style self-assessment for Registry Stack.

This is a CNCF TAG Security-style self-assessment. Registry Stack is not
currently a CNCF project, is not in the CNCF donation track, and has not been
reviewed by CNCF TAG Security. This document is maintainer self-assessment
against that public guide.

## Metadata

| Field | Value |
| --- | --- |
| Project | Registry Stack |
| Repository | [registrystack/registry-stack](https://github.com/registrystack/registry-stack) |
| Assessment type | Maintainer self-assessment |
| Review history | No public review ledger yet |
| Last reviewed | 2026-08-03 |

## Overview

Registry Stack helps operators publish governed registry-facing services over
data they already hold. The two main runtime patterns are protected registry
APIs through Registry Relay and signed minimum-disclosure assertions through
Evidence Gateway.

The public architecture, boundary model, and product roles are documented in
[Architecture](../../explanation/architecture/) and
[Boundaries and map](../../map/boundaries-and-map/). The cross-cutting security
requirements are documented in [RS-SEC-G](../../spec/rs-sec-g/).

## Self-assessment use

This assessment helps reviewers find public evidence quickly. It is not a
certification, penetration test, production deployment proof, or CNCF review.
The hosted lab is a synthetic-data behavior demo and does not prove production
operational assurance.

## Security functions and features

Registry Stack security behavior is split between software guarantees and
operator responsibilities.

Software guarantees include:

- OIDC token validation through shared platform primitives.
- Request-scope authorization and policy checks before protected reads or
  governed evidence evaluation.
- Disclosure controls that can return narrower evidence instead of source
  records.
- Signed, stateless Evidence Gateway assertions, serialized as a flattened JWS or, under
  Evidence Gateway's frozen profile, as an SD-JWT VC response.
- Minimized, fail-closed audit records emitted by runtime services, for the operator to ship to
  append-only storage.
- Release workflow support for an authenticated checksum chain, exact image
  digests, a consolidated SPDX SBOM, image-specific SBOM and Grype evidence,
  and attestations for the exact candidate manifest and bundle.

Operator responsibilities include:

- choosing and protecting signing-key storage;
- configuring trusted issuers, audiences, scopes, and peer relationships;
- retaining audit records in storage appropriate for the deployment's integrity
  and retention needs;
- reviewing vulnerability scan results and deployment-specific exposure before
  production use.

## Project compliance

Registry Stack documents standards alignment in [Standards](../../reference/standards/) and
the public spec register in [Specifications](../../spec/). These pages describe
implementation evidence and known gaps; they do not claim legal compliance by
themselves.

## Secure development practices

Development evidence:

- CI runs Rust format, workspace checks, workspace tests, release-tool tests, lab
  source-model checks, and docs checks.
- OpenSSF Scorecard runs on its schedule or by manual dispatch and publishes
  posture results as hygiene signals.
- Release manifests pin source refs and external inputs.
- Release validation checks source tag matching, source-ref ancestry, default
  branch reachability, and manifest consistency.
- Current GitHub Release payloads are covered by one keyless Sigstore-signed
  `SHA256SUMS` file. The protected-main publication workflow verifies the
  candidate attestations before promotion. The public verification process is documented in
  [`release/VERIFY.md`](https://github.com/registrystack/registry-stack/blob/main/release/VERIFY.md).

Known release-integrity gaps:

- OCI image signatures are not yet published for root monorepo releases.
- Ordinary Beta releases do not publish a second generic SLSA provenance
  asset. Candidate attestations and the signed checksum closure cover the
  current Beta provenance boundary.
- Public claims about signing are scoped to the release asset or product
  surface that actually performs signing.

## Security issue resolution

Report vulnerabilities through
[`SECURITY.md`](https://github.com/registrystack/registry-stack/blob/main/SECURITY.md).
The project publishes public review-ledger entries only when they are fixed and
public, or when an open theme is already publicly inferable and approved for
publication by the security reviewer.

## Appendix

Primary public evidence:

- [RS-SEC-G](../../spec/rs-sec-g/)
- [Contracts](../../reference/contracts/)
- [OpenSSF evidence](../openssf-evidence/)
- [Evidence Gateway API reference](../../reference/apis/registry-evidence/)
- [RS-PR-RELAY](../../spec/rs-pr-relay/), the normative Relay protocol
  specification. Relay generates its own OpenAPI description per deployment
  from that deployment's registry contract, so the site publishes no
  product-level Relay API reference.
- GitHub Release assets, with signed checksums, consolidated SPDX SBOM,
  security evidence, release manifest, and candidate attestations
- [Release verification](https://github.com/registrystack/registry-stack/blob/main/release/VERIFY.md)