-
Notifications
You must be signed in to change notification settings - Fork 0
7. SBOM
SBOM (Software Bill of Materials) is a detailed list of all components, dependencies, and libraries used in a software application or container image. It helps track, analyze, and manage security risks by providing full transparency into what is inside your software.
Think of an SBOM as an ingredient list for software—it tells you exactly what goes into your application, including:
- System libraries
- Open-source dependencies
- Proprietary software components
- Version numbers
- Licensing information
SBOMs are critical for security, compliance, and risk management. Here’s why:
- Helps identify known vulnerabilities (CVEs) in dependencies.
- Makes it easier to patch or update insecure packages.
- If a security flaw (e.g., Log4j) is discovered, an SBOM tells you whether you're affected.
Example:
- If a package like
openssl-1.1.1has a critical vulnerability, an SBOM will list it, allowing quick response.
- Many software components have licenses (MIT, GPL, Apache, etc.).
- SBOM ensures that all dependencies comply with legal requirements.
- Helps with government regulations like U.S. Executive Order 14028, requiring SBOMs for software security.
Example:
- If your project mistakenly includes a GPL-licensed library (which has strict usage terms), SBOM flags it early.
- SBOM provides a trusted, verifiable record of software components.
- Prevents supply chain attacks (e.g., malicious dependencies in NPM, PyPI, etc.).
- If an attacker injects a backdoor into a package, an SBOM helps verify if your software is affected.
Example:
- If an attacker inserts a malicious package (
log4shellexploit in Log4j), SBOM helps identify and remove it quickly.
- When a zero-day vulnerability is announced, teams can immediately check their SBOM instead of manually inspecting every component.
- Reduces downtime and accelerates incident response.
Example:
- If a CVE (security flaw) is found in
openssl-1.1.1, an SBOM helps security teams identify and fix affected systems immediately.
- SBOMs use standard formats (like SPDX, CycloneDX) that are machine-readable.
- Helps DevSecOps teams, security scanners, and auditors analyze dependencies consistently.
SBOMs are automatically generated using tools like:
- Apko / Melange (for container images)
- Syft (for general SBOM scanning)
- Trivy (security & vulnerability scanning)
- SPDX (open-source SBOM format)
- CycloneDX (another widely-used format)
Example: Generating an SBOM with Apko
apko build --sbom apko.yaml my-image:latest my-image.tar✅ This creates an SBOM alongside the container image.
{
"name": "my-container-image",
"spdxVersion": "SPDX-2.2",
"packages": [
{
"name": "busybox",
"versionInfo": "1.35.0-r29",
"license": "GPL-2.0",
"supplier": "Alpine Linux"
},
{
"name": "openssl",
"versionInfo": "1.1.1n",
"license": "OpenSSL",
"supplier": "Alpine Linux"
}
]
}This SBOM tells us:
- The image contains BusyBox and OpenSSL.
- Exact versions are recorded.
- Licenses are specified (GPL, OpenSSL).
- If a security vulnerability is found in OpenSSL 1.1.1n, we know where it's used.
| Feature | Without SBOM ❌ | With SBOM ✅ |
|---|---|---|
| Tracks all dependencies | ❌ No | ✅ Yes |
| Quick vulnerability detection | ❌ Manual | ✅ Automated |
| License compliance check | ❌ Risky | ✅ Ensured |
| Fast incident response | ❌ Slow | ✅ Immediate |
| Supply chain security | ❌ Weak | ✅ Strong |
✅ Increases security by detecting vulnerabilities early.
✅ Ensures compliance by tracking software licenses.
✅ Improves supply chain security by verifying all dependencies.
✅ Accelerates incident response when vulnerabilities are discovered.
✅ Reduces risk by preventing unknown software components.
SBOM is becoming a mandatory security standard in modern software development. 🚀