Skip to content
Registry StackDocsv0.25.0
Search

Security self-assessment

View as Markdown

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”
FieldValue
ProjectRegistry Stack
Repositoryregistrystack/registry-stack
Assessment typeMaintainer self-assessment
Review historyNo public review ledger yet
Last reviewed2026-08-03

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 signed minimum-disclosure assertions through Evidence Gateway.

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.
  • Signed, stateless Evidence Gateway assertions, serialized as a flattened JWS or, under Evidence Gateway’s frozen profile, as an SD-JWT VC response.
  • Hash-chained audit records emitted by runtime services.
  • 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

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, 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.

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

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.

Appendix

Section titled “Appendix”

Primary public evidence: