SBOM: From Regulatory Constraint to Cornerstone of Software Security

When a critical vulnerability like Log4j or SolarWinds erupts, some companies still take weeks to determine whether they are affected. Tomorrow, with the generalization of SBOMs, that delay could drop to just a few minutes. This is precisely what Europe and the United States are aiming for by making software transparency mandatory.

Since December 2024, the rules of the game have changed in Europe. With the entry into force of the Cyber Resilience Act, manufacturers of digital products now have until December 11, 2027 to provide a Software Bill of Materials (SBOM) in a machine-readable format. This software inventory, which records a complete and traceable list of the components used, becomes a prerequisite for accessing the European market and complying with regulatory obligations.

“Knowing what’s in your own software”

For Allan Friedman, senior advisor at CISA and a historical figure of the movement, the formula is simple: “SBOM is the radical idea that we should actually know what is in our own software.” The SBOM is not limited to a static list: it describes the making of the software, its dependencies, versions, and licenses, all in a standardized format.

For Gonda Lamberink, Senior Global Director Cybersecurity at Bureau Veritas, its role has become obvious: “SBOMs represent a large part of the solution to the problem of supply chain security… they can become an essential element of software security practices by facilitating collaboration across the chain and accountability.” The SolarWinds and Log4j crises have proven how a lack of transparency slows down response and amplifies the impact of attacks.

Strict obligations in the United States

In the United States, authorities did not wait for Brussels to set strict rules. The FDA has required for several years that any pre-market submission for a medical device must include a complete SBOM, covering commercial, open source, and off-the-shelf components. The legal basis is §524B of the Federal Food, Drug, and Cosmetic Act, and the most recent update of the guidelines on June 26, 2025 made this an explicit condition for Cyber-Devices.

The federal public sector is also concerned. With memos OMB M-22-18 and M-23-16, the White House requires suppliers to attest to compliance with the NIST SSDF through the Secure Software Development Attestation procedure managed by CISA. Even if not every SBOM is systematically required, the obligation of transparency has become a clear and structuring expectation for suppliers.

A practice that is becoming professionalized

For Kelli Schwalm, Senior Product Manager at RunSafe Security, the shift is radical: “The minimum SBOM elements recommended in 2025 show how far the sector has come… from a theoretical list to practical requirements.” The integration of cryptographic hashes, author information, and generation context now requires automated and reliable production. Schwalm stresses that an SBOM generated at build time is the most faithful and warns against excluding embedded software, which often involves the most critical systems.

CISA as technical conductor

CISA not only sets obligations but also describes the types of SBOM: source, build, analysis, installation, and runtime. This classification facilitates operational implementation in development and operations processes. It provides a shared compass for developers, integrators, buyers, and regulators.

“BOMs are not a new concept,” recalls Steve Springett, initiator of CycloneDX and founder of OWASP Dependency-Track. Inventories have existed for a long time, but their systematic integration into CI/CD pipelines is a game-changer, offering transparency and traceability at scale.

A gap between ambition and reality

The figures show a worrying delay. According to the 2025 Ponemon study, 59% of companies reported an attack on their software supply chain, half of them in the past year. More than a quarter of these incidents were linked to unpatched open source vulnerabilities. Yet only 39% maintain a complete inventory of their dependencies, and a significant proportion do not validate delivered SBOMs or link them to continuous monitoring. The result: weeks of delay in detection and response, increased costs, and a shift from prevention to crisis management.

Generative AI, a new risk factor

The massive arrival of generative AI adds new complexity. Teams integrate suggested code without traceability of its origin, licenses, or transitive dependencies. “Phantom packages” appear in dependency trees, making monitoring even more difficult. Backslash Security has tackled the issue with a platform capable of analyzing reachability, vulnerability, and traceability of AI-generated code, offering specific visibility into these phantom packages.

Formats, VEX and living SBOMs

