December 2021. A security researcher publishes information about a critical vulnerability in the Log4j library - Log4Shell, CVSSv3 10.0, the highest possible rating. Within hours, attackers begin mass exploitation. Companies worldwide panic: “Do we use Log4j? Where? In which systems?”
The problem: most organizations didn’t know. Log4j is a dependency included in thousands of applications, often as a transitive dependency (a dependency of a dependency). Teams spent days, weeks manually searching repositories, checking CI/CD pipelines, calling vendors. Some never got a complete answer. This was a truth moment for the industry: we don’t have visibility into what makes up our software.
Software Bill of Materials (SBOM) is the answer. A list of all components, libraries, dependencies that make up an application - with versions, licenses, sources of origin. Like an ingredients list on food packaging, only for software.
What exactly is SBOM and why has it become a necessity?
SBOM is a machine-readable inventory. Not a PDF with a list of libraries. A structured format (SPDX, CycloneDX) that tools can parse automatically. It contains: component name, version, supplier/author, license type, hashes for integrity verification, relationships between components (what depends on what).
Supply chain attack surface has exploded. The average enterprise application has 500+ dependencies (direct and transitive). Each dependency is a potential attack vector. SolarWinds, Codecov, event-stream, ua-parser-js - supply chain attacks are becoming more frequent and more effective.
Regulatory pressure is growing. US Executive Order 14028 (2021) requires SBOM for software sold to the federal government. EU Cyber Resilience Act (CRA) introduces SBOM requirements for products with digital elements sold in the EU. This isn’t a suggestion - it’s law.
Enterprise clients are starting to require it. Large corporations, especially in regulated sectors (finance, healthcare, critical infrastructure), are starting to require SBOM from software suppliers as part of due diligence. No SBOM = no contract.
Incident response without SBOM is blind. When a new CVE appears - how quickly can you answer if you’re affected? Without SBOM - you search manually, for hours, days. With SBOM - query the database, answer in seconds.
What problems does SBOM actually solve?
Visibility into transitive dependencies. Your code uses library A, which uses B, which uses C. Do you know what’s in C? How many vulnerabilities does it have? What license does it have? Without SBOM - you don’t know. With SBOM - everything is explicit.
Vulnerability management at scale. When NVD publishes a new CVE, you can automatically check all your applications: “which of my systems use this component in this version?” Prioritization becomes possible.
License compliance. Open source has different licenses: MIT, Apache 2.0, GPL, AGPL. Some require attribution, some copyleft (derivative works must be open source). SBOM allows automatic checking whether you’re violating licenses.
Audit trail and provenance. Where does this component come from? Who built it? Does the checksum match what we downloaded? SBOM with cryptographic signatures gives assurance that components haven’t been modified.
Supplier risk assessment. If a vendor delivers software with SBOM - you can assess risk: how many known CVEs does it have in dependencies, does it use deprecated libraries, what does maintenance of these components look like.
Merger & Acquisition due diligence. Buying a company = buying its technical debt and security debt. SBOM allows you to assess exactly what you’re buying before signing the agreement.
What SBOM formats are used and which to choose?
SPDX (Software Package Data Exchange). ISO/IEC 5962:2021 standard. Developed by Linux Foundation. Focuses on licensing and compliance. Widely supported, mature. Formats: JSON, RDF, XML, YAML, tag-value.
CycloneDX. OWASP standard. Focuses on security and vulnerability tracking. More security-centric than SPDX. Native support for VEX (Vulnerability Exploitability eXchange). Formats: JSON, XML, Protocol Buffers.
SWID Tags (Software Identification). ISO/IEC 19770-2. Older standard, used mainly in enterprise asset management. Less adoption in security community than SPDX/CycloneDX.
Which to choose? For most organizations the recommendation is: CycloneDX if the main focus is security and vulnerability management, SPDX if the main focus is compliance and licensing. Both are interoperable - tools can convert between formats.
Trend: convergence and interoperability. SPDX 3.0 and CycloneDX 1.5+ are converging in functionality. Tools support both. Format choice is less critical than the fact of having an SBOM.
How to generate SBOM in practice?
Build-time generation (recommended). SBOM generated during the application build process, when the dependency resolver has full knowledge of what’s being used. Most accurate source of truth.
Tools per ecosystem:
- Maven (Java): CycloneDX Maven Plugin, SPDX Maven Plugin
- npm (JavaScript): @cyclonedx/bom, npm-sbom
- pip (Python): cyclonedx-bom, pip-licenses
- Go: cyclonedx-gomod, spdx-sbom-generator
- NuGet (.NET): CycloneDX module for .NET
- Cargo (Rust): cargo-cyclonedx, cargo-spdx
Container image analysis. For containers - tools like Syft, Trivy, Grype scan image layers and generate SBOM of container contents (OS packages + application dependencies).
Binary analysis (SCA tools). If you don’t have access to source code - Software Composition Analysis tools (Snyk, Checkmarx SCA, Black Duck) can analyze binaries and try to recreate SBOM. Less accurate than build-time, but better than nothing.
Integration with CI/CD. SBOM should be generated automatically with every build and stored as an artifact alongside the release. Jenkins, GitHub Actions, GitLab CI, Azure DevOps - all have plugin/action support.
How to manage SBOM after generation?
Central SBOM repository. Don’t generate SBOM and forget. You need a place where all SBOMs are stored, versioned, queryable. Dependency-Track (OWASP, open source) is a popular choice.
Continuous monitoring. When a new CVE is published, the system automatically checks all SBOMs and alerts if affected components are found. Dependency-Track, Snyk, Sonatype Nexus Lifecycle offer this functionality.
Policy enforcement. Define policy: “we don’t accept dependencies with known critical CVEs”, “we don’t accept GPL licensed libraries in our proprietary software”. Tools automatically flag violations.
SBOM lifecycle management. Application changes, dependencies change, SBOM must be updated. Old SBOM is false sense of security. Each release = new SBOM.
Sharing and distribution. How do you deliver SBOM to customers? As attachment to release notes? As separate download? Embedded in product? Industry standards are still being shaped, but transparency is the direction.
What challenges do organizations face when implementing SBOM?
Incomplete dependencies. Not every dependency is explicitly declared. Native libraries linked statically, vendored dependencies copied to repo, build tools that aren’t part of runtime - SBOM may be incomplete.
Transitive dependencies depth. Dependency tree can have dozens of levels deep. Tools handle deep trees differently. Testing and validation needed.
Legacy applications. Applications written 15 years ago, without modern build systems, without package managers - generating SBOM is difficult or impossible. Binary analysis can help, but isn’t perfect.
Proprietary third-party software. If you use closed-source components from a vendor - you may not have SBOM (vendor doesn’t provide it) nor ability to generate (no source code). This is a visibility gap.
False positives and noise. Vulnerability scanning tools based on SBOM can generate many alerts, including false positives (CVE doesn’t apply to your usage pattern) or low-risk issues. Triage requires human judgment.
Naming inconsistency. The same component may have different names in different ecosystems. Matching CVE to component requires name normalization (CPE, PURL). Doesn’t always work perfectly.
How does EU Cyber Resilience Act change the SBOM landscape?
CRA scope. CRA applies to “products with digital elements” sold in the EU market. Software, hardware with embedded software, IoT devices. Practically anything with code.
SBOM as requirement. CRA requires manufacturers to provide SBOM at least for direct dependencies. Must be in machine-readable format (SPDX or equivalent). Must contain top-level dependencies.
Vulnerability handling obligations. Manufacturer must: identify and document vulnerabilities, provide security updates, inform ENISA about exploited vulnerabilities within 24h. SBOM is the foundation of these processes.
Penalties for non-compliance. Up to 15 million EUR or 2.5% of global turnover (whichever is higher). This is serious enforcement, not theoretical threat.
Timeline. CRA enters into force in 2027 with transition period. Companies should start preparations now - implementing SBOM generation and vulnerability management takes time.
Implications for software vendors. If you sell software in the EU - you must have SBOM capability. If you buy software - you can require SBOM from vendors as part of procurement.
How does SBOM affect vulnerability management workflow?
Shift from “where is it?” to “what do we do about it?”. With SBOM, identification of affected systems is automatic. Effort moves to: prioritization, remediation planning, patching execution.
Risk-based prioritization. Not every CVE requires immediate action. SBOM + VEX (Vulnerability Exploitability eXchange) allows determining: is this CVE exploitable in our context? Is it reachable? Do we have compensating controls?
Remediation tracking. SBOM shows where to update dependency. Tracking: when patch was available, when deployed, in which systems still waiting. Metrics for improvement.
Vendor communication. If CVE is in vendor-supplied component - you have SBOM as evidence. “Your library X in version Y has CVE-Z, when will patch be available?” Concrete conversation, not “you probably use it somewhere”.
Compliance evidence. Auditors ask: “how do you manage vulnerabilities in third-party components?” SBOM + vulnerability scanning reports + remediation records = evidence.
How to build an SBOM program in an organization?
Phase 1: Pilot (3-6 months). Choose 2-3 applications with different tech stacks. Implement SBOM generation in CI/CD. Integrate with vulnerability scanning (Trivy, Grype, Dependency-Track). Learn tooling and processes.
Phase 2: Expansion (6-12 months). Expand to all new projects. Define SBOM policy (when to generate, where to store, who has access). Integrate with existing security workflows.
Phase 3: Legacy inclusion (12-18 months). Tackle legacy applications. Where possible - add build-time generation. Where impossible - binary analysis. Accept that coverage won’t be 100%.
Phase 4: Maturity (18+ months). Automated policy enforcement. SBOM sharing with customers/partners. Metrics and reporting. Continuous improvement.
Roles and responsibilities. Security team: vulnerability monitoring, policy definition. Development teams: SBOM generation integration, remediation. Procurement: vendor SBOM requirements. Legal: license compliance.
What tools make up the SBOM ecosystem?
SBOM Generation:
- Syft (Anchore): multi-format, multi-ecosystem, containers, filesystems
- Trivy (Aqua Security): scanner + SBOM generation, k8s native
- cdxgen: CycloneDX generator, multiple languages
- Tern: container image inspection
Management and Analysis:
- Dependency-Track (OWASP): vulnerability tracking, policy management, free/open source
- Sonatype Nexus Lifecycle: enterprise SCA with SBOM support
- Snyk: developer-friendly SCA + SBOM
- Anchore Enterprise: container security + SBOM management
Vulnerability Scanning Based on SBOM:
- Grype (Anchore): vulnerability scanner using SBOMs
- OSV-Scanner (Google): open source vulnerability database scanner
- Trivy: scanner that can consume SBOM as input
SBOM Validation and Compliance:
- SBOM-Tool (Microsoft): SBOM generation and validation
- ntia-conformance-checker: validates SBOM against NTIA minimum elements
- CycloneDX validator, SPDX validator
Table: SBOM implementation roadmap for organizations
| Phase | Actions | Tools | KPIs | Timeline |
|---|---|---|---|---|
| 1. Assessment | Application and tech stack inventory | Spreadsheet, asset management | % applications mapped | Month 1-2 |
| 1. Assessment | SBOM tool evaluation for each stack | PoC with Syft, cdxgen, ecosystem-specific tools | Tools selected per stack | Month 1-2 |
| 2. Pilot | SBOM generation for 2-3 pilot applications | Selected generators + Dependency-Track | SBOM generated, vulnerability alerts working | Month 3-4 |
| 2. Pilot | Integration with CI/CD pipeline | Jenkins/GitHub Actions/GitLab CI plugins | SBOM generated automatically with each build | Month 4-5 |
| 3. Policy | Policy definition (blocked licenses, max CVE severity) | Dependency-Track policy engine | Policy defined and documented | Month 5-6 |
| 3. Policy | Training for development teams | Workshops, documentation | 100% dev teams trained | Month 6-7 |
| 4. Rollout | Expansion to all active projects | Same tooling, templated pipelines | % projects with SBOM coverage | Month 7-12 |
| 4. Rollout | Legacy application assessment | Binary analysis (Syft on filesystems) | % legacy apps with partial SBOM | Month 8-14 |
| 5. Operations | Vulnerability monitoring and alerting | Dependency-Track + alerting integration | MTTR for critical vulnerabilities | Ongoing |
| 5. Operations | Vendor SBOM requirements in procurement | Updated procurement templates | % new vendors providing SBOM | Ongoing |
| 6. Maturity | SBOM sharing with customers | Distribution mechanism, documentation | % customers receiving SBOM | Month 18+ |
| 6. Maturity | Compliance reporting for CRA | Automated reports, audit evidence | Compliance readiness score | Month 18+ |
SBOM isn’t another buzzword to ignore - it’s a fundamental change in how we manage software supply chain. Log4Shell was a wake-up call. Regulations like EU Cyber Resilience Act are transforming SBOM from “nice to have” to “must have”.
Key takeaways:
- SBOM gives visibility into what makes up your software - without it you’re blind
- EU CRA requires SBOM from 2027 - time to start preparations now
- Build-time generation is most accurate - integrate with CI/CD
- Generation alone isn’t enough - you need continuous monitoring and vulnerability management
- Format choice (SPDX vs CycloneDX) is less critical than having an SBOM
- Legacy applications are challenging - binary analysis helps but isn’t perfect
- SBOM program requires time and resources - start small, expand gradually
Organizations that invest in SBOM now will have an advantage: faster incident response, easier compliance, better position in conversations with enterprise clients. Those who delay - will pay a higher price later.
ARDURA Consulting supports organizations in building software supply chain security programs. Our DevSecOps specialists help implement SBOM generation, vulnerability management, and compliance frameworks. Let’s talk about securing your software supply chain.