[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SBOM analysis types


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 [steve.springett@owasp.org]
Sent: Wednesday, October 30, 2019 7:58 PM
To: sbom@omg.org
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.

  • Analyzing component quantity
    • Maintenance costs, etc.
  • Analyzing potential impact of coupling
    • Frameworks vs libraries for example
  • Identification and independent analysis of component assemblies (systems, subsystems, etc)
  • Identification and analysis of dependencies
    • Effective dependencies on a per application basis
    • Declared dependencies in the case of repo manifest
    • Identifying circular dependencies and associated upgrade risk
  • Vulnerability analysis
    • Assets (via CPE)
    • Libraries and Docker images (via PURL)
    • Decentralized (via external references - i.e. GitHub Advisories)
  • Out-of-date analysis
    • For managed components (maven, npm, nuget, rpm, deb, etc) via PURL
  • License analysis
    • SPDX, non-SPDX, and commercial licenses
  • File verification and component identification
    • Hash (md5, sha1, sha2, sha3)
  • Project health analysis
    • via external references to SCM, defect tracker, etc
    • # of committers, pull requests, issues, age, commit frequency, release frequency, etc
  • Signature validation of the BOM or component assembly within the BOM
  • Analysis of all the above for modified components (pedigree) without loss of fidelity

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.