What is an SBOM (Software Bill of Materials)?

A modern SBOM goes well beyond a package.json listing. At minimum it captures the NTIA minimum elements:

• Supplier of each component (who produced it).
• Component name and version.
• Unique identifier — typically a PURL (Package URL) or CPE, plus cryptographic hash where applicable.
• Dependency relationships — direct vs transitive, and the path from the shipped artefact down.
• Author of the SBOM (often the build system).
• Timestamp of generation.

Production-grade SBOMs add: license metadata, vulnerability cross-references (VEX statements), build-environment provenance (SLSA attestations), and the cryptographic signature over the SBOM document itself.

CycloneDX (maintained by OWASP) is JSON-first, optimised for security tooling and CI/CD pipelines. It is the format most security scanners and CI integrations emit natively. SPDX (Linux Foundation, ISO/IEC 5962:2021) is more verbose, license-focused, and the format federal contracts most often specify by name. Most modern toolchains can convert between the two; both are acceptable to the EU CRA and US federal requirements.

The reliable production model is *build-time generation*. The CI/CD pipeline that produces the artefact emits the SBOM at the same step, signs both with the same key, and stores them together. Tools that do this well include Syft (Anchore), CycloneDX CLI, Microsoft sbom-tool, GitHub's SBOM generation, and most modern container build tools (BuildKit, ko, Buildah).

The failure modes that show up at audit:

• Manual SBOMs assembled in spreadsheets at audit time — they are wrong on day zero and rot daily. Auditors check timestamps and divergence from current lockfiles; this approach fails.
• Direct-dependency-only SBOMs — miss the transitive packages that almost every supply-chain incident exploits. Log4Shell would not have been discoverable in a direct-only SBOM for the vast majority of affected products.
• Container-image SBOMs that stop at the application layer — miss the base-image system libraries (glibc, OpenSSL) that are the real attack surface in containerised production.
• No build-time-tool coverage — the compromised package in the May 2026 Tanstack incident was a *build-time* dev dependency, not a runtime one. Build-time-only SBOMs missed it entirely.
• No signature on the SBOM — a tampered SBOM is worse than no SBOM. Regulators are increasingly asking for the signature chain alongside the document.

The defensive value of SBOMs becomes obvious during a supply-chain incident. The question "which of my products contains version X of package Y" goes from a multi-day cross-team reconciliation to a single SBOM query.

Real incidents in the 2024-2026 timeframe:

• Log4Shell (CVE-2021-44228) — organisations with mature SBOM coverage of every shipped artefact answered the blast-radius question in hours. Organisations without spent weeks.
• xz-utils backdoor (CVE-2024-3094) — affected a narrow Debian/Fedora pre-release branch. SBOM queries against base-image SBOMs identified scope within minutes; manual enumeration took days.
• Shai-Hulud / Mini Shai-Hulud (2024-2025) — npm worm-style supply-chain compromise. Organisations with current SBOMs on every CI artefact identified the affected pipelines in single queries. Organisations without were forced into broad credential rotation as a precaution.
• Tanstack incident, May 2026 — affected a build-time-only dev dependency. Organisations whose SBOMs included build-time tools answered the impact question on the same day; those whose SBOMs stopped at runtime dependencies missed the vector.

The operational requirement is therefore an SBOM that is (a) per shipped artefact, (b) covers transitive and build-time dependencies, (c) is generated and signed at build time, (d) is stored where incident-response tooling can query it in seconds. Trust Centers / continuous-evidence platforms with built-in SBOM ingestion satisfy this by construction.

EU Cyber Resilience Act (Reg. 2024/2847) — manufacturers must "identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product" (Annex I, Part 2(1)). The SBOM must be provided to market-surveillance authorities upon request. Full obligation from 11 December 2027.

EU NIS2 (Directive 2022/2555 + national transpositions) — Art. 21 measures include "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". National authorities (ACN in Italy, BSI in Germany, ANSSI in France) routinely request SBOMs during inspections, even though the Directive does not name the term explicitly.

EU DORA (Reg. 2022/2554) — ICT-third-party risk management (Art. 28+) requires registers of contractual arrangements with detailed ICT-supplier information. SBOMs feed directly into this register for shipped ICT products.

US Executive Order 14028 — federal procurement requires self-attested SBOMs. NIST SP 800-218 (SSDF) and SP 800-204D operationalise it.

US Federal Acquisition Regulation (FAR) supply-chain rules — incremental rule-making through 2025-2026 increasingly demands SBOM ingestion in vendor risk-management programs.

In aggregate: an organisation that ships software products into either jurisdiction in 2026-2027 without an automated, signed-at-build-time SBOM process is now an outlier among its peer set, and will be at procurement and audit disadvantage relative to vendors that ship one as standard.