SBOM uitgelegd: Waarom een Software Bill of Materials nu een beveiligingsvereiste is

A few years ago, the term "Software Bill of Materials" (SBOM) was barely known outside of niche software supply chain circles. Today, it is referenced in EU legislation, US executive orders, and enterprise procurement requirements worldwide. If your organization builds, buys, or operates software — and almost every organization does — understanding SBOM is no longer optional.

This article explains what an SBOM is, why it matters for security, what regulators are now requiring, and how it fits alongside other application security practices such as dynamic testing.

What Is an SBOM?

An SBOM is a structured, machine-readable inventory of all the components that make up a piece of software. Think of it as an ingredient list for code. Just as a food product must declare its ingredients so that consumers can make informed decisions, an SBOM declares the open-source libraries, third-party packages, and internal modules that a software application is built from.

A typical SBOM includes:

• Component names and versions — every library or package the application depends on
• Licensing information — the open-source licenses that govern each component
• Dependency relationships — how components relate to and depend on each other
• Source information — where each component comes from (package repository, internal codebase, etc.)
• Known vulnerabilities — references to CVEs (Common Vulnerabilities and Exposures) associated with each component

The two most widely used SBOM formats are SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both are designed to be machine-readable, enabling automated tooling to process and act on SBOM data at scale.

Why SBOMs Have Become a Security Priority

The Log4Shell vulnerability in late 2021 was a turning point. The Apache Log4j library — embedded in thousands of enterprise applications, often without the operators even knowing — was found to contain a critical remote code execution vulnerability. Organizations scrambled to answer a simple question: do we use Log4j? For many, answering that question took weeks, because they had no systematic inventory of their software components.

That experience crystallized what security professionals had long understood: modern software is built on a foundation of open-source components, and vulnerabilities in those components can cascade across the entire technology ecosystem. Without an SBOM, organizations are effectively flying blind.

The data supports the concern. The vast majority of modern applications contain open-source components, and a significant proportion of those components contain known vulnerabilities. In many cases, the vulnerable version is not the current one — organizations are running outdated dependencies because nobody tracked them.

What Regulations Now Require

EU Cyber Resilience Act (CRA)

The EU's Cyber Resilience Act, which entered into force in 2024, introduces mandatory cybersecurity requirements for products with digital elements sold in the European market. SBOM production and maintenance is explicitly part of the CRA's requirements. Manufacturers must document the software components in their products and keep that documentation updated throughout the product lifecycle.

NIS2 Directive

While NIS2 does not mandate SBOMs by name, its requirements around supply chain security and vulnerability management create strong practical pressure to implement them. Understanding what software components you are running — and what vulnerabilities they contain — is a prerequisite for the kind of systematic risk management NIS2 requires.

US Executive Order 14028

In the United States, Executive Order 14028 on Improving the Nation's Cybersecurity (2021) directed federal agencies to require SBOMs from software vendors. This has effectively made SBOM a baseline expectation for any organization selling software to the US federal government — and it has influenced procurement standards more broadly.

Enterprise Procurement Requirements

Beyond regulation, many large enterprises now request SBOMs as part of their vendor security assessments. If your organization sells software or SaaS services to other businesses, the expectation that you can provide an SBOM is increasingly common.

SBOM and Runtime Security: The Missing Link

An SBOM tells you what components are in your software. What it does not tell you is whether those components are being actively exploited in the running application. This is an important distinction.

Consider a scenario: your SBOM shows that your application uses a version of a JSON parsing library that has a known vulnerability. The SBOM has done its job — it has surfaced a potential risk. But is that vulnerability actually exploitable in your specific application? Does the code path that triggers the vulnerability exist in your implementation? Is the application configured in a way that allows exploitation?

Static analysis of your SBOM can identify the presence of a vulnerable component. It cannot confirm whether that component is actually exploitable in your deployed application. This is precisely the gap that dynamic application security testing (DAST) fills.

DAST tools like Invicti test your running application from the outside — the way an attacker would. Rather than inferring risk from component inventories, they actively probe the application for exploitable vulnerabilities and confirm findings with actual proof of exploitation. This proof-based approach eliminates the false positives that plague purely static approaches and gives security teams confidence that the vulnerabilities in their backlog are real.

Integrating SBOM and DAST in Your Security Programme

A mature application security programme uses both SBOM management and dynamic testing as complementary capabilities:

• SBOM for supply chain visibility. Your SBOM tooling (integrated into your CI/CD pipeline) automatically generates and updates component inventories as your software changes. Automated scanning against vulnerability databases (NVD, OSV, etc.) flags when a component version is associated with a known CVE.
• DAST for runtime validation. Your DAST platform tests the running application at regular intervals and as part of deployment pipelines. It confirms which vulnerabilities are actually exploitable in your environment, and surfaces runtime issues — such as authentication flaws, injection vulnerabilities, and business logic errors — that static component analysis cannot detect.
• Unified vulnerability management. Findings from both sources feed into a central vulnerability management workflow, where issues are prioritized by exploitability and business impact, assigned to owners, and tracked to remediation.

This layered approach addresses the full spectrum of application security risk: the risks that come from what your software is built from (SBOM), and the risks that emerge from how it behaves in practice (DAST).

Getting Started with SBOM

For organizations that are new to SBOM, the following steps provide a practical starting point:

1. 1Choose an SBOM format. For most organizations, CycloneDX is a good starting point — it has strong tooling support and is widely used in the security community. SPDX is the better choice if compliance with specific regulatory frameworks (particularly EU CRA) is the primary driver.
2. 2Integrate SBOM generation into your build pipeline. Tools like Syft, cdxgen, and Trivy can automatically generate SBOMs from build artifacts. Integrating this into your CI/CD pipeline ensures that SBOMs are always current and tied to specific software versions.
3. 3Automate vulnerability scanning against your SBOMs. Platforms like Grype or OWASP Dependency-Track ingest SBOMs and continuously check them against vulnerability databases, alerting you when new CVEs affect your dependencies.
4. 4Establish a remediation process. An SBOM that identifies vulnerabilities is only useful if there is a process for acting on that information. Define severity thresholds, assign ownership, and set SLAs for remediation.
5. 5Complement with dynamic testing. Deploy DAST scanning alongside your SBOM programme to validate runtime security and catch vulnerabilities that static component analysis cannot surface.

Conclusion

The shift toward mandatory SBOM requirements reflects a broader maturation in how regulators, enterprises, and security teams think about software risk. A software component you did not know you were running can still be exploited. Knowing what is in your software is the foundation on which everything else in application security is built.

But knowing what is in your software is only the beginning. Understanding how that software actually behaves under attack — and whether its vulnerabilities are genuinely exploitable — requires dynamic testing alongside your SBOM programme.

InitiumsTech helps European organizations implement both SBOM tooling and Invicti's DAST platform as part of a comprehensive application security strategy. If you are working through your CRA or NIS2 compliance requirements and want to understand how these pieces fit together, we are happy to walk through your specific situation.

Want to discuss your SBOM or application security strategy? Book a call with InitiumsTech.