aboutcode-org / aboutcode-org/www.aboutcode.org
POST: Our approach to compare SBOMS, or the "10 steps for SBOM comparison".
- Lingua principale
- JavaScript
- Stelle
- 9
- Fork
- 18
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
This is our approach to compare SBOMS, or what are the "more or less" "10 steps towards SBOM validation and comparison":
First, what are the requirements that make an SBOM comparable? At a high level, you can only compare apples-to-apples. In SBOM speak, this means that you have have a complete listing of all packages included in a software, using the same package (and license) identifiers.
Here are the requirements towards a comparable SBOM:
1. Is this valid JSON? Otherwise, fix the JSON until it loads.
2. Is the data schema-valid for its SBOM JSON schema? Otherwise, fix the JSON until it validates.
3. Is the SBOM using PURLs to identify packages? Otherwise, fix the package identifiers to map to PURL.
4. Are the PURLs using a correct syntax? Otherwise, fix the PURL until they validate.
5. As these existing PURLs, known in the PURL spec as registered types, and pointing to actual real code? Otherwise, fix the PURL until they are correct.
6. Are all the PURLs that should be present found in the SBOM? (is this complete and accurate?) Otherwise, fix the SBOM until it is accurate.
7. Are the versions of each package available with each PURL? Otherwise, fix the PURL until they all have a version.
And also for licensing:
8. Is the license for each package present? Otherwise, fix the SBOM.
9. Are licenses using correct SPDX license expressions? Otherwise, fix the licenses to get expressions.
And also to cross check when some data is lacking or incorrect:
10. Is there a copyright or some provenance information for each package? Otherwise, fix the SBOM to add the missing information.
11. Are key URLs like home page or download URLs present for each package?0. Is this the list of PURLs for the deployed, as-run code? Otherwise, fix the SBOM to add the missing information.
Other interesting data points:
13. Is the relationship between packages described?
14. Are there other "enrichment", like package description, other attributes?
15. For each package, is there an indication of its intended usage or "scope" (test, prod, dev, doc, etc.)?
Finally:
16. What is the "type" of SBOM? OR at what point in time in the software lifecycle it was computed?
And now, here is how compare two SBOMs!
17. Esnure that all requirements 1. to 7. are met.
18. Extract and sort the list of PURLs from each SBOM, and compare these two sequences (an easy diff)
19. If 16. holds and this is the same analyzed code, there should be no differences at all.
20. You can further compare licenses for any matching PURLs pair assuming that 8. and 9. are met.
(Add an image of the How to Draw an Owl meme)
https://www.reddit.com/r/pics/comments/d3zhx/how_to_draw_an_owl/
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Valutazione
Questa issue non è ancora stata valutata.