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. v0.8.3 is the first planned provenance-bearing root release. Existing 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:
Use the check-level results as hygiene telemetry. 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 | 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.0 is not signed unless it is backfilled later, and v0.8.2 does not include tag-bound SLSA provenance unless a separate backfill decision is made. v0.8.3 is expected to exercise the provenance path. | release/VERIFY.md and GitHub Releases |
| Signed version tags | Not implemented. Git tag objects are not yet cryptographically signed. | Release workflow |
| Dependency policy | Dependency-deny configuration is present; root CI enforcement is tracked separately. | deny.toml |
| 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 |
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 v0.8.0; 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; v0.8.3 expected to be first provenance-bearing root release |
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.