SBOM Best Practices
A Software Bill of Materials (SBOM) is foundational to modern product security. Learn how to generate high-quality SBOMs, keep them current, and use them effectively for vulnerability management and regulatory compliance.
What You'll Learn
Why SBOMs Matter
An SBOM is a complete inventory of all software components in your product—including open-source libraries, third-party SDKs, and proprietary code. The FDA now requires SBOMs for medical device submissions, and they're becoming standard for any connected product. A good SBOM enables you to quickly identify which products are affected when new vulnerabilities are disclosed.
Generating Quality SBOMs
The quality of your SBOM depends on how it's generated. Different tools and approaches have different strengths.
Generation Methods
Generate SBOMs during your build process using dependency manifests (package.json, requirements.txt, pom.xml, etc.). This captures exactly what's included in each build.
Tools: Syft, CycloneDX plugins (Maven, npm, pip), SPDX tools
Scan container images or compiled binaries to discover components. Good for verifying build-time SBOMs or analyzing third-party software.
Tools: Syft, Trivy, Grype, FOSSA
For components that can't be automatically detected—proprietary libraries, firmware blobs, or commercial SDKs without package managers.
When needed: Embedded systems, legacy code, commercial libraries
Best Practice: Combine methods. Use build-time generation as your baseline, verify with container scanning, and manually add components that tooling misses.
Choosing the Right Format
Two formats dominate the SBOM landscape. Both are acceptable for FDA submissions.
CycloneDX
OWASP standard designed for security use cases. Includes native support for vulnerabilities (VEX), services, and licensing.
✓ Recommended for Product Security Hub
SPDX
Linux Foundation standard with strong focus on licensing compliance. ISO/IEC 5962:2021 certified.
Good for license compliance workflows
FDA Guidance: The FDA accepts both CycloneDX and SPDX formats. Choose based on your toolchain and downstream use cases. CycloneDX is often preferred for security-focused workflows.
Essential SBOM Data Fields
Not all SBOMs are created equal. The value of your SBOM depends on the quality and completeness of component data.
Required Fields
| Field | Why It Matters | Example |
|---|---|---|
| Component Name | Identifies what the component is | lodash |
| Version | Critical for vulnerability matching | 4.17.21 |
| Supplier/Vendor | Distinguishes components with same name | Lodash contributors |
| Component Type | Library, framework, OS, firmware, etc. | library |
Highly Recommended Fields
| Field | Why It Matters | Example |
|---|---|---|
| PURL | Package URL for precise identification | pkg:npm/lodash@4.17.21 |
| CPE | Common Platform Enumeration for NVD matching | cpe:2.3:a:lodash:lodash:4.17.21 |
| License | Compliance and legal review | MIT |
| Hash/Checksum | Verifies component integrity | sha256:abc123... |
Common Pitfall: Missing or incorrect version numbers drastically reduce SBOM value. A vulnerability scanner can't match CVEs to components without accurate versions. Always verify version data is present and correct.
Improving Vulnerability Matching
The primary use case for SBOMs is identifying which vulnerabilities affect your products. Accurate matching requires good component identifiers.
Use Package URLs (PURLs)
PURLs are the most reliable identifier for vulnerability matching because they encode the package ecosystem, name, and version in a standardized format.
pkg:pypi/django@4.2.1
pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1
Add CPEs for legacy/commercial software
CPEs (Common Platform Enumeration) are used by the NVD and are essential for matching vulnerabilities in commercial software, operating systems, and firmware.
cpe:2.3:a:openssl:openssl:1.1.1k:*:*:*:*:*:*:*
Include transitive dependencies
Your SBOM should include not just direct dependencies but also their dependencies (transitive). Many critical vulnerabilities (like Log4Shell) are in transitive dependencies that aren't obvious from your manifest files.
In Product Security Hub: When you import a CycloneDX SBOM, components are automatically scanned against OSV, NVD, and GitHub Advisories. PURLs and CPEs in your SBOM improve matching accuracy.
SBOM Lifecycle Management
An SBOM is a living document that should be updated throughout your product lifecycle.
Development
Generate SBOMs during CI/CD builds. Track SBOM changes alongside code changes. Use SBOMs to review new dependencies before they're merged.
Release
Generate a final SBOM for each release version. Archive it alongside the release artifacts. This becomes your official record for that version.
Submission
Include SBOM in FDA premarket submissions. Ensure it's in machine-readable format (CycloneDX JSON or SPDX). Provide human-readable version if requested.
Post-Market
Continuously monitor SBOM components for new vulnerabilities. When vulnerabilities are disclosed, you should be able to quickly identify affected products.
Updates & Patches
Regenerate SBOM for each update. Document what changed (components added, removed, or upgraded). Communicate SBOM updates to customers as needed.
In Product Security Hub: Use product versioning to maintain separate SBOMs for each release. Clone products to create new versions—the SBOM carries forward, and you only need to update what changed.
Handling Supplier SBOMs
If your product includes third-party components (SDKs, libraries, firmware), you need to incorporate their SBOMs into yours.
Request SBOMs from suppliers
Add SBOM requirements to your procurement process. Suppliers should provide SBOMs in CycloneDX or SPDX format for any software they deliver.
Validate supplier SBOMs
Check that supplier SBOMs meet minimum data quality requirements. Verify versions are present, identifiers are accurate, and the SBOM is reasonably complete.
Merge into your product SBOM
Your product's SBOM should include components from supplier SBOMs. Most SBOM tools support nesting or merging SBOMs to create a complete picture.
Track supplier component updates
When suppliers release updates, obtain updated SBOMs. Monitor for vulnerabilities in supplier components and coordinate with suppliers on remediation.
When suppliers don't provide SBOMs: You may need to generate SBOMs yourself using binary analysis tools, or document "unknown" components in your SBOM. FDA expects you to make reasonable efforts to understand your software composition.
SBOM for FDA Submissions
The FDA's premarket cybersecurity guidance includes specific requirements for SBOM documentation.
FDA SBOM Requirements (Summary)
Common FDA Reviewer Questions
"How do you track open-source components?"
Be ready to explain your SBOM generation process and how you maintain it through the product lifecycle.
"How do you monitor for new vulnerabilities?"
Describe your vulnerability scanning process and how quickly you can identify affected products when CVEs are published.
"What's your process for end-of-life components?"
Explain how you track support dates and your process for replacing EOL components before they become unsupported.
In Product Security Hub: Export SBOMs in CycloneDX JSON format for FDA submissions. Use the "Human Readable (Excel)" export for your own review and documentation.
SBOM Best Practices Summary
Ready to manage your SBOMs?
Product Security Hub makes it easy to import, scan, and manage SBOMs across all your products—with automatic vulnerability matching and FDA-ready exports.