Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#38 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
38/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
markdown
領域
content

調査の方向性

まず、markdownベースのWebサイトのエントリーポイントと、投稿で既に使われている形式を見つけます。issue本文をSBOM比較記事の構成として使用し、リンクされたフクロウの画像を含めます。投稿がサイトで想定されている場所に、番号付きのガイダンスとともに追加され、画像が正しくレンダリングされれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
JavaScript
スター
9
フォーク
17
平均マージ
7時間 55分
マージ済み PR(30日)
2

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

aboutcode-org/www.aboutcode.org のほかの issue

aboutcode-org/www.aboutcode.org の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。