作者：林詩芳 / 臺灣大學計算機及資訊網路中心程式組行政專員
隨著越來越多套件漏洞及勒索軟體的出現，確保軟體供應鏈安全(Supply Chain Security)，強化預防識別惡意或有漏洞套件或元件的能力成為重要的議題，軟體物料清單(Software Bill of Materials，SBOMs)對於安全資訊交流扮演關鍵溝通角色。本文簡介SBOM的內容與產生工具，並說明其在既有軟體開發生命週期(System Development Life Cycle，SDLC)中如何協助增強管理軟體供應鏈的安全。
軟體產品使用的軟體組件或套件來源可能來自內部開發，第三方供應或開源專案。隨著軟體開發複雜度增加，軟體直接相依的組件或套件可能又再依賴到其他組件或套件，形成複雜的軟體供應鏈(Software Supply Chain)，因而增加資安防護的難度。隨著越來越多套件漏洞(例如:Log4Shell)及勒索軟體的出現，確保軟體供應鏈安全(Supply Chain Security)成為重要的議題。在2021年5月美國拜登總統於發布了關於改善網路安全行政命令(Executive Order 14028)，其中之一即是建議建立軟體物料清單(Software Bill of Materials，SBOMs)。[1]而在台灣銀行公會於2023年4月公布實施的「金融機構資通系統與服務供應鏈風險管理規範」中雖然沒規定軟體產品與服務組件需提供SBOMs，但其軟體供應商得擔保元件安全。[2]目的皆希望強化預防識別惡意或有漏洞套件或元件的能力。
在Linux基金會支持下訂義了軟體套件資料交換(Software Package Data Exchange，SPDX)的格式，以作為描述軟體物料清單(SBOMs)的開源標準。[3]軟體物料清單(SBOMs)為軟體構成的所有元件清單，許可證清單(SPDX License List)，版權和安全參考。SPDX有五種文件格式：tag/value (.spdx)，JSON(.spdx.json)， YAML(.spdx.yml)，RDF/xml(spdx.rdf)和spreadsheets (.xls)。SPDX Document v2.3定義文件規格可分為兩類：一是必須包含的內容為文件建立資料(Document Creation Information)，二是可選擇提供的內容為套件資訊(Package Information)，檔案資訊(File Information)，片段資訊(Snippet Information)，其他許可證資訊(Other Licensing Information)，SPDX文件相互關係資訊(Relationships between SPDX Elements Information)，註解資訊(Annotations Information)。[4]
無論是開源或商業軟體皆有許多軟體物料清單產生器(SBOMs generator tool)可以選擇。其中sbom-tool為微軟所提供的開源軟體物料清單產生器，其可建立SPDX2.2相容的SBOM。此產生器透過微軟的套件掃描工具(Component Detection，CD)，component-detection掃描軟體中所使用的套件，並使用ClearlyDefined API取得套件的授權資訊。[5]其使用介紹如下表：
|
步驟
|
說明
|
|
1
|
待分析的軟體專案：ASP.NET Core and Class Library。如圖1。
|
|
圖1：待分析的軟體專案
|
|
2
|
建置專案。如圖2。建置專案命令如下：
dotnet build –output <output_directory>
|
|
圖2：建置專案
|
|
3
|
透過命令列生成SBOM。如圖3。生成SBOM的命列如下：
sbom-tool generate -b <drop path> -bc <build components path> -pn <package name> -pv <package version> -ps <package supplier> -nsb <namespace uri base>
|
|
圖3：生成SBOM
|
|
4
|
生成的SBOM檔案位置，在_manifest folder內。如圖4。
|
|
圖4：SBOM檔案位置
|
|
5
|
SBOM檔案內容。如圖5。
|
|
圖5：SBOM檔案內容
|
sbom-tool產生的SBOM，其內容可分四個部分：
- 文件建立資料(Document Creation Information)：關於SBOM文件的基本資訊如：軟體名稱、SPDX授權、SPDX版本、文件建立者、文件建立時間等。如圖6。
- 6：文件建立資料(從sbom-tool產生SBOM)
- 檔案部分(Files section)：組成軟體的檔案清單。每個檔案屬性包含檔案內容的雜湊值（SHA-1、SHA-256）。如圖7。
- 軟體套件部分(Packages section)：軟體套件清單。每個套件屬性包含：套件名稱、套件版本、套件供應商、雜湊值（SHA-1、SHA-256）、套件下載的URL、套件識別碼。如圖8。
- 8：軟體套件部分(從sbom-tool產生SBOM)
4. 關係部分(Relationships section)：檔案與套件間的關係清單。如圖9。
圖9：關係部分(從sbom-tool產生SBOM)
在Github儲存庫(Repository)可提供關係相依圖(Dependency Graph)來分析軟體專案的相依性關係，如圖10。並可匯出SBOMs檔案，以sbom-tool為例如圖11。
圖10：Github可提供sbom-tool的Dependency Graph
圖11：Github可匯出sbom-tool的SBOM
當以下狀況皆會觸發儲存庫(Repository)自動更新關係相依圖(Dependency Graph):當儲存庫(Repository)有新的推送(Push)或更改，或儲存庫(Repository)的相依項目的儲存庫(Repository)有更改，儲存庫(Repository)其關係相依圖(Dependency Graph)會自動更新。
產生軟體物料清單(SBOM)只是第一步，為了確保軟體供應鏈安全(Supply Chain Security)，還需透過查閱與蒐集資安弱點資訊如:公開常見漏洞與揭露(Common Vulnerabilities and Exposures，CVE)，進一步檢核軟體使用清單的元件或套件是否存在已知的漏洞與風險。[6]以Github為例，其Github Advisory Database蒐集安全漏洞(Security Vulnerabilities)，惡意軟體(Malware)資訊 和已知CVEs紀錄。透過Dependabot Alerts偵測掃描Github儲存庫(Repository default branch)中是否有Github Advisory Database蒐集到的安全漏洞，並對該Repository的擁有者提供安全性警告(Security Alerts)通知功能。當GitHub Advisory Database有新的諮詢(Advisory)或儲存庫(Repository)被推送(Push)新版或更新依賴套件或版本時皆會觸發掃描後發布警告通知。或是以商業軟體Synopsys Black Duck或Sonatype Repository Firewall為例，除了對已經進入原始碼版控(Source Configuration Management，SCM)的原始碼專案在進行程式碼建置(Code Build)後產生SBOM，並利用其蒐集安全漏洞的知識庫提供客戶安全漏洞的訊息且提出警告外，亦可進一步提供分析軟體授權風險資訊因而阻擋授權風險的套件。[7][8] 因此透過SBOM的資訊可提供開發者或組織檢查與監控已經發布或使用的軟體元件的漏洞與授權追蹤。[9]
再更進一步，希望在軟體開發生命週期(System Development Life Cycle，SDLC)的早期，就能防止將有漏洞的弱點的套件引入到開發的軟體內。在開發階段評估要引用元件或套件時，能取得要引用的元件或套件是否有已知的漏洞資訊，因而排除使用。以Github為例，其可透過相依性審核(Dependency Review)讓你在把有漏洞的套件(Package)拉進(Pull)或加到你的儲存庫(Repository)時，發出相關安全漏洞的警告，以防止將漏洞加到儲存庫(Repository)中。[10]或是商業軟體Synopsys Code Sight或Sonatype IQ為例，皆為開發環境(Integrated Development Environment，IDE) Plugin，也可在開發階段時評估是否引用套件時，提供該套件是否有漏洞與提供修改建議。[11][12]以上是進一步在開發階段防止引入有已知漏洞的套件方式，而非等把有漏洞的套件加到並推送(Push)到原始碼版控(SCM)內，進行程式碼建置(Code Build)並產生SBOM後，再去檢核是否有引用到不安全或有漏洞的套件。
然而無論是軟體開發生命週期(SDLC)哪一個階段進行檢核套件的安全性，都必須是持續且自動化的監控。因此需在軟體開發維運(DEVOPS)的持續整合(Continuous Integration，CI)，持續部屬(Continuous Deployment，CD)流程中納入。以Github Configuring Dependency Review Action為例，其提供REST API方式來取得儲存庫(Repository)的不同Dependency Changes資訊，並可透過設定Github Action workflow其configuration file(YAML file)，例如：拒絕的安全等級閾值(fail-on-severity)，允許許可證的清單(allow-licenses)等選項資訊，進而把其納入組織的CI，CD中幫助組織的政策(Policy)檢核與評估。或是如商業軟體Synopsys Black Duck或Sonatype Repository Firewall亦根據其蒐集安全漏洞的知識庫資訊配合組織設定的政策(Policy)協助組織做套件風險評估與管理的功能。
SBOM對於安全資訊交流扮演關鍵溝通角色，利用SBOM提供的軟體組成資訊，進而檢核並阻擋違反組織政策(Policy)的套件或元件加到軟體專案中， 因此可以增加組織識別惡意或有漏洞的套件與元件的能力，進而強化軟體供應鏈的安全性。
References：
[1] EO 14028 https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[2] https://www.ithome.com.tw/news/156604
[3] SPDX wiki https://en.wikipedia.org/wiki/Software_Package_Data_Exchange
[4] SPDX https://spdx.dev/
[5] sbom-tool https://github.com/microsoft/sbom-tool
[6] CVE https://cve.mitre.org/
[7] Synopsys Black Duck https://www.synopsys.com/software-integrity/software-composition-analysis-tools/black-duck-sca.html
[8] Sonatype Repository Firewall https://www.sonatype.com/products/sonatype-repository-firewall
[9] Github Advisory Database https://github.com/advisories
[10] Dependency Review https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
[11] Synopsys Code Sight https://www.synopsys.com/software-integrity/code-sight.html
[12] Sonatype IQ https://help.sonatype.com/iqserver/integrations/plugins-for-ides/iq-for-idea