What Is an SBOM and Why Your Security Team Needs One

Your application has 1,247 dependencies. Can you name them? Can you tell your auditor which licenses they use? Can you check in 30 seconds whether any of them are affected by the latest critical CVE?

If not, you need a Software Bill of Materials.

What Is an SBOM?

An SBOM (Software Bill of Materials) is a comprehensive inventory of every component in your software — libraries, frameworks, packages, and their dependencies. Think of it as a nutrition label for code.

An SBOM entry for a single component includes:

Package name (e.g., lodash)

Version (e.g., 4.17.21)

Supplier (e.g., npm)

License (e.g., MIT)

Hash/checksum for integrity verification

Dependency relationships (what depends on what)

Why SBOMs Matter Now

Three converging forces made SBOMs go from "nice-to-have" to "required":

1. Regulatory Mandates

US Executive Order 14028 (2021) — Requires software suppliers to the federal government to provide SBOMs. If you sell to any US government agency, you need SBOMs.

EU Cyber Resilience Act (2024) — Products sold in the EU must include vulnerability disclosure capabilities and machine-readable SBOMs.

FedRAMP — Cloud service providers seeking FedRAMP authorization must document software components and their supply chain.

2. Supply Chain Attacks

The SolarWinds attack, Log4Shell, and the XZ Utils backdoor all demonstrated that attackers target dependencies, not just your code. When Log4Shell dropped, organizations with SBOMs identified affected systems in hours. Organizations without SBOMs took weeks.

3. Compliance Frameworks

SOC 2 — Trust Services Criteria CC7.1 requires organizations to "identify and manage the inventory of components." SBOMs satisfy this control directly.

ISO 27001 — A.12.6.1 requires technical vulnerability management of all software components.

PCI DSS 4.0 — Requirement 6.3.2 requires an inventory of bespoke and custom software, and all third-party components.

SBOM Formats

Two dominant standards:

SPDX (ISO/IEC 5962)

Developed by the Linux Foundation. Full ISO standard. Strongest for license compliance and legal requirements.

{
  "spdxVersion": "SPDX-2.3",
  "name": "myapp",
  "packages": [
    {
      "name": "express",
      "versionInfo": "4.18.2",
      "supplier": "Organization: npm",
      "licenseConcluded": "MIT"
    }
  ]
}

CycloneDX (OWASP)

Developed by OWASP. Designed for security use cases. Best for vulnerability correlation and runtime analysis.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "licenses": [{"license": {"id": "MIT"}}]
    }
  ]
}

Which Format to Choose?

| Use Case | Recommended Format |

|----------|-------------------|

| License compliance / legal | SPDX |

| Vulnerability management | CycloneDX |

| Government compliance | SPDX (ISO standard) |

| General purpose | Either — both work |

How to Generate SBOMs

Syft (Recommended)

Anchore's Syft is the most versatile SBOM generator:

# Container image
syft myapp:latest -o spdx-json > sbom.spdx.json
# Source directory
syft dir:./my-project -o cyclonedx-json > sbom.cdx.json
# Filesystem
syft file:/path/to/binary -o spdx-json > sbom.spdx.json

Trivy

Aqua's Trivy can generate SBOMs alongside vulnerability scans:

trivy image --format spdx myapp:latest > sbom.spdx

Language-Specific Tools

npm: npm sbom --sbom-format cyclonedx

pip: cyclonedx-py or pip-audit

Go: cyclonedx-gomod

Using SBOMs for Vulnerability Management

Generating an SBOM is step one. The real value comes from continuous monitoring:

1. Scan SBOM Against Vulnerability Databases

# Scan an existing SBOM with Grype
grype sbom:sbom.cdx.json

This tells you which components in your SBOM have known CVEs — without re-scanning the entire image.

2. Monitor for New Disclosures

When a new CVE is published, query your SBOM inventory to find every application, service, and container that includes the affected component.

3. Diff SBOMs Between Versions

Compare SBOMs from v1.0 and v2.0 to see exactly what changed — new dependencies, removed packages, version upgrades. This is your change audit trail.

SBOM Best Practices

Generate with every build — SBOMs should be a CI/CD artifact, created automatically

Store alongside your artifacts — SBOM goes in the same registry as your container image

Use machine-readable formats — JSON, not PDF. Automated tools need to parse them

Include transitive dependencies — Direct deps aren't enough; most vulnerabilities are in transitive deps

Update on every release — Stale SBOMs are worse than no SBOM (false sense of security)

Correlate with vulnerability data — An SBOM without vulnerability scanning is just an inventory

How Vulnios Handles SBOMs

When you scan a container image or repository with Vulnios:

Syft generates the SBOM automatically as part of the multi-engine scan

Grype scans the SBOM for known vulnerabilities

Results merge into the unified findings view with EPSS + CVSS prioritization

Export your SBOM in SPDX or CycloneDX format with one click

No manual configuration. No separate tool.

---

Generate your first SBOM at vulnios.com. Automatic SBOM generation + vulnerability scanning in one platform.