"SBOM: The Document Every Open Source Project Needs"
An SBOM is a structured inventory of every component in your software. It's required by EU CRA, useful for compliance, and takes 5 seconds to generate. Here's everything you need to know.
If someone asked you "what software is in your project?" could you answer? Most developers can name the top 5 dependencies. But a typical project has 200+ components — and nobody knows what they all are.
An SBOM (Software Bill of Materials) changes that. It's a structured document that lists every component, its version, its license, and its vulnerability status. Think of it as an ingredient label for your software.
What Is an SBOM?
An SBOM is a machine-readable document that inventories:
- All software components — direct and transitive dependencies
- Version numbers — exact versions of each component
- Package identifiers — unique IDs (PURL, CPE) for each component
- License information — which license each component uses
- Dependency relationships — what depends on what
- Known vulnerabilities — CVEs affecting each component
Without an SBOM, you're flying blind. You don't know what's in your software, what vulnerabilities it has, or what licenses you're using.
Why You Need an SBOM
1. Security
An SBOM tells you exactly which components have known vulnerabilities. When a new CVE is published, you can check your SBOM to see if you're affected.
2. Compliance
The EU Cyber Resilience Act requires SBOMs by 2027. The US Executive Order 14028 requires them for federal software. The FDA requires them for medical devices. SBOMs are becoming mandatory.
3. Incident Response
When a vulnerability is discovered, you need to know:
- Which of your products use the affected component?
- What version are they using?
- Which teams need to be notified?
An SBOM answers all three questions instantly.
4. Supply Chain Security
An SBOM documents your entire supply chain. When a dependency is compromised, you can immediately identify which projects are affected.
SBOM Formats
There are three main formats:
CycloneDX (OWASP)
- Security-focused
- Supports VEX (Vulnerability Exploitability eXchange)
- Compact JSON structure
- Best for vulnerability management
SPDX (Linux Foundation)
- ISO standard (ISO/IEC 5962:2021)
- Best for license compliance
- Widest regulatory acceptance
- More verbose but comprehensive
SWID (ISO)
- Software identification tags
- Lightweight, focused on identification
- Best for IT asset management
- Not a full SBOM
Recommendation: Use CycloneDX for security, SPDX for compliance. VulnLedger supports both.
How to Generate an SBOM
One Command
pip install vulnledger
vulnledger scan . --json --output sbom.json
This generates a CycloneDX SBOM in 5 seconds. It scans:
- Python packages (requirements.txt, pyproject.toml)
- JavaScript packages (package.json)
- Go modules (go.mod)
- Rust crates (Cargo.toml)
- Java dependencies (pom.xml)
- Docker images
In CI/CD
Add SBOM generation to every build:
- name: Generate SBOM
run: |
pip install vulnledger
vulnledger scan . --json --output sbom.json
In the Dashboard
VulnLedger's web dashboard generates SBOMs automatically on every scan. No CLI needed.
What an SBOM Looks Like
Here's a simplified CycloneDX SBOM:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{
"name": "requests",
"version": "2.31.0",
"purl": "pkg:pypi/[email protected]",
"type": "library",
"licenses": [{"id": "Apache-2.0"}]
},
{
"name": "flask",
"version": "3.0.0",
"purl": "pkg:pypi/[email protected]",
"type": "library",
"licenses": [{"id": "BSD-3-Clause"}]
}
],
"vulnerabilities": [
{
"id": "CVE-2024-1234",
"severity": "high",
"description": "Remote code execution in requests",
"affects": [{"ref": "pkg:pypi/[email protected]"}]
}
]
}
SBOM Best Practices
1. Generate on Every Build
Don't generate SBOMs manually. Add to CI/CD:
- run: vulnledger scan . --json --output sbom.json
2. Store with Releases
Attach SBOMs to GitHub releases:
- uses: softprops/action-gh-release@v2
with:
files: sbom.json
3. Version Your SBOMs
Each release gets a new SBOM. Track changes between versions.
4. Share with Stakeholders
Customers, auditors, and partners may request your SBOM. Make it easy to share.
5. Monitor Continuously
An SBOM from January is useless if new CVEs are published in March. Set up daily scans.
SBOM and the EU CRA
The EU Cyber Resilience Act requires:
- SBOMs for all digital products sold in the EU
- Machine-readable format (CycloneDX or SPDX)
- Include all components with versions
- Maintain and update throughout product lifecycle
- Provide to authorities upon request
Deadline: January 2027 for all products.
How VulnLedger Helps
VulnLedger generates SBOMs automatically:
# One command
vulnledger scan . --json --output sbom.json
# Or use the dashboard for automatic SBOM generation
The SBOM includes:
- Every dependency (direct and transitive)
- Version numbers and package URLs
- License information
- Known vulnerabilities
- Dependency relationships
Conclusion
An SBOM is the foundation of software security and compliance. Without it, you don't know what's in your software, what vulnerabilities it has, or what licenses you're using. Generating one takes 5 seconds. Not having one can cost millions in fines and breached trust.
Previous: How to Audit Your Open Source Dependencies