aboutcode-org / aboutcode-org/www.aboutcode.org

POST: Our approach to compare SBOMS, or the "10 steps for SBOM comparison".

Abierto
#38 0 comentarios 0 reacciones 0 asignados Ver en GitHub
blog
Lenguaje dominante
JavaScript
Estrellas
9
Forks
18
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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/

Image

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.