OpenSSF and release trust
This page explains which public release-trust checks you can verify for Registry Stack, and which OpenSSF signals are self-attested or still incomplete.
For release signature and provenance verification commands, use
release/VERIFY.md.
Release trust status
Section titled “Release trust status”| Question | Current answer | Verification source |
|---|---|---|
| Are GitHub Release assets signed? | Yes, for release assets produced after keyless cosign signing landed. Each signed asset has a matching .sig and .pem file. | SECURITY.md and release workflow |
Is v0.8.0 signed? | No. The v0.8.0 prerelease was published before release-asset signing was added and has not been backfilled with .sig and .pem assets. | GitHub Release assets |
| Are release Git tags signed? | Not yet. The release workflow checks source-tag consistency, but Git tag objects are not yet GPG-, SSH-, or Sigstore-signed. | Release workflow |
| Are provenance attestations published? | Enabled for tag-triggered releases produced by the current workflow. As of 2026-07-09, v0.8.3 and v0.8.4 include root release provenance; releases produced before this workflow change, including v0.8.2, may not include .intoto.jsonl provenance assets. | Release workflow and release/VERIFY.md |
Scorecard
Section titled “Scorecard”Registry Stack configures OpenSSF Scorecard in
.github/workflows/scorecard.yml. The workflow is scheduled and runs on
default-branch changes.
Current public evidence:
Read the check-level results, not the aggregate score. The aggregate score can hide important details, so release-integrity findings such as missing signed Git tags or provenance are tracked as explicit caveats until they are fixed.
Known caveats include older releases without provenance, branch-protection visibility, SAST coverage, unpinned lab images, and existing dependency vulnerability findings. Check-level Scorecard results are signals, not a certification.
Best practices badge
Section titled “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.
Current user-visible status:
| Area | Current status | Public evidence |
|---|---|---|
| Vulnerability reporting | Private reporting policy is published. | SECURITY.md |
| CI and tests | CI runs on the public repository. | CI workflow |
| Release process | Releases are built by the tag-driven release workflow and checked against release manifests. | Release workflow and release manifests |
| Signed releases | v0.8.0 is unsigned; v0.8.2 has no tag-bound SLSA provenance. | release/VERIFY.md and GitHub Releases |
| Signed version tags | Not implemented. Git tag objects are not yet cryptographically signed. | Release workflow |
| Dependency policy | Dependency advisories are enforced through cargo deny check in the CI rust job, which runs on every push that touches Rust code (the job is path-filtered). An advisory without an upstream fix carries a scoped, documented ignore in deny.toml with a review trigger. | deny.toml and CI workflow |
| Source release evidence | Releases include release assets and generated release capsules. Later signed releases add signature assets, and tag-triggered releases produced after the provenance workflow change add .intoto.jsonl provenance. | GitHub Releases |
Newly produced release assets are signed with keyless cosign and include .sig and .pem files.
Tag-triggered releases produced by the current workflow also include release-level SLSA
provenance; v0.8.3 and v0.8.4 both exercised the provenance path through the same
tag-triggered workflow.
OSPS baseline
Section titled “OSPS baseline”Registry Stack targets OpenSSF OSPS Baseline 2026-02-19, Level 1 as the first version-pinned baseline map. The map distinguishes root monorepo controls from legacy imported product controls.
| Control area | Public evidence | Status |
|---|---|---|
| Public source repository | registry-stack | Implemented |
| Vulnerability disclosure | SECURITY.md | Implemented |
| Automated tests | CI workflow | Implemented |
| Token permissions | CI uses read-only permissions; release write permissions are scoped to publishing jobs | Implemented |
| Release artifacts | Checksums, image digests, image SBOMs, vulnerability scans, release capsules | Published for every GitHub Release from v0.8.0 onward (v0.8.1 was a release candidate with no GitHub Release); signature assets are release-workflow gated |
| Signed releases | Keyless cosign signing for GitHub Release assets with .sig and .pem verification material | Implemented for newly produced release assets |
| Signed version tags | Cryptographic Git tag signatures | Not implemented |
| Provenance attestations | Release-level SLSA provenance for non-signature GitHub Release assets | Workflow enabled; as of 2026-07-09, v0.8.3 and v0.8.4 both include provenance |
Legacy product controls
Section titled “Legacy product controls”Imported product docs may describe older product-local release flows. They are not cited as active root monorepo controls unless the root workflow implements the same behavior or the claim is explicitly product-scoped.