簡單、透明、安全、高度整合！龍蜥可信 SBOM 能力探索與實踐

近兩年，軟體供應鏈有非常多安全事件，包括軟體供應鏈的各個階段開發、構建、交付、使用等每個環節都有很多的軟體供應鏈的安全事件發生。在 2023 龍蜥作業系統大會全面建設安全生態分論壇上，阿里雲技術專家鄭耿、周彭晨分享了龍蜥社群在構建 SBOM 基礎能力方面所做的努力，也深入探討了龍蜥社群在建立健全 SBOM 能力所必須開展的相關工作，並基於軟體供應鏈各個階段出現的簽名服務短板，提出了專門服務於軟體供應鏈的統一簽名服務。以下為分享原文：

01 軟體物料清單（SBOM）

提到 SBOM 就不得不提一下軟體供應鏈的概念，上圖是引用 CNCF 軟體供應鏈白皮書。軟體供應鏈和傳統供應鏈是一個非常好的類比，如從原件的生產到工廠的製造，運輸到使用者側，商店銷售，觸達到終端使用者。從軟體的維度，軟體原始碼的引入、開發、構建，透過網路釋出到最終的製品倉，觸達下游使用者的整個流程，即為軟體供應鏈的定義。

近兩年的情況可以看到非常多的軟體供應鏈的安全事件，包括軟體供應鏈的開發、構建、交付、使用等各個環節都有很多安全事件發生，軟體供應鏈問題急需解決。截止到 2023 年 4 月份的 12 個月之內，外企有至少 60% 的公司受到軟體供應鏈攻擊的影響。

這就引出了軟體物料清單的概念。軟體物料清單可以理解為對軟體製品的一種描述，它包括了一些軟體的原資訊、軟體的基本資訊、軟體的依賴、開源證書等資訊，可以做軟體供應鏈管理、安全漏洞管理、應急響應、軟體合規管理等用途。gartner 預測，到 2026 年至少有 60% 的採購方將在關鍵設施的採購中交付軟體物料清單。

龍蜥社群在逐步構建整個 SBOM 的基礎資料能力。目前在龍蜥軟體資訊中心上已經實現了針對軟體的軟體包、ISO 映象、容器映象的全製品覆蓋。目前，初步是實現國際主流的 SPDX 的格式的軟體物料清單，後續根據需求，也會逐步支援其他的 CycloneDX、SWID 等更多 SBOM 格式的支援。

02 可信 SBOM

什麼是可信 SBOM？這裡引用一句話：Simply producing an SBOM is not sufficient，instead we must ensure that such SBOMS are trustworthy，意思是做一個 SBOM 的交付是不夠的，保證 SBOM 交付給下游的使用者的 SBOM，它是可信的，什麼是可信？從四個維度定義可信，一個是交付給使用者的 SBOM 內容的準確性，比如軟體製品包含了哪些成分，成分是否是真的，用機器學習的評價指標就是裡面的假陽率有多少。二是可驗證性，怎麼保證交付給使用者的 SBOM，使用者可以驗證交付的 SBOM 是真實的。三是完整性，比如 SBOM 可能包含了 99 個依賴成分，但可能它實際依賴了 120 個成分，完整性上的缺失導致 SBOM 內容不準確。四是 SBOM 的來源可信，是否是來源於一個可信的組織機構，比如龍蜥，而不是不可信的第三方，這就是機構可信背書的問題。

目前開源社群在可信 SBOM 上的實踐：上圖是 Redhat 的 sbom 倉庫。Redhat 在官方製品的倉庫已經發布了一個 beta 版本的、基於 spdx 的 sbom 資料。可以看到每個製品的 SBOM 對應了三條資料，第一條是壓縮後的 SBOM 檔案；第二條是 SBOM 檔案的簽名資訊；第三條是 SBOM 的雜湊值。利用簽名和雜湊值，從完整性和來源可信兩個維度保證 SBOM 的可信。

上圖是一個比較典型的容器映象場景，也是 SBOM 目前的生態和整個工具集支撐的比較好的場景。目前社群主流的方案是: 首先透過 SBOM 的一些生成工具，比如 syft 工具生成容器映象的 SBOM。cosign 是 Linux Fundation 在社群上支援的簽名專案，然後利用cosign 對 SBOM 基於 in-toto 的 Attestation 格式生成 SBOM Attestation。透過這種方式可以把 SBOM 和容器映象關聯。最終下游使用者可以透過工具對 SBOM 進行驗證。圖上我們對遠端證明做驗證，可以看到 SBOM 整個的製品簽名資訊。簽名是一個非常好的驗證來源可信的手段。供應鏈的整個生產流程還有非常多的點可以用簽名做可信校驗。

