軟件成分分析及其如何識別開源軟件風險
軟件成分分析的定義
軟件成分分析(SCA)是指分析了解應用程序中使用了哪些開源組件和依賴關系，以及如何自動化地使用這些組件和依賴關系。SCA的目的是評估這些組件的安全性并識別它們帶來的潛在風險或許可證沖突。為了確保引用的代碼不會在產品中引入安全風險或合規問題，將SCA工具有效地納入軟件開發工作流程是加強軟件供應鏈安全性和完整性的重要一步。
為什么需要軟件組成分析
從零開始開發軟件應用的日子已經一去不復返了。開源軟件的廣泛引用給應用程序的開發方式帶來了變革。個體開發人員和企業可以在他們的代碼中引用已有的組件和庫來實現各種功能，從簡單的Web 表單驗證到復雜的加密操作等。
雖然開源代碼的引用在一定程度上避免了“重復造輪子”，但隨之而來的也包括一些隱患: 例如你引用的代碼可能存在著 bug 或脆弱性，又或者代碼攜帶的許可證與所開發應用本身的許可證相沖突。誰來檢查這些又是一個問題。
人工檢查一批組件或許是個簡單的任務，但現代軟件應用通常是由數百個庫構成的。這些庫本身又可能有其他依賴關系。而且一個程序可以運行很多層，若沒有意識到這一點，一個應用程序表面上只包含了少量的庫，但是在其內部很可能已經引入了成百上千的傳遞性依賴關系。這時候就需要SCA來解決了。
軟件成分分析和SBOM（軟件物料清單）
大多數SCA工具都可以生成軟件物料清單（SBOM）。SBOM是一個詳細清單，這個清單包含了應用程序中所有的依賴關系和組件。一個理想的SBOM可以提供應用程序中所有組件的名稱、版本號、發布日期、校驗和、許可證信息以及其他元數據。
這可以通過以下方式之一實現：
- 清單掃描 SCA工具掃描應用程序的構成清單文件，例如package.json、用于JavaScript或pom.ApacheMaven（Java）項目的XML，并根據這些，生成依賴關系列表。如果沒有版本控制系統（例如GitHub、GitLab或SVN）中所包含的最終打包文件，那么開發人員可以使用這種方法來掃描應用程序。
- 二進制掃描 SCA工具掃描打包文件，并通過二進制指紋識別開源組件。此方式通過識別應用程序的最終打包文件中所有包，從而減少誤報，并識別以非標準方式引入到應用程序中的第三方軟件和庫。然而，并不是每個SCA工具都有二進制掃描功能。
- 清單及二進制掃描 一些SCA解決方案可能會選擇混合方法：清單和二進制結合掃描，以獲得高精度的SBOM。因此，SCA解決方案的復雜程度決定了它識別隱藏組件的準確程度。
通常，SBOM是以XML、JSON或類似格式的文本文件的形式出現的，這些格式對人和機器都是可讀的。XML文檔基于OWASP CycloneDX標準，列出了組成KeyClock的組件，包括它們的校驗和、版本號、發布日期和許可證信息。值得注意的是，SBOM所含數據顯示，單一版本的KeyClope包含900多個組件。
同樣是基于文本，但Linux基金會的SPDX標準與CyoNeNDX標準并不相同。
SCA工具如何幫助查找開源漏洞？
自動化的SCA工具可以幫助研發團隊開發和發布高質量的代碼，并為參與者提供一種積極主動的風險管理方法。在軟件開發過程的初期，SCA工具通過識別安全漏洞和風險，使軟件開發人員提前無縫地選擇更為安全的組件。在應用程序中引入第三方組件和庫的初期就充分考慮了安全性評估，降低了重復進行安全評估的需要，從而加快開發過程。
如果具有已知風險和漏洞的組件對于開發工作來說是不可或缺的，那么開發團隊可以在首次引入該組件時對其進行判斷，并找出更好的解決方法來安全地使用該組件。
SCA方法和工具的目標不僅僅是掃描應用程序的資源和二進制文件來生成SBOM，更關鍵的挑戰在于準確地將組件的每個版本對應已知的漏洞。此外還有合規性方面：讓參與者無縫地檢查和解決組件造成的許可證沖突。
幾年前，這個過程可能很簡單。只要檢查MITRE或NVD提供的CVE feeds，并將它們對應到應用程序的組件版本就足夠了。在一項研究中，中佛羅里達大學、喬治梅森大學和佐治亞理工大學合作發表了一篇論文，表明：CVE的建議往往是不準確的，并且具有不一致性。另外，CPE（Common Platform Enumeration）平臺數據在這些建議中的呈現方式，也可能使CVE數據被曲解。
例如，針對Tomcat服務器中漏洞發布的CVE建議可能僅適用于Apache Tomcat命名空間下的選定組件，例如org、Apache、tomcat:coyote，而不是整個ApacheTomcat名稱空間，但CVE建議中提到的CPE，可能并不能從而清楚地從而此局限性。
因此，SCA工具需要足夠智能，以準確地將安全漏洞對應到受影響的組件，而不是盲目地相信CVE建議，標記良性組件。為了最大限度地減少開發人員之間的沖突，同時讓安全評估和合規團隊和平相處，SCA解決方案需要在避免引入漏報的風險（即未能發現安全風險）的情況下，最大限度地減少結果中出現誤報漏洞的可能性。但這可能需要人工干預、安全研究以及基于簽名的文件掃描工具。
此外，僅依靠CVE feeds獲取安全情報是不夠的。漏洞咨詢可能出現在產品供應商網站、GitHub和許多其他地方，包括私人數據庫。同樣的，關于零日攻擊的概念驗證漏洞以及已知漏洞可能會出現在漏洞數據庫、黑客論壇和其他神秘的地方。然而，并不是所有的SCA工具都是相同的，也并不是所有的SCA工具都需要有從大量的資源中獲取情報，并理解成千上萬的情報的能力。
新的供應鏈威脅：惡意軟件、被劫持的庫、依賴關系混亂
組織選擇SCA工具時，不僅需要考慮已知的安全風險和漏洞，同時也更加需要考慮層出不窮的新型攻擊。
就好像領先零日攻擊已經不再是問題一樣，正如我們所見，誤植域名攻擊以及滲透到npm、PyPI和RubyGems等開放源代碼注冊中心的依賴混淆惡意軟件的出現率越來越高。并且，這些攻擊均處于一個不斷發展的階段。
通過分析滲透到開源生態系統中的數百個惡意軟件樣本和依賴混淆，。2021年10月，功能性勒索代碼第一次被發現包含在一個名為noblox.js-proxies的“誤植域名”中。這個合法的包名為noblox.js-proxied，是官方Noblox的鏡像，Roblox游戲的一個API封裝包。
同月，不法分子還劫持了熱門的NPM庫、 ua-parser-js、 coa 和 rc，向其中安裝加密器和密碼竊取器。由于UA解析器庫每周下載超過700萬次，臉書、微軟、亞馬遜、谷歌等科技公司都在使用它，這也表明了此次劫持可能造成的影響巨大。同樣地，coa每周的下載量約為900萬次，rc約為1400萬次。
然而，這起供應鏈事件并不僅僅是一次誤植域名攻擊或依賴關系劫持攻擊，同時不法分子也竊取了這些項目背后的主要維護者的npm賬戶。JetBrains透露了對Kotlin/JS開發人員的潛在影響：由于uaparser-js是Karma測試框架的依賴項之一，Kotlin/JS開發人員在遭到攻擊期間運行了Karma測試用例。
所有這些都引發了一個問題：你的SCA工具是否能夠在惡意軟件注入、網絡釣魚攻擊、依賴性劫持和受損庫分布到下游前發現它們？
對于自動化工具來說，識別構成應用程序的數千個組件本身就是一項艱巨的任務，更不用說開發人員團隊了。同樣困難的還有篩選安全源的任務，這需要列出數千個可能適用于或不適用于你應用程序的漏洞。最后，不斷演變的威脅形勢進一步使軟件供應鏈的安全性和完整性問題變得復雜。將全面、快速、準確的SCA解決方案集成到軟件開發工作流程中已經變得至關重要，然而獲得一個能夠解決上述大多數新威脅的解決方案仍然是一個挑戰。
附：數世咨詢中國數字安全能力圖譜中“開發安全”及能力企業
數世點評
開源組件的廣泛引用，為高速迭代的軟件應用開發帶來了極大的便利，提高研發效率的同時，也降低了開發成本。但與此同時，開源組件所攜帶的的各種安全隱患也一并進入了軟件應用。隨著應用交付規模和頻率的日益增長，人們越來越重視開發效率，卻逐漸淡化了安全的重要性。然而軟件開發安全才是“木桶上那根最短的木板”。只有做好合規風險管控和安全態勢的感知，才能使軟件開發工作順利且高質量的完成。所以，選擇適合自己的SCA工具，并有效地將其集成在開發流程中是軟件開發工作中的必不可少的環節。
