Security self-assessment
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
Section titled “Metadata”| Field | Value |
|---|---|
| Project | Registry Stack |
| Repository | registrystack/registry-stack |
| Assessment type | Maintainer self-assessment |
| Review history | No public review ledger yet |
| Last reviewed | 2026-06-24 |
Overview
Section titled “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 governed evidence responses through Registry Notary.
The public architecture, boundary model, and product roles are documented in Architecture and Boundaries and map. The cross-cutting security requirements are documented in RS-SEC-G.
Self-assessment use
Section titled “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
Section titled “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.
- Credential issuance for configured Notary surfaces, including SD-JWT VC issuance where configured.
- Hash-chained audit records emitted by runtime services.
- Release workflow support for public checksums, keyless cosign signatures for GitHub Release assets, image digests, image SBOMs, Grype vulnerability reports, and generated release capsules after the first capsule-producing release run.
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
Section titled “Project compliance”Registry Stack documents standards alignment in Standards and the public spec register in Specifications. These pages describe implementation evidence and known gaps; they do not claim legal compliance by themselves.
Secure development practices
Section titled “Secure development practices”Development evidence:
- CI runs Rust format, workspace checks, focused tests, release-tool tests, lab source-model checks, and docs checks.
- OpenSSF Scorecard runs on the root workflow and publishes default-branch results as hygiene telemetry.
- Release manifests pin source refs and external inputs.
- Release validation checks source tag matching, source-ref ancestry, default branch reachability, and manifest consistency.
- Release capsules are generated from workflow evidence rather than hand-written prose.
- GitHub Release assets are signed by the root release workflow with keyless
cosign. Tag-triggered releases produced by the current workflow also publish
release-level SLSA provenance. The public verification process is documented in
release/VERIFY.md.
Known release-integrity gaps:
- OCI image signatures are not yet published for root monorepo releases.
- Existing releases produced before the provenance workflow change may not include release-level SLSA provenance assets.
- Public claims about signing are scoped to the release asset or product surface that actually performs signing.
Security issue resolution
Section titled “Security issue resolution”Report vulnerabilities through
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.
No public review ledger yet.
Appendix
Section titled “Appendix”Primary public evidence:
- RS-SEC-G
- Contracts
- OpenSSF evidence
- Registry Notary API reference
- Registry Relay API reference
- GitHub Release assets, with generated release capsules after the first capsule-producing release run
- Release verification