OpenSSF and release trust

This page records which Registry Stack release-trust checks you can verify, and which Open Source Security Foundation (OpenSSF) answers have a narrower scope.

Use the public release/VERIFY.md procedure to authenticate a current release.

Release trust status

Question	Current answer	Verification source
Are current release payloads signed?	Yes. One keyless Sigstore bundle authenticates SHA256SUMS, which covers every public payload.	Release workflow
Are release Git tags signed?	No. The annotated tag binds a candidate run, attempt, and manifest hash, but the Git tag object is not cryptographically signed.	Release operations
Is release provenance published?	Yes. GitHub artifact attestations authenticate the candidate manifest and bundle, and the signed checksum chain authenticates the public payloads.	Release verification
Are published builds repeatable?	A weekly clean proof covers canonical Linux amd64 binaries plus image configuration and ordered layers. The OpenSSF justification is current only while an applicable successful proof is no older than 30 days.	Repeatable build evidence

Current release evidence chain

The candidate workflow builds each shipped artifact once, publishes candidate images only to private packages, scans exact image digests, and seals one seven-day candidate manifest and bundle. The annotated tag binds that manifest to the candidate run and attempt.

The protected-main publication workflow verifies the tag and candidate, then reconciles the complete draft GitHub Release before a public write. It promotes image manifests at the same digests, publishes the draft, and dispatches authenticated documentation promotion.

Current public security assets include:

• SHA256SUMS.
• One registry-stack-vX.Y.Z-SHA256SUMS.sigstore.json bundle.
• One consolidated SPDX JSON software bill of materials (SBOM).
• One checksum-covered security-evidence archive.
• One compact release manifest recording candidate and promotion identity.

Releases from v0.19.0 onward publish no container image lock. Current-main release tooling rejects earlier release shapes before asset discovery and directs operators to verify them from the corresponding source tag and archived assets.

Current releases do not publish a second generic SLSA provenance envelope, per-file signature and certificate pairs, release capsules, candidate telemetry, or intermediate receipt parts.

Scorecard

Registry Stack runs OpenSSF Scorecard on its normal schedule and by manual dispatch. Scorecard is posture telemetry and cannot change an ordinary release result.

• Latest public Scorecard viewer
• Scorecard workflow history

Read the check-level results rather than treating the aggregate score as a certification. Known caveats include unsigned Git tag objects and older releases with different evidence inventories.

Best practices badge

The OpenSSF Best Practices Badge is self-attested. Registry Stack records an answer only when a public source file, workflow, release artifact, or docs page supports that answer. The in-tree answer source is release/openssf-best-practices-silver.yaml. The authoritative project page is the Registry Stack Best Practices project.

Criterion	Status boundary	Public evidence
build_repeatable	Met only while the latest applicable clean proof is successful and no older than 30 days	Repeatable build evidence
signed_releases	Met for releases using the authenticated SHA256SUMS chain	Release verification
version_tags_signed	Unmet because Git tag objects are not cryptographically signed	Release workflow

A failed or stale repeatability result changes the badge justification. The result does not retroactively fail a published release and does not become an ordinary publication blocker.

OSPS baseline

Registry Stack targets OpenSSF OSPS Baseline 2026-02-19, Level 1 as the first version-pinned baseline map.

Control area	Public evidence	Status
Public source repository	registry-stack	Implemented
Vulnerability disclosure	SECURITY.md	Implemented
Automated tests	CI workflow	Implemented
Token permissions	Read-only build and verification jobs; package, release, signing, and Pages permissions are separated	Implemented
Release artifacts	Signed checksums, consolidated SPDX SBOM, security archive, and release manifest	Implemented by the current workflow
Signed version tags	Cryptographic Git tag signatures	Not implemented
Provenance	Candidate build attestations and a signed public checksum closure	Implemented by the current workflows

Historical releases

Historical release assets remain immutable. Earlier releases may contain per-file .sig and .pem pairs, capsules, candidate receipts, separate digest files, multiple SBOMs, a container image lock, generic SLSA provenance, or no provenance. Use the verification document committed at the selected tag and do not infer current guarantees from an older inventory. v0.8.0 remains unsigned.