SBOM (Software Bill of Materials) has become in 2026 one of the critical artifacts of cybersecurity. Imposed by U.S. authorities (Executive Order 14028) and increasingly required in Europe via the Cyber Resilience Act, it lists all software components that make up an application, including third-party and open source libraries.
Why SBOM has become critical
Three elements have made SBOM unavoidable: supply chain attacks (SolarWinds, Log4j, XZ Utils) which demonstrated that a single compromised component can affect thousands of organizations; the inflation of open source dependencies (a modern application contains on average 80% third-party code); regulatory requirements that now mandate component traceability.
The 3 priority use cases
- Rapid response to a critical CVE: when a critical CVE drops (Log4Shell type), the SBOM lets you know in minutes, not days, which applications in your fleet are vulnerable.
- Vendor compliance: before purchasing software, requiring its SBOM lets you verify that components are up to date, without unpatched critical CVEs, and without problematic licenses.
- M&A due diligence: during an acquisition, the SBOM of acquired products reveals the true state of security debt, what questionnaires don't show.
For the vendor side specifically, see our practical guide on how to get an SBOM from your third-party software vendors: what to request, contract wording, and the red flags to watch for.
How to start in 4 steps
- Choose a standard format: CycloneDX (OWASP) or SPDX (Linux Foundation), not a proprietary format.
- Automate generation: integrate tools like Syft, Trivy or Anchore in your CI/CD pipeline.
- Store and version: one SBOM per application version, kept in a central repository.
- Connect to your CVE intelligence: cross-reference SBOM and CVE feeds to generate contextualized alerts.
Without an SBOM, your incident response is blind. With one, it becomes surgical.