軟體成分分析（SCA）完全指南
上一篇文章中，我們討論了 DAST 的概念、重要性及其工作原理。那在開發過程中如何查詢開源軟體包中的漏洞並學習如何修復？本指南帶你一起了解 SCA 工具及其最佳實踐。
如今，絕大多數程式碼驅動的應用程式都包括開源元件。但是，開原始碼可能包含一些致命的漏洞，比如 Log4Shell 漏洞。
軟體成分分析（SCA）是查詢開源軟體包中的漏洞並學習如何修復它們的最佳選擇，確保程式碼和應用程式處於安全狀態。本指南將帶你一起了解使用 SCA 工具時的最佳實踐。
什麼是軟體成分分析 SCA？
軟體成分分析 Software Compostition Analysis（SCA） 是一種用於管理開源元件應用安全的方法。通過 SCA，開發團隊可以快速跟蹤和分析引入專案的開源元件。同時，SCA 工具可以發現所有相關元件、支援庫以及它們之間直接和間接依賴關係。SCA 工具還可以檢測軟體許可證、已棄用的依賴項以及漏洞和潛在威脅。掃描過程會生成物料清單 Bill of Materials（BOM），從而提供專案軟體資產的完整清單。
SCA 本身並不新奇，但隨著開源元件的普及和廣泛應用，SCA 逐漸成為應用程式安全專案的關鍵部分，而 SCA 工具數量也隨之激增。包括 DevSecOps 在內的現代軟體開發實踐中，SCA 需要便於開發人員使用，同時也能讓安全團隊能夠有能力在軟體開發生命週期 Software Development Life Cycle （SDLC）內引導和指導開發人員安全地進行開發。
為什麼要使用 SCA？
開源元件儼然成為每個垂直領域軟體的主要部分。而 SCA 工具有助於跟蹤應用程式使用的開源元件，這從生產和安全形度來看都至關重要。
安全漏洞帶來的慘痛代價
Gartner 預計超過70%的應用程式因使用開源元件而產生缺陷和漏洞。正如美國徵信巨頭 Equifax 的案例所表明，這些漏洞可能會給企業和組織帶來災難性後果。
在此事件中，Equifax 最初表示，網路犯罪分子利用 Apache Struts 的漏洞獲取檔案。隨即，Equifax 在公告中確認，先前披露和修復的漏洞是就是在這次資料洩露事件中惡意攻擊者所利用的漏洞，當時這個漏洞的評分有10 分之高。而 Equifax 在漏洞出現後沒有及時修復，駭客利用其系統中未修復的 Apache Struts 漏洞發起攻擊，導致1.43億使用者的信用記錄被洩露，其中包括姓名、出生日期、地址，以及駕駛證號碼等，這是有史以來規模最大的資料洩露案。最終，此案以 Equifax 支付7億美元的賠償金和罰款，索賠期限延長四年落幕。
Equifax 漏洞事件成為安全行業，尤其是應用程式安全的重要標誌，因為它強調了控制措施的重要性，開源元件引入的風險應當得到管理。該漏洞也揭示了對速度的要求，企業需要能夠快速，重複地查詢和修復他們正在使用的開源軟體包中的漏洞。而在 Tidelift 2022年開源供應鏈報告中顯示，有57%的企業認為，即使有現代安全工具的助力，在使用開源進行開發時識別和解決安全漏洞仍然是一項巨大的挑戰。
為什麼 SCA 這麼重要？
越來越多的應用程式由開原始碼組成。據估計，開原始碼佔到了應用程式程式碼的90%。實際上應用程式是由不同的元件組成，企業需要保證所有的元件成分都是安全的，這樣才能夠有效地管理和降低風險。這也正是企業在確保程式碼庫安全時所面臨的挑戰。
開源已成為軟體領域的中流砥柱
軟體正在吞噬世界，而開源在吞噬軟體。在當今競爭激烈的市場中，開源能夠幫助公司將服務數位化，讓企業在市場中獲得一定的競爭優勢。
開源是怎樣幫助企業實現服務數位化的呢？當企業在進行軟體開發時，從零開始構建消耗大量的時間和資源。而使用提供完全相同功能的開源軟體包能夠有效降低這些成本。
開源本質上是高度靈活的。在社群的支援和嚴格審查下，開源通常很安全。同時，免費的開源軟體和元件能夠幫助企業和組織避免軟體廠商的束縛。
在 Tidelift 最近的一項研究中，68%的受訪者指出，節省資金和開發時間是企業鼓勵使用開源元件進行應用程式開發的首要原因。而48%的受訪者則表示，使用開源是為了提高應用程式開發和維護效率。開源的使用在新冠疫情之前就達到了頂峰，而疫情的出現加速了採用率。Gartner 預計，90% 的企業應用程式將依賴於開源的使用。
當今的軟體供應鏈
開源是構成現代雲原生應用程式的一部分。如今，應用程式更多是組裝而非從零構建。除了開源軟體包之外，應用程式還由專有程式碼、容器和基礎設施組裝而成，成為軟體供應鏈的組成部分。而軟體供應鏈中的這些元件和模組也是惡意攻擊的潛在目標。利用軟體供應鏈中的漏洞能對整個應用程式，進而擴大攻擊面。
以 Octopus Scanner 惡意軟體為例，它通過濫用構建過程影響整個供應鏈，經過該供應鏈產生的工件影響其他專案。受影響的專案可能會被許多不同的系統克隆、Fork 和使用，也就是所說的「套娃」攻擊。而最近的 SolarWinds 攻擊主要針對特定軟體，這也進一步證明了現代軟體供應鏈給企業和組織帶來的風險越來越大。
開源 ≠ 安全
開源專案被認為使用起來更安全。畢竟當整個社群參與維護和開發專案時，問題常常被更快地識別和修復。這當然包括安全漏洞在內的各種 bug。話雖如此，這並不代表開源是沒有風險的。
開源專案是公開的，且對所有人都是可見。當然也包括惡意攻擊者。在其中發現並修復的任何漏洞都會暴露給潛在的攻擊者。開源專案越受歡迎，該軟體包的吸引力就越大，而對應事件的攻擊影響也就越大。
當然企業使用開源元件需要自擔風險，因為沒有供應商通知他們缺陷，或者簽署的合同讓他們擺脫責任。
SCA 五大挑戰
如前文所述，SCA 是應用程式安全方法和工具的總稱，這些方法和工具通常在開發期間掃描應用程式（如 SAST），來定位應用程式中使用的開源元件，並隨後識別安全漏洞和軟體許可證問題。為了有效管理和降低這些開源元件帶來的風險，企業將面臨一系列與利用開源構建現代應用程式的方式相關的風險與挑戰。
1. 程式碼的低可見性
將開原始碼嵌入到應用程式程式碼庫中的方式帶來了巨大的可見性挑戰。開發人員可能會直接在程式碼中使用許多開源包，而這些包又包含一些開發人員不瞭解的其他開源包。這些直接或可傳遞的依賴關係複雜多層，因此很難對應用程式實際使用的開源進行端到端的可見性。
而絕大多數安全漏洞都存在於複雜多層的關係中。Snyk State of Open Source Security 報告發現，超過86%的 .js 節點漏洞是在可傳遞依賴項中發現的。在 Java 和 Ruby 上也發現了類似的數位。這意味著應用程式中的絕大多數安全漏洞通常都能在開原始碼中找到，開發人員甚至不知道他們使用了這些程式碼。
雲原生應用程式以另一種方式利用開源，這同樣可能會給企業帶來程式碼可見性的難題。容器映象可以由各種開源元件組成，這些元件還需要識別和測試漏洞。容器為開發人員提供的抽象層，從開發的角度來看是一個優勢，從安全形度來看也是一個弱點。
2. 依賴關係錯綜複雜
為了準確識別應用程式正在使用的依賴關係以及它們引入的漏洞，需要深入瞭解每個生態系統如何處理依賴關係。開源包在安裝時的解析、鎖定檔案、開發依賴關係 - 所有這些都是影響如何識別開源包中的漏洞並將決定後續修復步驟的要素。SCA 解決方案需要理解這些細微差別，以避免產生過多誤報。
3. 漏洞數量持續增加
由於已識別的漏洞數量龐大，因此掩蓋了漏洞的可見性及其對企業構成的風險。Snyk Intel 漏洞資料庫增加了10000多個漏洞，也反映了漏洞數量的持續增長。
這些上升趨勢會體現在已識別且需要注意的漏洞列表中，其中通常由數千個問題組成。鑑於開發和安全團隊可支配的資源有限，如果沒有一定的安全技能或嵌入高階安全專業知識的工具，就很難確定工作的優先順序。基於通用漏洞評分系統 CVSS （Common Vulnerability Scoring System）是評估風險和確定工作優先順序的常用方法，但這個方式存在一些固有的弱點需要在使用時特別注意。
4. 不易找到完善的漏洞資料庫
有關已知漏洞的資訊較為分散。國家漏洞資料庫（NVD）通常用於接收有關漏洞的更新，但其他來源（如問題跟蹤器、線上論壇、安全新聞通訊等）也能提供大量有關漏洞的安全情報。NVD 也可能無法及時新增漏洞。例如，NVD中92%的 JavaScript 漏洞都是事先新增到 Snyk 中的。及時瞭解漏洞很重要。
5. 安全檢查降低開發速度
開發人員的開發節奏很快，而安全團隊卻很難趕上。由於需要更快、更頻繁地交付程式碼，開發人員越來越多地使用到開源。缺乏人力和資源的安全團隊試圖在軟體開發生命週期的各個不同階段進行安全檢查，但這實際上導致開發速度減慢。然而減慢的開發節奏可能對整體應用程式安全更不利，因此這些檢查最終會被繞過或忽略。
因此，在安全模型中出現了 DevSecOps 和安全防護左移（Shift Left）的概念，即將安全責任轉移到開發團隊中，以確保對開發工作流的干擾最小，同時確保安全性。
SCA 的6個最佳實踐
軟體組合分析 （SCA） 工具是查詢開源包中的漏洞並學習如何修復它們的最佳選擇，保護程式碼和應用程式的執行狀況。在使用 SCA 工具時，請參考以下六個最佳實踐。
1. 使用開發者友好的 SCA 工具
開發人員忙於寫程式碼。他們需要全面思考，高效設計，並快速迭代。因此對開發人員不友好的 SCA 工具會減慢開發節奏。而便於開發人員使用的 SCA 工具能夠輕鬆設定和使用。它應該簡單地與現有的開發工作流和工具整合，並儘早在軟體開發生命週期（SDLC）中整合。
在確定工具後，也需要給開發人員普及 SCA 的重要性以及用處。讓開發人員明確從開發初期就考慮安全問題，並將安全檢查完善到他們的工作流程中。這將有效避免開發人員因為修復安全問題而重寫程式碼所花費的時間。
2. 瞭解依賴關係
開源包有兩種依賴關係：直接依賴和傳遞依賴。直接依賴項，就是你直接使用在專案裡的開源包。而直接依賴項之一使用的開源包，便是傳遞（間接）依賴項了。
分析表明，開源軟體包中80%的漏洞存在於傳遞依賴關係中。這意味著程式碼中的大多數漏洞都包含在未知且正在使用的（巢狀）依賴項中。而一個優秀的 SCA 工具，應該準確地檢查程式碼中的所有依賴項，並且應該能夠識別和檢查傳遞依賴項。瞭解程式碼中使用的開源包的深度和複雜性，能夠確保在各個級別都進行合適有效的漏洞檢測。
3. 自動掃描與可操作修復
一個好的 SCA 工具可以為企業提供定期執行自動掃描的選項。利用這一點，企業可以來設定對程式碼的主動和持續監控。自動掃描能夠提供有關漏洞所在位置以及如何修復漏洞的可操作警報。請認真對待 SCA 工具提供的修復漏洞的方向，採用該方向來應用修復程式。
4. 將 SCA 整合到 CI/CD 流水線中
使用SCA 工具並不意味著需要在開發—測試—生產過程中停滯下來。相反，企業應該將 SCA 掃描整合到 CI/CD 流水線中，以便識別和修復漏洞，併成為軟體開發和構建過程中的一個功能部分。同時，這也可以幫助開發人員更輕鬆地適應程式碼安全作為其日常工作流程一部分。
5. 利用報告及物料清單
包括美國聯邦政府在內的許多組織，在購買軟體時都要求包含軟體物料清單 （SBOM） 報告。在產品中提供詳細的物料清單表明企業瞭解跟蹤應用程式內每個元件的價值。有關安全掃描和修復的清晰報告也非常強大。提供有關企業的安全實踐和修復的漏洞數量的詳細報告，表明對軟體安全的承諾和踐行。
6. 加強安全策略，提高許可證合規性
清楚地瞭解開發人員使用的開源包，將有助於企業建立定義和實施安全準則的策略。企業可以使用通過漏洞掃描獲得的知識，指導開發人員在使用開源軟體包時考慮安全性。
跟蹤開原始碼本身對於應用程式安全很重要，同時跟蹤開源許可證對於合規性也至關重要。開源許可證明確了開源軟體包的法律使用條款，使用 SCA 工具能夠幫助企業深入瞭解開源元件的許可條款和條件。在制定安全策略時，企業也需要鼓勵開發人員在軟體開發生命週期初期採用許可證合規性的規範。
SCA 的未來
鑑於開源的日益普及，以及最近違規和網路攻擊的宣傳，大眾對 SCA 的關注熱度逐步上升。開源在推動數位化轉型中所扮演著不可忽視的角色，而這個趨勢在近期幾乎不會發生改變。
企業使用開源來幫助他們在各自的市場中擁有競爭優勢。同時，人們逐漸意識到，他們必須控制開源的使用來管理和減少其伴隨的風險。當 SCA 工具能夠滿足我們所提到的這些關鍵需求，將能成功幫助企業在市場中更好地競爭。
參考連結：
Equifax 資訊洩露案落幕
https://www.secrss.com/articles/39075TideLift: 2020 managed opensource survey
https://tidelift.com/subscription/2020-managed-open-source-survey