Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#38 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
38/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
markdown
Domínio
content

Direção de pesquisa

Comece localizando o ponto de entrada do site baseado em markdown e o formato existente para as postagens. Use o corpo da issue como estrutura para o artigo de comparação de SBOM e inclua a imagem de coruja vinculada; a tarefa estará concluída quando a postagem for adicionada no local esperado do site, com suas orientações numeradas, e a imagem for renderizada corretamente.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

blog

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:

  1. Is the license for each package present? Otherwise, fix the SBOM.
  2. 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:

  1. Is there a copyright or some provenance information for each package? Otherwise, fix the SBOM to add the missing information.
  2. 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!

  1. Esnure that all requirements 1. to 7. are met.

  2. Extract and sort the list of PURLs from each SBOM, and compare these two sequences (an easy diff)

  3. If 16. holds and this is the same analyzed code, there should be no differences at all.

  4. 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
Linguagem predominante
JavaScript
Estrelas
9
Forks
17
Merge médio
7h 55min
PRs com merge (30d)
2

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aboutcode-org/www.aboutcode.org

Todas as issues de aboutcode-org/www.aboutcode.org

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.