SBOM is moving from “good practice” to operational obligation

European Union Agency for Cybersecurity (ENISA) new “SBOM Adoption State of Play – 2026” report confirms that SBOM is becoming a core requirement for software supply chain transparency, vulnerability management, third-party risk management and regulatory compliance.

The key driver is the Cyber Resilience Act, which becomes fully applicable in December 2027. ENISA notes that the CRA makes security by design and security by default a legal obligation for digital products entering the EU market, and introduces a requirement for manufacturers to create, maintain and, where necessary, share SBOMs with market surveillance authorities.

Photo: freepik

SBOM is no longer only about software development teams knowing what libraries they use.

It is about:

➡️ Evidence of what is inside the product.

➡️ Evidence of dependency visibility.

➡️ Evidence of vulnerability handling.

➡️ Evidence of supplier transparency.

➡️ Evidence for procurement, compliance and regulators.

Under the CRA, SBOM should be machine-readable, kept up to date across the product lifecycle, included in technical documentation, and used in vulnerability handling processes.

ENISA’s survey received 334 responses, with around 65% EU-based and more than 80% directly impacted by the CRA. 78% of respondents have already started their SBOM adoption journey, but only 9% reported mature, automated implementation.

The report highlights several challenges:

➡️ SBOM completeness,

➡️ data quality,

➡️ supplier SBOM availability,

➡️ vulnerability matching,

➡️ lack of internal skills,

➡️ and integration into risk and compliance processes.

One finding is especially important for buyers: only 10% of respondents said they already have mandatory SBOM requirements in supplier contracts, while many organizations are still planning or applying this only ad hoc.

This is where procurement and TPRM should become much more active.

Organizations that buy software should not wait passively for vendors to mature. They should start asking for SBOMs as part of due diligence, contractual requirements and ongoing vendor monitoring.

➡️ If you develop software, you should generate and maintain SBOMs.

➡️ If you buy software, you should require SBOMs from your suppliers.

➡️ This logic is no llimited to traditional software. In AI, we increasingly talk about AIBOM, covering a broader and more complex ecosystem: models, datasets, infrastructure, dependencies, components, providers, security properties and governance information.

Link

Author: Sebastian Burgemejster