Registry stack documentation: machine-readable Markdown. Index of all pages: https://docs.registrystack.org/llms.txt Full corpus: https://docs.registrystack.org/llms-full.txt # OpenSSF and release trust > Registry Stack public OpenSSF status and release verification evidence. 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`](https://github.com/registrystack/registry-stack/blob/main/release/VERIFY.md). ## 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`](https://github.com/registrystack/registry-stack/blob/main/SECURITY.md) and [release workflow](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/release.yml) | | 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](https://github.com/registrystack/registry-stack/releases/tag/v0.8.0) | | 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](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/release.yml) | | 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](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/release.yml) and [`release/VERIFY.md`](https://github.com/registrystack/registry-stack/blob/main/release/VERIFY.md) | ## Scorecard Registry Stack configures OpenSSF Scorecard in `.github/workflows/scorecard.yml`. The workflow is scheduled and runs on default-branch changes. Current public evidence: - [Latest public Scorecard viewer](https://scorecard.dev/viewer/?uri=github.com/registrystack/registry-stack) - [Scorecard workflow run history](https://github.com/registrystack/registry-stack/actions/workflows/scorecard.yml) 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 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`](https://github.com/registrystack/registry-stack/blob/main/SECURITY.md) | | CI and tests | CI runs on the public repository. | [CI workflow](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/ci.yml) | | Release process | Releases are built by the tag-driven release workflow and checked against release manifests. | [Release workflow](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/release.yml) and [release manifests](https://github.com/registrystack/registry-stack/tree/main/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`](https://github.com/registrystack/registry-stack/blob/main/release/VERIFY.md) and [GitHub Releases](https://github.com/registrystack/registry-stack/releases) | | Signed version tags | Not implemented. Git tag objects are not yet cryptographically signed. | [Release workflow](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/release.yml) | | Dependency policy | Dependency-deny configuration is present; root CI enforcement is tracked separately. | [`deny.toml`](https://github.com/registrystack/registry-stack/blob/main/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](https://github.com/registrystack/registry-stack/releases) | ## 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`](https://github.com/registrystack/registry-stack) | Implemented | | Vulnerability disclosure | [`SECURITY.md`](https://github.com/registrystack/registry-stack/blob/main/SECURITY.md) | Implemented | | Automated tests | [CI workflow](https://github.com/registrystack/registry-stack/blob/main/.github/workflows/ci.yml) | 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 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.