A built artifact ships with an inventory of what went into it
Nobody can read a compiled binary to find out which dependency versions are inside it. Without an inventory, a newly disclosed vulnerability in a bundled library leaves every downstream user unable to answer whether they are affected, and the maintainer unable to tell them.
Observable check
a release that carries a built asset also carries a software bill of materials in SPDX or CycloneDX format, published as a release asset or at a path the README or release notes name, covering the dependencies that went into that asset. A release carrying only the source archives the forge generates falls outside this rule rather than failing it.
Where this comes from
- https://baseline.openssf.org/versions/2026-02-19
- https://github.com/ossf/scorecard/blob/main/docs/checks.md
- https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software.html
- https://docs.github.com/rest/dependency-graph/sboms
Last read against these sources on 2026-07-28.
OSPS-QA-02.02, Maturity 3: 'When the project has made a release, all compiled released software assets MUST be delivered with a software bill of materials.' Concise Guide item 18 names SPDX and CycloneDX as the formats. Scorecard's SBOM check supplies the observable form, an SBOM as a file in the source or a release artifact. Note this sits at Level 3 upstream, so it is a maturity target rather than a floor, and the rule's applicability clause is what keeps that honest. The forge dependency-graph export at GET /repos/{owner}/{repo}/dependency-graph/sbom was adopted on 2026-07-31 as the answer for the eight ecosystems whose reference names no SBOM generator. It returns SPDX, needs nothing installed in the release job, and is GitHub only, so GitLab keeps the gap.