OpenSSF and release trust
This page records which Registry Stack release-trust checks you can verify, and which Open Source Security Foundation (OpenSSF) answers remain 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? | No. The release workflow checks source-tag consistency, but Git tag objects are not GPG-, SSH-, or Sigstore-signed. | Release workflow |
| Are provenance attestations published? | Yes, for tag-triggered releases produced by the current workflow. v0.13.0 includes tag-bound release provenance. | v0.13.0 assets and release/VERIFY.md |
| Are published builds repeatable? | The canonical Linux amd64 binaries, image config, and ordered image layers have repeated exactly for v0.13.0. The documented scope excludes environment independence and generated evidence bytes. | release/REPEATABLE-BUILDS.md |
Current release evidence chain
Section titled “Current release evidence chain”The candidate release path builds and scans private candidate packages before the operator creates the release tag. Promotion verifies the exact candidate run and attempt, publishes the same candidate bytes and image digests, and includes the signed candidate receipt as a GitHub Release asset. The receipt records the build run identity.
Release provenance binds the tagged source to the published release bytes.
The candidate receipt connects those bytes to the workflow run that compiled
them.
Two builds in one candidate run demonstrate build determinism, not environment
independence.
The scheduled clean rebuild provides later-host evidence for the narrower
repeatability claim tracked in
release/REPEATABLE-BUILDS.md.
v0.13.0 predates candidate promotion, but it has public exact rebuild evidence
for the same canonical Linux amd64 binary and image scope.
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 unsigned Git tags remain explicit caveats.
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.
The exact in-tree answer source is
release/openssf-best-practices-silver.yaml.
The answers mirror the selected criteria on the
Registry Stack Best Practices project page,
checked on 2026-07-25.
The authoritative project page reports the Silver badge; the in-tree file
makes the selected answers and evidence links reviewable with the code.
| Criterion | Status | Public evidence |
|---|---|---|
build_repeatable | Met | Project answer and v0.13.0 repeatable-build evidence |
signed_releases | Met | Project answer and release verification commands |
version_tags_signed | Unmet | Project answer and release workflow |
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 | Current releases promote a verified pre-tag candidate. Historical releases, including v0.13.0, used the tag-driven build workflow. | Release workflow and release manifests |
| Signed releases | Current release assets are signed. v0.13.0 carries keyless cosign signatures, certificates, and tag-bound provenance. v0.8.0 remains unsigned. | release/VERIFY.md and v0.13.0 assets |
| 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 promotion also publishes release-level SLSA provenance.
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); current promotion also publishes its candidate receipt |
| 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 | Candidate build attestation plus release-level SLSA provenance for non-signature GitHub Release assets | Workflow enabled; v0.13.0 provides current public tag-bound release provenance, while the candidate receipt chain applies to releases produced by the candidate workflow |
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.