經過十數年的發展，開源軟體應用已到達成熟階段，從2008年開始，Gartner陸續發表多篇研究報告，指出開源軟體在「商業應用程式」、「雲端計算服務」與「資訊基礎建設」的占比將不斷提昇，經統計自2008年至今， 由超過50％ 開源函式庫組成的商用套裝軟體與嵌入式設備數量已增長10倍以上[1]。在近期全球知名的開源軟體與服務供應商Red Hat更發表了「企業開源軟體調查報告」，指出包含「基礎設施現代化（64％）」、「應用程式開發（54％ ） 」、「數位化轉型（53％ ） 」等領域，均有超過50％以上的開源函式庫使用率[2]。
軟體供應鏈管理
（Software Supplier Chain Management）議題現今雖然大多數的軟體或韌體開發均依賴第三方套件（包括函式庫、可執行二進制文件或開源原始碼），但相較於硬體供應鏈的管理，設備製造商對於軟體供應鏈的掌握與了解卻相對的缺乏。使得軟體或韌體中包含了許多未被記錄的第三方套件，並引入了不必要的已知弱點（CVE），讓使用者與設備製造商曝露在包含個資外洩、商譽受損等各種風險造成的影響與損失。
弱點雖然是開發軟體過程中可能的疏失，但更重要的是，製造商通常不清楚產品使用了哪些開源軟體，也不知道其軟體供應商是否用到不安全或存在弱點的軟體套件，因而無法即時在開發階段避免這些風險，導致軟體釋出後而產生的安全風險與修補成本。儘管OWASP WEB Application Top 10 : A9 Using Known Vulnerable Components，在2013年就已被提出[3]，在經過近八年的時間後，每當有新的弱點被揭露時，依然很少有企業可以快速、準確的回應一些關鍵性的問題，例如：「我們的產品是否有受到該弱點的影響？」、「此弱點影
響了哪些產品線？ 」以及「哪些軟體的版本是否存在這些問題？」；其實這歸因於在開發階段，未對產品的軟（韌）體組成進行管理所造成，造成了開發、採購、維護與處理成本的大幅增加。在Gartner的研究報告「12 Things to Get Right for Successful DevSecOps」提到，在軟體開發的過程中，首先應專注於識別和消除第三方套件的已知弱點[4]，因此，除了瞭解自已的開發團隊有使用哪些開源軟體外，同時須對軟體供應鏈進行管理、消除已被國際組織與社群揭露的已知弱點，不僅是安全軟體開發的第一步，更是效果最顯著、成本最低廉的必要項目之一。
提升供應鏈透明度將可有效降低網路安全風險和總體成本[5]，以下即為執行的方法與重點：
• 提高識別可能導致網路安全事件的第三方套件的能力• 減少因供應鏈混亂而導致的計劃外和非生產性工作
• 有更高透明度的供應商將能更輕鬆地在市場中脫穎而出
• 通過跨多個部門的標準化格式來減少重複工作
• 識別可疑、偽造與惡意的第三方套件
然而，供應鏈管理與軟體組成清單的建立，是一套系統化的流程，必須要從建立軟體組成清單開始，逐步融入到企業的開發流程中， 成為與生俱來的企業DNA的一部分。但從無到有一步步的建立完整的軟體供應鏈資料，是一個長期且持續迭代的過程，這過程可能會耗費大量的人力資源，導致許多企業無法完整實現軟體供應鏈的安全管理；以下我們將說明，如何在安全品質與人力資源投入下取得一個平衡，逐步完成軟體供應鏈的安全管理。
軟體組成清單（SBOM）
軟體組成清單（Software Bill of Materials, SBOM）亦稱為風險組成清單（Cybersecurity Bill of Materials, CBOM），是構成軟（韌）體的成份表。用來描述軟體的組成架構、內容、生產與整合軌跡，以提供軟體組成透明性，美國國家電信暨資訊管理局（National Telecommunications and Information Administration, NTIA），從2019年開始起草並核定了一系列的文件，提供SBOM的相關資訊與指引， 並以醫療行業進行實際案例研究[6]。透過SBOM，為軟體供應鏈管理的核心技術，能解決兩個重要的問題[7]：
1. 我們是否曾使用過易受攻擊的開源函式庫版本？
2. 如果是，它們存在於哪些產品與應用程式中？
SBOM是軟體組成元件和關聯表[ 8 ]， 包含這些元件的名稱、版本、來源、層次與相依性等關係， 必須是機器可讀格式（Machine Readable Format）。
SBOM 可包括開源或專有（Proprietary ）軟體，產出SBOM的最有效方式，是在開發過程一併的記錄與建立。但對於已經存在或正在開發的元件、設備、軟體與系統來說，這樣的方式缺乏效率，因此並不可行。以自動化的方式來輔助開發團隊，進行軟體組成清單初稿的建立，更能有效減少對於團隊的工作干擾，降低產品開發期程的延宕，更有效快速的達成目標，其中一個最常被採用的關鍵技術即是韌體掃描與分析。
韌體掃描（Binary Scan）
韌體掃描（Binary Scan）是執行軟（韌）體組成分析最有效快速的自動化方法之一，這是一種用於管理開源軟體組成安全性的方法[9][10][11][12]。透過韌體掃描，開發團隊可以快速切入正在開發中的專案，自動化分析引入到專案中的任何開源函式庫。韌體掃描工具能發現所有相關組件、弱點和潛在風險， 同時檢測軟（韌）體許可證。掃描過程會生成軟體組成清單，有利於開發人員和應用程式安全團隊。
軟體的組成隨著開源軟體項目的增加，包含核心運算、資料交換、網路通訊等大部分的主要模組， 自主開發程式的功能則類似膠水一般結合這些開源模組，或是小量的特製化元件與差異化功能，一般來說在物聯網與嵌入式設備中軟體主要由SDK、Open Source與Self-Developed Program三大部分組成。
軟體開發部門因軟體品質控制（Software Quality Control）需要使用原始碼掃描（Source Code Scan）來找出諸如Out of Bounds Write、Use after free 等CWE（Common Weakness Enumerati on）問題已行之有年，且相當成熟，但卻常常忽略了外部或第三方供應商所提供的內容， 而這些交付的項目與內容，有時甚致沒有原始碼，或者包含了二進位的檔案。
韌體掃描（Binary Scan）在物聯網設備製造業的應用
由於現在幾乎每個製造商與開發部門在其產品與軟體中都使用了開源軟體，因此軟體組成分析變得尤其重要。Gartner在「軟體組成分析市場指南」報告中也建議，通過安全掃描工具進行掃描必須是標準流程，而不是
例外的補強措施[13]。
在2018年醫療設備的安全審核上，第一次明確規範了軟體組成的安全，美國FDA於醫療器材上市許可申請草案中，將網路風險組成表（Cybersecurity BOM, CBOM）列為必要項目，因此採用可以有效輔助開發團隊產出軟體組成清單的自動化工具至關重要。其中韌體掃描的技術優點，是可涵蓋不同來源或檔案型態的掃描需求，包含可取得原始碼的開源函式庫，與無法取得原始碼的第三方模組及二進位檔案。在應用情境方面，包含研發（RD）團隊與品管（QA）團隊，甚至軟體的採購驗收、智財權稽核單位及安全檢測實驗室，都能有效良好的運用。
從各個產業趨勢分析結果來看， 近期的國際資安規範與標準，會將SBOM與CBOM列為優先要求項目，因此Gartner在報告評論中也認為：軟體組成分析的重要性將繼續提高；要求範圍與內容將擴展到包括軟體供應鏈；需要工具配合DevSecOps的執行；維持SBOM、保持動態優化的要求將愈來愈高。
HERCULES SecSAM開源軟體風險管理系統
有鑑於產業面臨愈來愈嚴慬的法規與標準， 安華聯網推出的次世代開源軟體風險管理系統HERCULES SecSAM，可以協助企業建立完整的開源軟體（OSS）風險管理系統，解決客戶對於開源軟體與供應鏈安全管理上的難題。
SecSAM可自動匯入已盤點清單，針對產品的安全性進行完整且有效的管理，透過SecSAM OSS弱點分析工具進行CVE弱點比對，協助客戶建立OSS風險清單，列出所使用開源軟體之弱點及建議修補方案。
對於無法取得原始碼，例如外包商提供之軟體或已編譯為二進制執行檔（Binary File）的產品，SecSAM利用韌體掃描技術進行內容組成分析，可快速盤點與識別產品中引入的第三方套件與已知弱點，這樣的方式除了操作簡便、應用彈性之外，更無原始碼洩漏之風險。
此外，SecSAM更可分析開源軟體清單中之各種授權類型（例如 GPL、LPL、Apache等），幫助客戶選用合乎企業利益的開源授權規則軟體，避免面對受侵權法律議題而蒙受損失。
除了上述檢測自動化的功能特色外，SecSAM更進一步的結合開發團隊常用的問題追縱（IssueTracking）系統，且每日更新國際弱點與資安情資訊息，即時回饋與檢查產品風險清單並主動發出警示，使開發團隊或產品安全負責團隊，可依循SecSAM所提供的解決方案與相關情資，快速對弱點進行反應與修補，在產品的生命周期中達成安全設計、安全測試、安全維護等重要目標。
Reference
[1] Gartner: 80 ％ of commercial apps to use open source by 2012 : https://arstechnica.com/information-technology/2008/02/
gartner-80-percent-of-commercial-software-programs-will-include-open-source-by-2012/
[2] The State of Enterprise Open Source : https://www.redhat.com/en/enterprise-open-source-report/2021
[3] OWASP Top 10 -2013 The Ten Most Critical Web Application Security Risks : https://owasp.org/www-pdf-archive/OWASP_
Top_10_-_2013.pdf
[4] 12 Things to Get Right for Successful DevSecOps : https://www.gartner.com/en/documents/3978490/12-things-to-get-right-forsuccessful-
devsecops
[5] Framing Software Component Transparency: Establishing a Common Software Bill of Material （SBOM） : https://www.ntia.gov/
les/ntia/publications/framingsbom_20191112.pdf
[6] SOFTWARE BILL OF MATERIALS : https://www.ntia.gov/SBOM
[7] Why You Need a Software Bill of Materials More Than Ever : https://blog.sonatype.com/why-you-need-a-software-bill-ofmaterials-
more-than-ever
[8] SBOM at a Glance : https://www.ntia.gov/ les/ntia/publications/sbom_at_a_glance_apr2021.pdf
[9] Guide to Software Composition Analysis （SCA） : https://snyk.io/blog/what-is-software-composition-analysis-sca-and-doesmy-
company-need-it/
[10] Component Analysis : https://owasp.org/www-community/Component_Analysis
[11] Market Guide for Software Composition Analysis : https://www.gartner.com/en/documents/3989235/market-guide-forsoftware-
composition-analysis
[12] Software Composition Analysis-Open Source License Compliance and Vulnerability Management : https://assets.kpmg/content/
dam/kpmg/us/pdf/2018/08/software-composition-analysis- exera.pdf
[13] Market Guide for Software Composition Analysis : https://www.gartner.com/en/documents/3989235/market-guide-forsoftware-
composition-analysis