03 龍蜥統一簽名服務

為什麼在軟體供應鏈 SBOM 場景下提到統一簽名服務？它其實是推導後的結果。接下來介紹怎麼演繹推匯出需要的統一的簽名服務？

軟體供應鏈 SBOM 有一個非常明顯的特徵，所有的資料來源、問題都是碎片化散落在整個軟體供應鏈 SBOM 體系下面的，比如生產階段、設計階段、釋出階段。要解決軟體供應鏈 SBOM 的可信問題，需要一個非常好的方法論指導，而龍蜥從攻擊面管理的角度解決軟體供應鏈 SBOM 複雜體系的可信問題。

在安全問題的設計過程中，首先為軟體供應鏈 SBOM 建立一個可信模型。為了全面覆蓋軟體供應鏈 SBOM 整個過程，把它分為大概三部分：

• 原始碼階段是編碼 Code Review。

• 構建階段是編譯、釋出。

• 部署階段是釋出、上線、執行。

除了以上三部分之外還會涉及到依賴，如構建依賴、編譯依賴等，這是構建、釋出時非常重要的 SBOM 概念。在此過程中，原始碼階段會發現有一個攻擊方式，比如有一些人編寫的不安全程式碼，這是一種比較多的攻擊方式。原始碼入侵的場景下，可以把原始碼倉庫都破壞掉，對原始碼完整性形成了一個非常壞的結果。在構建階段還有非常多的供應鏈投毒，把釋出製品篡改成用於攻擊的製品。

總結下來整個軟體供應鏈 SBOM 有四種需要做安全保護：原始碼完整性、構建完整性、系統完整性、後設資料的完整性。在此過程中，提到完整性大家會有一個非常直觀的概念，就是完整性的保護可以透過簽名解決。軟體供應鏈 SBOM 絕大多數場景有完整性的需求，透過統一簽名解決這樣的問題。因此，龍蜥從軟體供應鏈 SBOM 安全威脅模型，推匯出了需要有統一的簽名服務消解可信問題。

當前簽名技術比較成熟標準化，在 SBOM 的體系下有用簽名。那當前的簽名服務在Anolis OS 還有沒有，有哪些需要解決的問題。從整個Anolis OS 的軟體生命週期看，把它分為七個階段，需求、設計、研發、構建、測試、釋出、執行。需求階段有一個很重要的問題，即所謂的需求完整性，例如產品需求方提的需求最後有沒有完全被覆蓋到，在軟體供應鏈體系下它其實沒有被覆蓋的。簽名依賴很多簽名工具，比如構建系統、三方的工具等，龍蜥 OS 用的是 koji 的打包平臺。底層用到的密管服務，阿里雲的 KMS 或者本地的 PKI，從簽名服務的複雜性來說有很多的對接。

我們對 Anolis OS 的場景做了一個總結，有些功能有但可能會承擔安全風險，如 OS 的 rpm 包有一個非常嚴重的問題，有可能會本地落盤，所有的軟體生命週期當中的簽名都是分散，缺乏管控的。另外一個問題是標紅的東西很多，不同的標準，不同的簽名工具，不同的 KMS 都沒有統一支援或整合，導致了整個軟體供應鏈 SBOM 簽名是碎片化的。

針對以上問題，社群做了龍蜥統一簽名服務的設計，龍蜥的統一簽名服務特點是簡單的、透明的、安全的、高度整合的。所謂的簡單從使用者的視角來看，希望統一簽名服務是易用的，對使用者來說非常簡單，可以用各種方式把服務用起來。透明是後續把統一簽名服務開源出去，來搭建它真正的安全性。另一個最重要的點是高度整合，簽名服務是彈性的、可擴充套件，可以支援多種 KMS、服務、資料庫等。

統一簽名服務架構上可以東西向和南北向擴充套件。南北向的可擴充套件是後臺支撐的服務有多種 KMS、資料庫、三方服務可以借用。東西向的可擴充套件希望有多例項的能力，LB 或者 Gateway的方式能夠提升服務的吞吐能力，還有一個最重要的是缺失的標準的 JWT 統一的許可權管控。以上就是龍蜥統一簽名服務的整體架構介紹。

精彩影片回放、課件獲取：

2023 龍蜥作業系統大會直播回放及技術 PPT上線啦，歡迎移步龍蜥公眾號2024年3月5日相同推送檢視。

技術 PPT ：關注龍蜥公眾號【OpenAnolis 龍蜥】，回覆“龍蜥課件”獲取。

—— 完 ——