Software Bill of Materials (SBOM) Creation & Management Guide

💡 Tips:

• CycloneDX is better for security use cases — it has native VEX and vulnerability tracking
• SPDX is better if you also need comprehensive license compliance tracking
• Choose JSON output over XML for easier processing and smaller file sizes
• Document your format choice rationale for your SPDF documentation

💡 Tips:

• Syft + Grype (both from Anchore) is a powerful free combination for generation + vulnerability matching
• Test tools against your actual codebase — coverage varies by language/ecosystem
• Many tools miss C/C++ dependencies — you may need manual supplementation for embedded firmware
• Consider commercial tools if you need support and guaranteed coverage

💡 Tips:

• Include RTOS, bootloaders, and BSP components — these are often missed by automated tools
• Track "known unknowns" — components you know exist but cannot fully enumerate (e.g., COTS binary blobs)
• Document any components that require manual SBOM entries
• Include development tools that contribute runtime code (code generators, compilers)

💡 Tips:

• Generate SBOM AFTER dependency resolution but BEFORE packaging
• Version the SBOM with the same version as the software release
• Store SBOMs in your artifact repository (e.g., Artifactory, S3, Azure Blob)
• Include SBOM generation in your release checklist

💡 Tips:

• Use lock files (package-lock.json, Pipfile.lock, Cargo.lock) for accurate resolution
• Cross-check automated output against package manager dependency tree commands
• Log4Shell (CVE-2021-44228) was a transitive dependency in many projects — this is why depth matters
• Document maximum dependency depth for your project

💡 Tips:

• Create a separate "manual components" file that merges with the automated SBOM
• For binary-only components, record supplier, version, SHA256 hash, and license
• Set calendar reminders to check for updates to manually tracked components
• Document why each manual entry cannot be automated

💡 Tips:

• Use automated validation tools: sbom-tool, ntia-checker, or CycloneDX CLI validate
• Every component MUST have supplier, name, and version — no exceptions
• Document "known unknowns" explicitly — this shows thoroughness, not weakness
• Use Package URL (PURL) as the unique identifier when possible

💡 Tips:

• Not all CVEs are exploitable in your context — document your assessment for each
• Critical/High CVEs should be remediated before submission
• Use VEX (Vulnerability Exploitability eXchange) to document "not affected" justifications
• Include this vulnerability analysis in your premarket submission package

💡 Tips:

• Include BOTH a machine-readable file AND a human-readable summary
• The summary should include total component count, languages, licenses, and known vulnerability status
• FDA reviewers will check for common components with known CVEs — address them proactively
• Include the SBOM generation date and the software build version it represents

💡 Tips:

• Grype + your SBOM gives you free, continuous vulnerability monitoring
• Subscribe to vendor security advisories for COTS components
• Set up a security inbox (security@company.com) for monitoring alert notifications
• Review monitoring coverage quarterly — new vulnerability sources emerge regularly

💡 Tips:

• Every component update triggers a new SBOM generation
• Run full regression testing after dependency updates
• Security patches may qualify as minor changes under FDA software guidance — consult regulatory
• Keep a change log linking CVEs to component updates to SBOM versions

💡 Tips:

• Store SBOMs in your artifact repository with the same retention policy as software releases
• Tag SBOMs with the software version, build number, and date
• When a new CVE drops, you should be able to query "which deployed versions are affected?" within minutes
• This archive is valuable evidence of ongoing cybersecurity management for FDA