A Software Bill of Materials (SBOM) is a machine-readable inventory of all components in your software. With the EU CRA and US EO 14028 making SBOMs mandatory for many organizations, getting your SBOM practice right is essential.
Choose the right format
Two formats dominate the SBOM ecosystem:
CycloneDX is an OASIS standard designed for security use cases. It has native support for vulnerability data, VEX, and licensing information. If your primary concern is vulnerability management, CycloneDX is the natural choice.
SPDX is a Linux Foundation standard with deep roots in open-source license compliance. It has broader adoption in the open-source ecosystem. If license compliance is your primary concern alongside security, SPDX offers stronger tooling in that area.
Both formats are accepted by CVEium CIS and by most regulatory frameworks.
Generate SBOMs in your build pipeline
The most accurate SBOMs are generated during the build process, when the exact dependency tree is known. Common tools include:
- Syft (Anchore): Works with container images, filesystems, and archives. Outputs CycloneDX and SPDX.
- Trivy (Aqua): Security scanner that can generate CycloneDX SBOMs alongside vulnerability reports.
- CycloneDX CLI: Official tooling with plugins for npm, Maven, Gradle, pip, Go, and more.
- SPDX Tools: Official SPDX generation for various ecosystems.
Integrate SBOM generation into your CI/CD pipeline so every release automatically produces an up-to-date SBOM.
Include Package URLs (PURLs)
Package URLs are the most reliable identifier for matching components to known vulnerabilities. A PURL encodes the ecosystem, namespace, name, and version:
pkg:npm/express@4.18.2 pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1 pkg:pypi/django@4.2.7
Ensure your SBOM generation tool captures PURLs for all components. Without PURLs, vulnerability matching falls back to less accurate name-based methods.
Keep SBOMs current
An SBOM is a snapshot. When you update dependencies, the SBOM must be regenerated. Best practices:
- Generate a new SBOM for every release
- Store SBOMs alongside release artifacts
- Compute and track file hashes for integrity
- Upload to CVEium CIS for continuous vulnerability monitoring
From SBOM to action
An SBOM alone is documentation. The real value comes from what you do with it:
- Scan against known CVEs to identify vulnerabilities
- Triage each match to determine actual impact on your product
- Communicate your findings through VEX documents
- Monitor continuously as new CVEs are published
This cycle — generate, scan, triage, communicate — is the foundation of proactive vulnerability management.