Software Bill of Materials (SBOMs) are gaining traction and are a great way to codify what dependencies your software relies on from the Open Source ecosystems (and internal libraries too!).
The SBOM for a given release of a given piece of software should be static in terms of the components that comprise that release.
Known vulnerabilities change over time - we always know more about the security posture of Open Source components tomorrow than we did today. So how do we keep our BOMs updated with this information?
CycloneDX also allows for BOMs to interlink for the above reason. The best way to manage this scenario is to generate a BOM that describes your software release, excluding VEX data, and then have a tool (perhaps vexy?) produce you a VEX document (in CycloneDX format) that links back to your SBOM.
Did I confuse you? If so - read more about Independent BOM and VEX here.
- Data Sources
- API Reference