SBOM Generator
Generate Software Bill of Materials in CycloneDX and SPDX formats. Parse package.json, requirements.txt, Cargo.toml, go.mod, pom.xml, and more.
Understanding Software Bill of Materials
A Software Bill of Materials (SBOM) is a formal, structured list of components, libraries, and modules that make up a piece of software. Think of it as an ingredients list for your application - it tells you exactly what software components you are depending on.
š
Visibility
Know exactly what third-party code you are shipping. Identify all direct and transitive dependencies in your software supply chain.
š”ļø
Security
Quickly respond to vulnerability disclosures by knowing which components are affected. Enable automated vulnerability scanning and patch management.
āļø
Compliance
Meet regulatory requirements (EO 14028) and industry standards. Track license obligations to avoid legal issues with open source usage.
SBOM Standards Comparison
Feature CycloneDX SPDX
Organization OWASP Linux Foundation
Primary Focus Security & DevSecOps License Compliance
Formats JSON, XML, Protobuf JSON, RDF, Tag-Value
ISO Standard ECMA-424 ISO/IEC 5962:2021
Vulnerability Support Native (VEX, VDR) Via Extensions
Services/APIs Supported Limited
Executive Order 14028 Requirements
Executive Order 14028 "Improving the Nation's Cybersecurity" mandates SBOM requirements for software sold to the U.S. federal government:
-
Machine-Readable Format: SBOMs must be in standard formats (CycloneDX or SPDX)
-
NTIA Minimum Elements: Include supplier name, component name, version, unique identifiers, dependency relationships, author, and timestamp
-
Automation: SBOMs should be generated automatically during build process
-
Updates: New SBOM required for each software release or update
Best Practices for SBOM Management
-
DO Automate SBOM generation in your CI/CD pipeline for every build
-
DO Include transitive dependencies - not just direct dependencies
-
DO Version your SBOMs and maintain historical records
-
DO Integrate with vulnerability databases for continuous monitoring
-
DON'T Rely on manual processes - SBOMs get outdated quickly
-
DON'T Ignore license information - it's critical for compliance
Software Supply Chain Security
Our DevSecOps team implements SBOM generation, dependency scanning, and supply chain security for EO 14028 compliance.
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/express@4.18.2 |
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
- 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.
- 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.
- Update SBOMs with every release ā SBOMs are snapshots. Generate a new SBOM for every software release and store it alongside the release artifacts.
- Monitor for new vulnerabilities continuously ā Generate the SBOM once, but monitor it continuously. New CVEs are published daily for existing components.
- 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.
Frequently Asked Questions
Common questions about the SBOM Generator
A Software Bill of Materials (SBOM) is a comprehensive inventory of all components, libraries, and dependencies that make up a software application. SBOMs are essential for software supply chain security, enabling organizations to quickly identify vulnerable components, meet regulatory requirements, and manage licensing compliance.
The tool supports common dependency file formats including package.json and package-lock.json for Node.js/JavaScript projects, requirements.txt and Pipfile for Python projects, go.mod for Go projects, pom.xml for Java/Maven projects, and Cargo.toml for Rust projects. Simply paste or upload your dependency file to get started.
The tool generates SBOMs in industry-standard formats including CycloneDX (JSON and XML) and SPDX (JSON and tag-value). CycloneDX is widely used in DevSecOps pipelines, while SPDX is an ISO standard commonly used for license compliance. Choose the format that matches your tooling and compliance requirements.
The tool cross-references your dependencies against known vulnerability databases to identify components with security issues. It displays vulnerability severity levels and CVE identifiers, helping you prioritize remediation efforts. This is a static analysis based on version matching and does not require network access to your codebase.
The generated SBOM includes license information for each component when available from the dependency file. The license analysis view helps you identify components using various open-source licenses, making it easier to ensure compliance with your organization license policies and legal requirements.
Yes, all SBOM generation happens entirely in your browser. Your dependency files are processed client-side using JavaScript and are never uploaded to any server. The generated SBOM remains on your device until you choose to download or copy it.
ā¹ļø Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.