SBOM Generator

What Is an SBOM (Software Bill of Materials)

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and dependencies that make up a software application. Just as a physical product has a bill of materials listing every part and sub-assembly, an SBOM catalogs every open-source library, commercial component, and internally developed module in your software.

SBOMs have become essential for software supply chain security. The 2021 Executive Order on Improving the Nation's Cybersecurity (EO 14028) mandated SBOMs for software sold to the U.S. federal government, and industry adoption is accelerating as organizations seek to manage the risk posed by vulnerabilities in third-party components (as demonstrated by Log4Shell, Spring4Shell, and the xz Utils backdoor).

SBOM Formats

Format	Maintained By	Strengths	Common Use
SPDX	Linux Foundation	ISO standard (ISO/IEC 5962), comprehensive licensing	Open-source compliance, government
CycloneDX	OWASP	Security-focused, supports VEX, lightweight	Application security, DevSecOps
SWID Tags	ISO/IEC 19770-2	Software identification, asset management	Enterprise IT asset management

What an SBOM Contains

Field	Description	Example
Component name	Package or library name	express
Version	Specific version used	4.18.2
Supplier	Who provides the component	npm/expressjs
License	Software license	MIT
Hash	Cryptographic hash for integrity	SHA-256: a1b2c3...
Dependencies	Components this component depends on	accepts, body-parser, ...
CPE/PURL	Standard identifier for vulnerability matching	pkg:npm/[email protected]

Common Use Cases

• Vulnerability management: When a new CVE is published, search your SBOMs to instantly determine which applications are affected and need patching
• License compliance: Identify all open-source licenses in your software to ensure compliance with license obligations (GPL, LGPL, AGPL reciprocal requirements)
• Supply chain security: Monitor components for known vulnerabilities, malicious packages, and end-of-life status across your entire software portfolio
• Government compliance: Meet SBOM requirements for federal software procurement under EO 14028 and CISA guidance
• Vendor risk assessment: Request SBOMs from software vendors to evaluate the security and licensing risk of their products before procurement

Best Practices

1. Generate SBOMs automatically in CI/CD — Manual SBOM creation is unsustainable and error-prone. Use tools like Syft, Trivy, or CycloneDX plugins in your build pipeline to generate SBOMs automatically.
2. Include transitive dependencies — Your application may directly use 20 packages, but those packages depend on hundreds more. A complete SBOM includes the entire dependency tree.
3. Update SBOMs with every release — SBOMs are snapshots. Generate a new SBOM for every software release and store it alongside the release artifacts.
4. Monitor for new vulnerabilities continuously — Generate the SBOM once, but monitor it continuously. New CVEs are published daily for existing components.
5. Use VEX for vulnerability status — Vulnerability Exploitability eXchange (VEX) documents supplement SBOMs by indicating whether a known vulnerability actually affects your specific usage of a component.