ENISA publishes SBOM guidance tying automation to supply chain security

ENISA published its Technical Advisory for Software Bill of Materials on 22 Oct 2026 for organizations, especially micro-, small and medium enterprises, and stewards seeking initial SBOM capabilities.

The advisory links SBOM automation, integrity safeguards and lifecycle management directly to software supply chain security. ENISA urges organizations to use structured, machine-readable SBOM inventories to strengthen software supply chain transparency, find vulnerable components and monitor dependencies. The agency said SBOMs are a foundation for security, not a complete answer, and their worth relies on fitting into existing security workflows, quick patching and recorded vulnerability-handling choices. ENISA said the advisory reflects stakeholder feedback and aims to assist organizations, particularly SMEs.

The advisory describes SBOM implementation architecture and data flows using a defined lifecycle. It presents an indicative SBOM threat model with targeted risks and measures to address security issues across the SBOM ecosystem.

SBOMs should be continuously managed throughout the software development lifecycle and follow software evolution as components are added, updated, modified or removed through new releases. SBOM generators obtain data from code repositories, build outputs, package manager files, lock files, container images and binary scanning. For each component, generators collect metadata such as name, version, creator, unique identifiers, license information, external references and dependencies. SBOMs are produced in standard machine-readable formats, most commonly CycloneDX or SPDX.

Organizations can store SBOMs as JSON, XML, YAML or Tag-Value. ENISA points to SPDX and CycloneDX as accepted formats. The agency tells organizations to check inventories against built artifacts, confirm digital signatures, and build SBOM creation into development workflows and CI/CD (continuous integration/continuous delivery) pipelines. Capturing dependencies at build time works because dependencies are most accurately known then and requires little infrastructure change.

Automation remains a gap. 41% of organizations want full automation of SBOM generation for every release or build. Just 26% expect full automation of SBOM updates across the product support period, while nearly 23% expect partial automation.

ENISA advises organizations to begin with build-time integration as the minimum viable SBOM implementation. Yocto, Kubernetes, Linux and Zephyr are among the build environments that already provide automatic SBOM generation requiring only activation.

ENISA’s SBOM-focused threat model uses Microsoft’s STRIDE framework to assess six threat types: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The threat model covers generation tools, validation and signing services, repositories and consumption pipelines in addition to the SBOM artifact itself. To counter spoofing and tampering, organizations can use digital signatures, identity checks for suppliers and consumers, build attestations, secure key management, certificate revocation and integrity checks. Denial of service defenses involve extra infrastructure, DDoS protection, limits on file size and count, parser hardening and retention rules.

ENISA also warns that SBOMs may cause security and operational problems when they contain errors, are out of date, have been modified or removed, or are distributed without proper access controls.

ENISA’s SBOM Adoption State of Play 2026 identified a mismatch between organizational SBOM needs and actual SBOM delivery. 36 % of respondents said their organizations require every primary component and direct dependency with declared known unknowns, while just 29 % receive them. 24 % need SBOMs with full depth analysis, while just 14 % receive them.

A further 27 % want SBOMs with depth analysis including declared known unknowns, but only 12 % receive them. Sixty-two percent of respondents described achieving a high degree of SBOM completeness as quite difficult or extremely difficult. Survey respondents said they struggle to get SBOMs from suppliers, especially for commercial software bought from third parties.

Organizations are gaining better visibility into software they develop themselves, while supplier transparency stays uneven. The most common SBOM approach is build-time generation, with Thirty-nine percent of respondents producing SBOMs during software builds. Adoption efforts are slowed by data quality issues, vulnerability matching problems and a shortage of internal expertise. Organizations commonly use SBOMs for vulnerability management, software inventories, third-party risk assessments and compliance work.

The EU Cyber Resilience Act adds legal weight to SBOM expectations. Regulation EU 2024/2847 entered into force on December 10, 2024, and requires manufacturers to create, maintain and, where necessary, provide SBOMs for products with digital elements. The CRA mandates SBOMs for in-scope products in standardized machine-readable formats such as CycloneDX or SPDX, and covers hardware or software with digital elements offered on the EU market no matter where the maker is based or where production happens.

Violations may lead to fines reaching €15 million or 2.5% of worldwide annual turnover, whichever is higher, and removal of products from the EU’s 450-million-person single market. The CRA’s full requirements, including secure-by-design engineering, CE marking and mandatory security update commitments for support periods of generally a minimum of five years, come fully into force in December 2027. Starting December 11, 2027, products offered in the EU market cannot legally stay on sale without a CE marking demonstrating CRA compliance.

From September 11, 2026, manufacturers must submit an early warning to EU cybersecurity authorities within 24 hours of detecting active exploitation of a vulnerability in any product sold in the EU market. ENISA’s SBOM Adoption State of Play 2026 indicates organizations are readying for CRA duties using SBOM tools, automation and revised development practices as the EU Cyber Resilience Act approaches December 2027 application. SBOM adoption is underway across the software ecosystem, particularly among organizations that expect to be covered by the CRA. CRA-related investment decisions are shifting, as many organizations raise spending on SBOM tooling and automation.

CISA and 16 other government entities across four continents released new SBOM minimum elements guidance that supersedes the NTIA’s 2021 guidelines. The updated CISA guidance was first drafted in 2025 and informed by suggestions from 90 commenters, including Google, Microsoft and AWS. CISA’s SBOM guidance does not create legally enforceable requirements.

It introduces 10 new data fields and updates to existing elements, including a digital signature proving SBOM integrity and authenticity and the name and version of the SBOM generation tool. The new CISA guidance does not enshrine Vulnerability Exploitability eXchange (VEX), which NTIA created as a sister concept for SBOMs to show whether vulnerabilities are exploitable. According to CISA, accuracy, completeness and coverage assurance fall outside the SBOM document’s scope. Jeff Williams, founder of OWASP and founder and CTO of Contrast Security, said the test of success is whether security lowers real risk effectively, not whether it fully catalogues the problem.

CISA issued separate open source software best practices guidance one day after its SBOM guidance. The open source security guidance calls for agencies to get enough transparency into all relevant parts, including AI model training data.

An AI SBOM can reveal what a vendor claims is inside an AI system without proving the system is trustworthy for the enterprise’s intended use. Sanchit Vir Gogia, chief analyst at Greyhound Research, said minimum elements create visibility but do not create assurance.

The regulatory picture extends beyond the CRA. ENISA launched the European Vulnerability Database in May 2025 under the NIS2 Directive. The CRA sits alongside the NIS2 Directive and intersects with GDPR, which requires a separate 72-hour notification to data protection authorities that runs in parallel with CRA reporting.

Britain’s Product Security and Telecommunications Infrastructure Act entered into force in 2024. The OpenSSF and Linux Foundation Research 2026 CRA Awareness and Readiness Report found that 66% of respondents are unfamiliar with the CRA, compared with 62% in 2025. OpenSSF said over half of European small and medium-sized enterprises lack awareness of a regulation covering them.