The initial value of the SBOM as we defined it in the context of the analyses you mention is to be able to accurately identify the software on which the analyses were performed. E.g.: In the case of CVE, it would replace the CPE.
Then, thanks to annotations and the pedigree information, the fact that the software was analysed by a set of tools can be captured in a new SBOM, and a recipient of the software would be in a position to know if these analysis were performed, if there were some mitigation to some vulnerabilities, etc.
From: Steve Springett Sent: Wednesday, October 30, 2019 7:58 PM
To: Subject: SBOM analysis types
I’ve seen a lot of scenarios that the model seems to be defining, but I haven’t seen any documentation about what forms of analysis that orgs should be able to perform against SBOMs.
IMO, the value of SBOMs isn’t just being able to produce or consume them, but being able to automatically analyze them with a high degree of accuracy. For example, these are the types of analysis that are possible with CycloneDX. Some of these types of analysis are available in Dependency-Track and others will possible in future releases.
These forms of analysis are already possible today. If a standard SBOM format is created from this effort, I think these forms of automated analysis should be possible at a minimum. Otherwise, the value proposition of adoption or migration just won’t be there.