Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
#38 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
38/100
Issue 類型
文件
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
markdown
領域
content

研究方向

首先定位以 markdown 為基礎的網站入口點,以及現有的文章格式。使用 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 分鐘
30 天內合併 PR
2

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

aboutcode-org/www.aboutcode.org 的其他 Issue

查看 aboutcode-org/www.aboutcode.org 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。