Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which SBOM artifacts count as audit evidence?
Last verifiedThe useful SBOM evidence is one machine-readable inventory per released version, generated by the build, stored with the artifact, and queryable when an advisory lands. Format matters less than coverage, versioning, and retrievability.
SBOM evidence map, last verified 10 September 2026 against the NTIA minimum elements for a software bill of materials, CISA SBOM materials, the SPDX specification (published as ISO/IEC 5962:2021) and the CycloneDX specification, and Regulation (EU) 2024/2847 (the EU Cyber Resilience Act), whose Annex I and Annex VII provisions reach SBOMs for products with digital elements placed on the Union market. US federal requirements arrived through executive orders and OMB memoranda and have been amended more than once, so their current status must be checked rather than assumed. Outside those specific regimes, keeping SBOMs is industry best practice. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: an engineering leader, security engineer, or compliance owner deciding what to generate, where to keep it, and how to use it — and needing to know which parts of that are obligations rather than good hygiene.
This page is not legal advice. It does not determine YOUR obligations, does not decide whether the EU Cyber Resilience Act or any US federal requirement applies to you, does not start a clock, and does not file anything with an auditor. Whether you are a manufacturer of a product with digital elements placed on the Union market, and what that then requires, is a legal question for counsel — see the CRA pages on this site for the statutory text and its dates. Last verified 10 September 2026.
The most common SBOM failure is not format choice. It is generating an SBOM for the current main branch instead of one per released version, so that when an advisory lands you cannot answer which shipped releases contain the affected component. An SBOM that cannot be tied to a release is an inventory of a moment nobody deployed.
- Generate at build time from the same inputs that produced the artifact. An SBOM produced later by scanning a repository describes the repository, not the release.
- Depth is a decision you must record. Top-level dependencies are cheaper and less useful; transitive depth is where most exposure actually lives, and lockfile-based generation is what makes it reliable.
- The SBOM is an input to a question, not the answer. Its value shows up when you can query it — which releases include this component, and which customers run those releases.
- Sharing an SBOM externally is a separate decision from generating one. Some regimes contemplate providing it on request rather than publishing it; treat disclosure as a commercial and legal question, not a technical default.
SBOM-artifact-to-control map
Read the first column as the artifact, the second as what it evidences, the third as where it comes from, and the fourth as the common failure. Last verified 10 September 2026. Not legal advice.
| SBOM artifact | What it evidences | Where it comes from | Common failure |
|---|---|---|---|
| Per-release SBOM, machine-readable, one per released version | You know the composition of what you actually shipped. ISO/IEC 27001:2022 Annex A 5.9 inventory of associated assets and 8.8; AICPA TSC CC7.1. | Generated in the build job from the resolved dependency graph or lockfile, stored alongside the artifact by digest. | One SBOM for the default branch, regenerated on each build and overwriting the last, so no shipped version has its own record. |
| Minimum data fields per component | The inventory is usable by someone other than its author: supplier, component name, version, dependency relationship, unique identifiers, author of the SBOM data, and timestamp. | The NTIA minimum elements describe these fields; both SPDX and CycloneDX express them. | Components with a name and no version or identifier, which cannot be matched against an advisory. |
| Dependency relationships, including transitive depth | Exposure through indirect dependencies is visible, not assumed absent. Annex A 8.8; supports blast-radius analysis in an incident. | Lockfile-aware generation, or a build-integrated tool that records the resolved graph rather than the declared manifest. | Top-level-only SBOMs presented as full inventories, understating reach considerably. |
| Format declaration and specification version | The artifact can be parsed and validated by a consumer's tooling. SPDX (ISO/IEC 5962:2021) or CycloneDX, with the specification version stated. | The generator's output; validate against the specification schema in the pipeline. | A home-grown JSON list called an SBOM, which no customer tool can ingest. |
| Storage location and retrieval path | The SBOM is findable years later, by release, without archaeology. ISO/IEC 27001:2022 Clause 7.5 documented information. | Artifact registry alongside the image or package, or the evidence repository indexed by release version and digest. | SBOMs kept only as CI job artifacts, which expire on the platform's default schedule long before the release is retired. |
| Integrity of the SBOM itself | The inventory has not been altered since the build produced it. NIST SP 800-218 PS.1–PS.3; supports SLSA-style provenance claims, which are best practice. | Signing or attesting the SBOM in the build, and verifying the signature when it is consumed. | An unsigned SBOM in a mutable location, which evidences whatever the last editor wanted. |
| SBOM-to-advisory matching records | The inventory is actually used: the record of which advisories were checked against which releases, and the outcome. | Your vulnerability-management workflow, joining component identifiers from the SBOM to advisory feeds. | Years of SBOMs and no record of ever querying them, which evidences collection rather than a control. |
| Third-party and supplier SBOMs received | Components you did not build are also inventoried, including vendored code and container base layers. AICPA TSC CC9.2; Annex A 5.21 managing information security in the ICT supply chain. | Supplier deliverables, base-image SBOMs from the registry, or generation against the image you actually run. | Only first-party code inventoried, so base-image and vendor exposure is invisible. |
| Support-period and end-of-life mapping | You know which releases are still supported, and therefore which SBOMs still matter. Relevant to CRA support-period reasoning, and to customer commitments. | Your release and support policy, joined to the SBOM index by version. | Retaining every SBOM forever with no idea which releases are live, which makes the set unusable in a hurry. |
| Disclosure and request-handling record | You can respond to a customer or authority request for composition information in a controlled way. | A documented process naming who may release an SBOM externally, in what form, and under what terms. | Ad hoc disclosure by whichever engineer was asked, with no record of what was shared. |
Where SBOM is a legal requirement, and where it is best practice
This is the section most SBOM content gets wrong, usually by implying a general legal duty that does not exist. There are specific regimes that reach SBOMs, and a large space outside them where SBOM is excellent practice and nothing more. Last verified 10 September 2026. Not legal advice, and not a determination that any of these applies to you.
| Source | Which kind of authority | What it does not mean |
|---|---|---|
| Regulation (EU) 2024/2847 (Cyber Resilience Act): Annex I Part II requires manufacturers to identify and document components contained in the product with digital elements, including by drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies of the product. | Legal requirement — a regulation, but only where the CRA applies to you as an economic operator for a product with digital elements made available on the Union market. Article 71 sets phased application dates; the CRA pages on this site carry the statutory text and those dates. | Does not mean every software company has an SBOM duty, does not decide that you are a manufacturer, and does not start a clock. Note the regulation's floor is top-level dependencies — deeper coverage is your choice, and a good one. |
| Regulation (EU) 2024/2847 Annex VII: the SBOM forms part of the technical documentation, and point 8 contemplates providing it to a market surveillance authority further to a reasoned request. | Legal requirement where the CRA applies. It is a provide-on-reasoned-request provision, not a general publication duty. | Does not require you to publish an SBOM publicly. Recital 77 of the regulation states manufacturers should not be obliged to make the SBOM public — a recital, not an operative article. |
| US federal software requirements: Executive Order 14028 (2021) directed SBOM-related requirements for software sold to federal agencies, implemented through OMB memoranda and agency attestation processes. Subsequent executive orders have amended that cybersecurity policy landscape more than once. | Legal requirement in the contractual and acquisition sense, for suppliers selling software to US federal agencies, and only to the extent the current instruments and your contract require it. Verify current status — this is the fastest-moving item on this page. | Does not apply to a company with no US federal customers, and does not create a general SBOM duty for commercial sales. Do not cite a superseded memorandum as your obligation. |
| NTIA — The Minimum Elements for a Software Bill of Materials (2021). | Regulatory guidance. It describes the data fields, automation support, and practices that make an SBOM useful; it is not itself binding. | Does not make an SBOM mandatory. It is the best short answer to what fields your SBOM should contain. |
| CISA SBOM materials and community working-group outputs. | Agency guidance and community consensus. Useful on sharing, depth, and tooling expectations. | Not a regulation, and not a certification requirement. |
| SPDX (published as ISO/IEC 5962:2021) and CycloneDX specifications. | Industry best practice — format specifications. ISO publication of SPDX makes it a standard, not a legal obligation. | Neither format is legally required in general. The CRA text speaks of a commonly used machine-readable format rather than naming one. |
| ISO/IEC 27001:2022 Annex A 8.8 and 5.21; AICPA Trust Services Criteria CC7.1 and CC9.2. | Certification requirements and attestation criteria. They require vulnerability management and supply-chain management; neither names an SBOM. | Does not mean an auditor will ask for an SBOM by name. Many now do, as a practical way to evidence component awareness. |
| Generate one signed SBOM per released version, including transitive depth from the lockfile, retain it for the supported life of the release, and query it whenever an advisory lands. | ShipReady Metrics recommendation. | Not required by any framework named here except where the CRA or a federal contract reaches you. Adopt it because it turns an urgent advisory into a query. |
Checklist
A question list for the SBOM side of your evidence set. Not a determination that the CRA, a federal requirement, or any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Do we produce one SBOM per released version, or one per branch build that overwrites the last?
- Is the SBOM generated in the build from resolved dependencies, or produced later by scanning a repository?
- Does it include transitive dependencies, and is the depth decision recorded?
- Does it carry the NTIA minimum elements — supplier, component, version, relationships, identifiers, author, timestamp?
- Is it in SPDX or CycloneDX with the specification version stated, and validated against the schema in the pipeline?
- Is it stored somewhere that outlives the CI platform's artifact retention, indexed by release and digest?
- Is it signed or attested, and is that signature verified when it is consumed?
- Can we answer, today and without engineering archaeology, which shipped releases contain a named component version?
- Do we inventory base images and vendored third-party code, or only first-party dependencies?
- Do we know which releases are still supported, so we know which SBOMs still matter?
- Is there a documented process for who may share an SBOM externally, in what form, and on what terms?
- Has counsel been asked whether the CRA or any customer or federal contract creates an SBOM obligation for us?
What to do now
Ordered so that the ability to answer an urgent advisory arrives first. None of these steps is a legal determination, and none files anything with an auditor or a regulator.
- Add SBOM generation to the release job, keyed to the release version and artifact digest, before worrying about format debates.
- Move SBOMs out of CI job artifacts into the artifact registry or evidence repository, so they survive the platform's retention window.
- Include transitive depth via the lockfile, and write down the depth decision and its reason.
- Build the query path: given a component and version, which releases include it. Practise it once on a real advisory rather than discovering it during one.
- Add base images and vendored code to the inventory, so supplier exposure is visible.
- Sign or attest the SBOM in the same build that produces it, and verify on consumption. Provenance you never verify is documentation.
- Ask counsel the scope question: does the CRA reach any product we make available on the Union market, and does any customer or federal contract impose SBOM terms? Record the answer, including a not-in-scope answer.
- Re-verify the NTIA and CISA materials, the format specifications, and the CRA and US federal position annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not draw up your CRA technical documentation, does not produce your EU declaration of conformity, does not file anything with a market surveillance authority or an auditor, and does not determine that the CRA applies to you.
What exists: dependency and Dependabot ingest through the read-only GitHub App, GitLab security-findings ingest, cross-source deduplication, and blast-radius search over captured dependencies — including transitive npm dependencies where a lockfile was fetched. That blast-radius capability is the practical use of composition data: which captured services include an affected package.
Vulnerability management ranks findings using CISA KEV membership, EPSS, and CVSS. Those records are product evidence about your connected sources. They are not your CRA Annex VII technical documentation and not an SBOM kept at the disposal of a market surveillance authority.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Compliance → CRA reporting tracks the 24-hour, 72-hour, and 14-day ladder from recorded awareness for findings the organisation classified as CRA-in-scope; it does not start a clock and a named human still submits. The obligation map lists frameworks your organisation marked in-scope, which is not a legal opinion that a framework applies.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II and Annex VII, is a legal requirement only where it applies; Article 71 sets its phased dates, and Recital 77 is a recital rather than an operative article. NTIA's minimum elements for a software bill of materials and CISA's SBOM materials are guidance. The SPDX specification, published as ISO/IEC 5962:2021, and the CycloneDX specification are format standards and industry best practice. US federal SBOM requirements arrived through executive orders and OMB memoranda that have been amended more than once — verify the current instruments and your contract terms. ISO/IEC 27001:2022 Annex A 5.9, 5.21 and 8.8 are certification requirements. AICPA Trust Services Criteria CC7.1 and CC9.2 are attestation criteria. NIST SP 800-218 is guidance. Not a complete list, and not legal advice.
The CRA evidence-retention page on this site carries the statutory keep and the Annex VII content list. The SBOM blast-radius guide on this site explains the query side, and the dependency and vulnerability-management pages in this cluster cover the surrounding controls.