2026 年每日通報的 CVE 數量比前一年多 131%。

SBOM

SBOM 最佳實務

多數 SBOM 計畫產出的是檔案;好的計畫產出的是答案:這個版本包含什麼、我們是否受影響,以及由誰修正。這十項實務正是兩者的分界。

更新日期

若要在各團隊推行這些實務,請參閱在工程團隊間產生 SBOM。

產生 SBOM

1. 在 CI 中為每個版本產生

手動製作的 SBOM 在任何人讀到之前就已經過時。請將它設為建置該版本之管線中的一個步驟,或使用完全不需額外步驟就能產生 SBOM 的執行器,確保沒有任何版本在缺少 SBOM 的情況下出貨。GitHub Actions 的做法請參閱如何在 GitHub Actions 中產生 SBOM。

2. 描述實際出貨的那次建置

建置預設並不可重現。同一個 commit 建置兩次,並不保證會得到相同的相依套件,因為版本是在建置時解析的,而且步驟可能不同。從筆電或事後掃描產生的 SBOM,描述的是一次類似的建置,而不是您出貨的那一次。只有來自產生該版本之 CI 建置的 SBOM,才能證明其中包含什麼。請參閱建置時 SBOM。

3. 涵蓋 lockfile 以外的內容

鎖定檔(lockfile)並不是已出貨內容的紀錄。安裝腳本會下載程式碼,Rust 建置腳本會擷取檔案,容器建置則會帶入擁有自己作業系統套件的基礎映像檔。先決定 SBOM 必須涵蓋什麼,再實際測試:在您的 SBOM 中搜尋一個來自基礎映像檔的套件與一個建置工具。

4. 納入遞移相依套件與相依關係

漏洞通常位於直接相依套件之下。扁平的清單只能顯示某個元件存在,卻無法告訴您該升級什麼。請在 SBOM 中保留相依關係圖,讓每項發現都附帶引入它的套件。

5. 標示您看不到的部分

2026 Minimum Elements 要求 SBOM 作者明確標示未知資訊。坦承不完整的 SBOM,比看似完整的不完整 SBOM 更有價值。也請記錄工具、其版本與產生情境,讓讀者能判斷檔案涵蓋了什麼。請參閱SBOM 完整度。

保存 SBOM

6. 每個版本保留一份 SBOM,並與建置產物綁定

當使用舊版本的客戶詢問是否受影響時,您需要的是那個版本的 SBOM,而不是最新的。請將每份 SBOM 與其描述的建置及建置產物一起保存,並依該版本的支援期間決定保存多久。SBOM 中的雜湊值有助於將它與確切的建置產物對應起來。

7. 選定一種格式與識別碼,並持續使用

統一採用 CycloneDX 或 SPDX、固定的格式版本,並以套件 URL 作為識別碼。比較 SBOM 時的大部分麻煩,都來自不同工具對同一個東西的命名不同。請在管線中驗證每個檔案,並要求供應商提供相同格式。SBOM 品質檢查清單列出了該檢查的項目,以及可協助檢查的工具。

運用 SBOM

8. 監控已出貨的內容,而不只是正在建置的內容

SBOM 最有價值的時刻,是針對去年發布之軟體的資安公告出現後的隔天。這時 pull request 中的掃描幫不上忙。請以新的漏洞資料重新評估仍在支援之版本所保存的 SBOM,讓新的資安公告能轉化為一份受影響版本的清單。

9. 將發現轉交給負責人,並記錄決策

比對出一千個漏洞的 SBOM 只是一份清單,而不是計畫。請以優先排序方法為發現排序,將每一項轉交給負責修正的團隊,並記錄其餘項目不予處理的原因,例如寫成VEX 聲明。

10. 對客戶與稽核人員使用同一份 SBOM

客戶、稽核人員與主管機關會提出類似的問題。請以您自己團隊使用的 SBOM 回答,而不是另外製作一份會逐漸偏離的文件。如果您會分享 SBOM,請決定誰可以查看,以及他們如何取得更新,並向您的供應商提出相同要求。

常見錯誤

錯誤 為何有害 改為
每個儲存庫只有一份 SBOM 無法說明任何特定版本 每個版本一份,並與建置產物綁定
只在稽核時產生 描述的是沒有人出貨的建置 每個版本都在 CI 中產生
把 SBOM 視為已完成 新的資安公告會在發布後出現 持續監控
只比較元件數量 項目若有錯,數量多並不代表更好 檢查您確知存在的特定套件

CRACI 如何處理

CRACI 涵蓋了仰賴建置的實務。它是 GitHub Actions 執行器,會將每個作業取得的每個套件(包括沒有任何 lockfile 列出的隱藏相依套件)記錄到附完整度狀態的 CycloneDX 或 SPDX SBOM 中。它會在您方案的保存期限內保留每次過去的建置及其 SBOM,在新漏洞出現時重新評估受監控的 SBOM,並顯示哪些建置包含有漏洞的相依套件。資安團隊可分級研判發現,並將其轉交給負責修正的團隊。管理工具的比較請參閱SBOM 管理,或參閱最佳 SBOM 工具。

SBOM 最佳實務常見問題

應該在什麼時候產生 SBOM?

每一次都在產生該版本的 CI 建置期間產生。在那個時間點製作的 SBOM 描述的是實際出貨的內容,而之後才製作的 SBOM 描述的是重新建置或掃描的結果。

SBOM 應該保存多久?

至少要保存到該版本的支援期結束,另加主管機關或合約要求的期間。您需要舊版本的 SBOM,才能判斷其使用者是否受新漏洞影響。

SBOM 應該自動化嗎?

應該。手動製作的 SBOM 到下一個版本就過時了。請在管線中產生 SBOM、在管線中驗證,並與建置一起保存。

應該與客戶分享 SBOM 嗎?

在客戶或主管機關要求時,依您能接受的條件分享。SBOM 會揭露您使用了什麼,因此許多公司選擇應要求提供,而不是公開發布。

SBOM 與 SBOM 管理有什麼不同?

SBOM 是一個檔案。SBOM 管理則是持續進行的工作:依版本保存 SBOM、監控其中的新漏洞,並讓需要的人能夠取得。

從每次建置取得 SBOM

將一個 GitHub Actions 工作流程指向 CRACI,查看您出貨之建置的已記錄 SBOM 及其完整度狀態。

預約示範