On the formats side, two standards dominate the market: SPDX and CycloneDX. Both cover the minimum fields established by the NTIA and can be generated continuously through CI integrations. Synopsys has chosen to anchor the SBOM in its SDLC, linking export, import, validation, and curation to a multi-step vulnerability management process. For Tim Mackey, Principal Security Strategist at Synopsys, “modern software applications have a dependency problem.” The complexity of today’s architectures requires exhaustive inventories including sources, artifacts, hashes, dependencies, and licenses, to transform the SBOM into a living artifact rather than a mere snapshot.

The VEX, for Vulnerability Exploitability eXchange, complements this framework by providing insight into the actual exploitability of identified vulnerabilities. CISA has defined minimal requirements and statuses for these documents, enabling consumers to make informed decisions. By combining SBOM and VEX, companies reduce false positives and streamline response chains, even when security advisories follow one another rapidly.

2025–2026: operationalization

The SBOM is no longer a one-off report but becomes an artifact automatically produced at build time, stored in repositories, signed when needed, and integrated via APIs into risk management platforms. CISA’s classification has established itself as a reference, particularly to avoid blind spots in containerized environments or dynamic chaining of services at runtime. Anchore puts it bluntly: “When the next zero-day hits your infrastructure, will you spend five minutes identifying affected systems or five months hunting through manual inventories?”

The reflection does not stop at classic code. The Linux Foundation proposes to extend the concept with an AI-BOM, aimed at documenting algorithms, datasets, frameworks, and licenses. Based on SPDX 3.0, this new artifact seeks to strengthen transparency in a context where artificial intelligence is becoming a central component of digital value chains.

A market in motion

The market is responding with a wide range of solutions. Dependency-Track is establishing itself for large-scale SBOM analysis and continuous correlation with new advisories. CycloneDX stands out for its proximity to real-world practice, while SPDX has become widely adopted in compliance contexts. Tools like LibTracker, integrated directly into development environments, make versions, vulnerabilities, and licensing aspects visible in real time, bridging the gap between build, security, and legal.

For Josh Bressers, VP Security at Anchore and co-lead of the OpenSSF-SIG “SBOM Everywhere,” the practical value is no longer in question: without a reliable inventory, no organization can accelerate in the face of a zero-day. With a structured SBOM, response gains both precision and speed. Josh Corman, Vice President of Cyber Safety Strategy at Claroty, emphasizes the cross-sectoral scope: “SBOMs are a standard valued in every sector; we want to apply proven supply chain principles to software development – that should not be controversial.”

Governance, contracts and audit

In the future, SBOMs will not just be technical artifacts but governance tools integrated into contracts and audits. Synopsys already recommends defining requirements according to context, identifying user groups, and reviewing the legal situation. Clients, for their part, expect evidence of a secure SDLC, vulnerability reports, and accept VEX documents as a basis for decision-making. Integrating these elements into business relationships structures processes and avoids the logic of a mere “box-ticking exercise.” Kelli Schwalm even recommends starting with a comprehensive SBOM to identify and prioritize memory vulnerabilities in OT environments.

Clear signals for 2025 and 2026

The Ponemon figures send clear signals. Less than half of companies automate validation of open source dependencies, and only a third systematically assess AI-generated code. Many still rely on incomplete manual inventories. The study recommends continuous import and validation of SBOM data from third-party sources, checking against malicious package lists, and active monitoring of applications in production. The conclusions confirm the direct correlation between transparency, response speed, and risk reduction.

Conclusion

The SBOM is emerging as a two-faced instrument: a regulatory constraint in Europe and the United States, but also a major operational tool. By combining standardized formats, VEX assertions, CI/CD integrations, and runtime views, it closes informational blind spots that attackers have exploited for years. Regulatory deadlines set the minimum and push companies to invest. Those who, as early as 2025 and 2026, integrate SBOM generation and validation into their pipelines will turn this constraint into a competitive advantage: smooth compliance, stronger governance, and tangible risk reduction.