什麼是 Software Composition Analysis (SCA)？

什麼是 Software Composition Analysis？

您的開發團隊剛將一項關鍵更新推送到正式環境。部署成功。三週後，您發現該更新包含一個正遭攻擊者積極利用的脆弱開源元件。該程式庫版本落後多個版本，在 National Vulnerability Database 中被標記為重大，且存在於您不知道存在的傳遞相依性中。

開源軟體如今已構成企業程式碼庫中的絕大多數，而應用程式通常帶有數百個相依性。Software Composition Analysis (SCA) 的存在，就是為了防止這些盲點成為入侵途徑。SCA 是分析軟體以識別、評估及管理開源與第三方元件風險的流程。您可以掃描原始碼、二進位檔或套件資訊清單，以盤點每個元件，並將其與弱點資料庫進行比對、檢查授權合規性，並產生可採取行動的報告。當整合至您的 CI/CD 流程時，SCA 會在脆弱元件進入正式環境前加以阻止。

了解 SCA 的作用只是全貌的一半。現代軟體開發中開源風險的規模，說明了為何它已成為安全性要求，而非可有可無的工具。

為什麼 Software Composition Analysis 很重要

開源元件帶來的實際風險，其規模往往被多數團隊低估。根據 CISA 的 Open Source Software Security Roadmap，一項研究發現，在各產業受研究的程式碼庫中，96% 都存在開源軟體。NIST 已承認，提交至 NVD 且需要分析的 弱點積壓數量持續增加，僅 2024 年 CVE 提交量就增加了 32%。這種積壓使組織無法利用標準化的嚴重性指引來妥善排定風險優先順序。

近期的 供應鏈攻擊說明了這一點：

• 2020 年的 SolarWinds 攻擊破壞了軟體建置流程，影響超過 18,000 個組織，包括美國政府機構與《財星》500 大企業。
• 2021 年 12 月的 Log4Shell 弱點 (CVE-2021-44228) 使數百萬個使用 Log4j 程式庫的應用程式暴露於遠端程式碼執行風險之下。CISA 稱其為有史以來發現最嚴重的弱點之一。
• 2021 年的 Codecov 外洩事件危及 CI/CD 流程，在被發現前的兩個月內，暴露了來自超過 29,000 名客戶的憑證與原始碼。

每起事件都利用了開放原始碼元件或建置流程中的弱點，而 SCA 正是為了找出這些問題而設計。SCA 會以持續監控的方式整合到您的安全營運中，而非一次性的掃描。當新的弱點影響到正式環境元件時，您的 SCA 平台會發出警示，並阻擋包含已知弱點或不相容授權的建置。當攻擊者將惡意套件注入公開儲存庫時，您的 SCA 工具會將元件雜湊與已知良好的簽章進行比對，以找出 供應鏈竄改。

SCA 是數種應用程式安全測試方法之一。了解它與 SAST 和 DAST 的差異，有助於釐清各自適合您安全計畫中的哪個位置。

SCA 與 SAST 與 DAST 的比較

應用程式安全測試可分為三種不同領域，各自針對您程式碼庫中的不同攻擊面。

1. Software Composition Analysis (SCA) 會檢視整合至您應用程式中的第三方開源元件與程式庫。它可識別您團隊未自行撰寫之程式碼中的已知弱點、授權風險與供應鏈威脅。SCA 會掃描套件資訊清單、二進位檔與相依性樹，然後將結果與 NVD 和 GitHub Security Advisories 等弱點資料庫進行交叉比對。
2. Static Application Security Testing (SAST)會分析您的專有原始碼以找出安全性缺陷，包括注入弱點、不安全的資料處理與驗證弱點，也就是您團隊自行撰寫的程式碼中的問題。SAST 無需執行應用程式即可運作，透過掃描原始原始碼或編譯後的位元組碼，在執行階段前標示問題。
3. Dynamic Application Security Testing (DAST)會從外部測試執行中的應用程式，方法是模擬對即時端點的真實攻擊。DAST 可找出執行階段弱點，例如跨網站指令碼攻擊 (XSS)、驗證機制失效，以及只有在應用程式部署並回應請求時才會出現的伺服器設定錯誤。

企業程式碼庫主要包含開放原始碼元件，因此您需要這三者。先在您的 CI/CD 管線中執行 SCA，以便在 SAST 檢查您的專有程式碼之前先攔截有弱點的相依性，接著再針對已部署的應用程式使用 DAST 進行驗證。這種分層方法同時涵蓋您撰寫的程式碼與您承接的程式碼。

在釐清這些差異後，下一步是了解讓 SCA 平台發揮效能的核心元件。

軟體組成分析的核心元件

SCA 平台結合四項互補能力，將元件清單轉化為可採取行動的安全情報。

1. 開放原始碼清單與弱點識別構成基礎。 您的 SCA 工具會執行深度相依性解析，對您在 package.json 或 pom.xml 檔案中明確宣告的程式庫，以及這些程式庫所引入的傳遞相依性進行對應。根據 OWASP 相依性指南，絕大多數弱點存在於傳遞相依性中，而非您可直接控制的直接相依性。該工具會將您的清單與多個弱點資料庫進行交叉比對，包括 National Vulnerability Database (NVD)、MITRE CVE database、GitHub Security Advisories，以及供應商特定的安全公告。
2. 授權合規管理 可針對您的軟體產品組合中的開放原始碼授權提供自主追蹤。該工具會識別授權類型，並標示不相容授權之間的潛在衝突。獨立分析師評估指出，授權分析與指引是區分企業級 SCA 平台與基本掃描工具的關鍵標準。
3. 軟體物料清單 (SBOM) 產生 會建立完整清單，編錄所有元件、版本、授權與關係。您的 SCA 工具會以 CycloneDX 或 SPDX 等標準化格式匯出 SBOM，實現跨安全工具的互通性並滿足法規要求。根據 NIST 的 Secure Software Development Framework (SSDF) 指引，組織必須在開發期間自主產生 SBOM 與 SLSA 來源文件，以識別、評估並阻止軟體供應鏈風險。
4. 政策強制執行與風險優先排序 將其他三項能力串聯起來。您的 SCA 平台會套用可設定的政策，封鎖包含高嚴重性弱點、未核准授權或來自不受信任來源元件的建置。進階實作還會加入可達性分析與可利用性預測評分，依據實際風險而非單純弱點數量來排序發現結果。

這些能力共同構成了在實務中推動 SCA 掃描與分析的引擎。

軟體組成分析的運作方式

掃描技術

現代 SCA 使用四種互補的掃描技術，建立您軟體組成的完整圖像：

1. 資訊清單剖析 會檢查 package.json、pom.xml 或 requirements.txt 等套件管理器檔案中的已宣告相依性。
2. 原始碼掃描 會分析應用程式碼以找出匯入的程式庫。
3. 二進位分析 會在原始碼存取受限時檢查已編譯的應用程式。
4. 相依性樹狀對應 會建立跨越多個層級的完整相依性圖譜。

您會將 SCA 放在 CI/CD 管線的早期階段，先於 SAST and DAST 活動，以防止有弱點的程式庫進入正式環境。自主檢查會對 pull request 中的所有成品執行，包括相依性資訊清單。

比對與修補

您的 SCA 工具會執行多資料庫關聯分析，查詢 NVD、CVE 資料庫、GitHub Security Advisories，以及供應商特定的安全公告，以最大化涵蓋範圍。比對工作流程會使用精確版本資訊編錄所有元件，查詢整合式弱點資料庫以判定已安裝版本是否落在有弱點的範圍內，並分析授權類型是否存在政策衝突。

有效的 SCA 也會產生修補建議：版本升級路徑、修補程式可用性分析，以及風險評分。您的平台應提供自主指引，說明可修正弱點的最低安全版本。此工作流程會持續運作，監控已在正式環境中的元件，並在揭露新弱點時向您發出警示。

這些掃描與比對能力構成技術基礎。建立在其上的工具則提供安全團隊日常依賴的營運價值。

SCA 工具的核心能力

SCA 工具會將原始掃描資料轉化為您的團隊可採取行動的營運安全工作流程。五項能力將有效的 SCA 工具與基本相依性掃描器區分開來。

• 持續監控與警示 會即時根據新揭露的弱點追蹤您已部署的元件。某個在建置時通過所有檢查的元件，可能在研究人員發布新的 CVE 的那一刻就成為重大風險。您的 SCA 工具應在數小時內通知您，而不是等到下一次排程掃描。
• CI/CD 管線強制執行 會為您提供政策閘道，在發現重大弱點或未核准授權時自動使建置失敗。這會將修補時機前移到問題引入的當下，而不是等到部署後才發現，因為此時修復成本僅為正式環境緊急修補的一小部分。
• 可達性分析 可判定您的應用程式是否實際呼叫了已標記相依項中的易受攻擊程式碼路徑。程式庫可能包含已知 CVE，但如果您的應用程式從未呼叫受影響的函式，實際風險就會大幅降低。此分析可排除警示雜訊，並將修補工作聚焦於真正可被利用之處。
• 自動化修補指引 提供可執行的升級路徑，包括每項發現的最低安全版本、修補程式可用性，以及重大變更警告。有效的 SCA 工具不會只是把弱點清單丟給開發人員，而是會指出具體修正方式及其對相依性樹的下游影響。
• SBOM 匯出與合規報告 會產生 CycloneDX 或 SPDX 格式的機器可讀清單，以支援稽核軌跡與法規要求。這些報告會對應您應用程式組合中的每個元件、版本、授權與關係，可直接用於內部稽核、客戶要求或聯邦合規提交。

這些營運能力可在您的應用程式組合中帶來可衡量的安全與合規成果。

軟體組成分析的主要優勢

若有效實作，SCA 可帶來三項可衡量成果，足以支持在安全、合規與開發團隊中推動採用。

• 供應鏈中的弱點可視性： SCA 可讓您對相依項取得基礎可視性，識別弱點、授權與元件來源。發佈到開源登錄庫的惡意套件數量逐年大幅成長，攻擊者也愈來愈常鎖定 npm、PyPI 與其他儲存庫，透過軟體供應鏈散布惡意軟體。NIST 已指出 持續增加的 NVD 積壓 導致許多新的 CVE 沒有嚴重性評分，限制現有安全工具正確評估風險的能力。SCA 透過專有弱點情報與可達性分析填補了這項缺口。
• 促進法規遵循： 聯邦框架現在要求具備 SBOM 與弱點監控能力，而這正是 SCA 工具所提供的。 NIST 的 Secure Software Development Framework 要求組織在開發期間自主產生 SBOM 與 SLSA 來源證明文件。 Executive Order 14028 已將軟體供應鏈安全從可選的最佳實務提升為影響聯邦承包資格的合規要求。歐盟 Cyber Resilience Act 要求具有數位元素的產品必須採用 secure-by-design 實務進行開發。
• AI 擴大風險預防： AI 輔助開發正在加快相依項變更的速度，同時引入新的錯誤模式。一項 透過 USENIX 發表的同儕審查研究 發現，產生程式碼的 LLM 出現套件幻覺的平均比率為 19.6%，也就是推薦了不存在的軟體套件。AI 代理可能擴大風險，因為它們無法檢查來源、政策或已知惡意指標。SCA 提供治理層，可防止 AI 程式設計助理以機器速度引入易受攻擊或惡意元件。

即使具備這些優勢，授權合規仍是 SCA 所處理、卻最常被低估的風險之一。

軟體組成分析與開源授權合規

開源授權違規會帶來實際的法律與財務後果。根據 CISA 關於 SBOM 使用的指引，違反開源授權可能導致軟體停售或召回、罰款，以及聲譽受損。這些後果也可能透過未預期成本或支援突然中止，連帶影響下游組織。

每個開源元件都帶有授權，而授權大致可分為兩大類：

• 寬鬆授權 如 MIT、Apache 2.0 與 BSD，允許您在專有應用程式中使用、修改及散布程式碼，且義務極少，通常只需標示出處。
• Copyleft 授權 如 GNU General Public License (GPL) 則施加更嚴格的要求：如果您的專有程式碼成為 GPL 授權元件的衍生作品，且您散布該組合作品，則該衍生作品也必須依 GPL 釋出。這種「病毒式」效應可能迫使您揭露原本無意開源的專有原始碼。

風險會透過傳遞相依項而倍增。安裝單一套件可能會拉入數十個額外相依項，而每個相依項都帶有自己的授權。您的應用程式可能包含數百項分散於相依性樹多個層級的授權義務，而一個深藏三層的單一 copyleft 元件，就可能觸發影響整個產品的合規要求。以這種規模進行人工追蹤並不可行。

SCA 工具可透過自主掃描您的程式碼庫、識別直接與傳遞相依項中的每一項授權，並在衝突進入正式環境前加以標示，來解決此問題。您的 SCA 平台應在 CI/CD 管線中強制執行授權政策，封鎖引入未核准授權類型的建置，並在專有程式碼庫中出現 copyleft 元件時通知法務團隊。這種層級的治理對於管理 供應鏈風險 的企業級組織至關重要，尤其在併購期間更是如此，因為在盡職調查中發現未揭露的 GPL 使用情況，曾導致交易破局或觸發重大估值下修。

儘管具備這些能力，採用 SCA 仍伴隨您需要預先規劃的實際挑戰。

軟體組成分析的挑戰與限制

SCA 並非部署後即可置之不理的解決方案。組織會遇到四項反覆出現的挑戰，足以削弱即使資金充足的實作成效。

1. 誤判與資料準確性問題： 品質不佳的弱點情報與不精確的比對會削弱 SCA 的成效。當工具產生成千上萬筆發現，卻無法區分可被利用的弱點與理論風險時，就會出現警示疲勞。許多新弱點缺乏 NVD 評分的嚴重性評分缺口，讓跨企業應用程式組合的優先順序判定更加困難。
2. 修補優先順序判定的複雜性: 您需要區分每個應用程式的眾多相依項中，哪些實際構成可被利用的風險。僅靠 CVSS 評分並不足夠。您需要 EPSS (Exploit Prediction Scoring System) 資料、顯示是否呼叫易受攻擊程式碼路徑的可達性分析，以及關於應用程式關鍵性的業務情境。大多數 SCA 實作都缺乏這類優先順序判定能力。
3. 傳遞相依項的複雜性： 您的相依項之相依項會造成連鎖式修補挑戰。升級一個元件可能引入新的弱點，或破壞應用程式功能。根據 OWASP 相依性指引，開發團隊必須完整理解從第一層相依項經過多個層級直到易受攻擊元件的完整關係鏈。這需要許多開發團隊所欠缺的應用程式安全技能。
4. 開發人員工作流程整合摩擦： 會拖慢開發速度的安全掃描會遭到繞過。當 SCA 工具產生報告時，開發人員必須手動跨不同平台進行審查，修補作業因此停滯。您需要 IDE 整合、具備內嵌回饋的 pull request 掃描，以及使用可達性分析進行風險優先排序，以降低警示疲勞。關鍵漏洞即使已被自主識別，往往仍需很長時間才能修補，原因通常是糟糕的開發人員體驗造成了營運障礙。

這些挑戰確實存在，但大多源自於實作決策，而非 SCA 的根本限制。了解部署失敗之處，有助於您在自身導入過程中避免最常見的陷阱。

常見的 Software Composition Analysis 實作錯誤

企業資安團隊在實作 SCA 時，經常會犯五個錯誤。避免這些錯誤可大幅提升您的 SCA 投資報酬。

• 忽略傳遞相依性： 大多數漏洞存在於傳遞相依性中，但團隊卻專注於直接相依性。攻擊者會特別鎖定這些隱藏層，因為它們較不顯眼，且不在開發人員的直接控制範圍內。
• 未依可利用性進行優先排序： 將所有 CVEs 視為同等重要，會造成難以負荷的警示疲勞。即使有漏洞的程式碼可達，真正重要的是其可利用性。然而，許多團隊僅依賴 CVSS 分數，而未考量漏洞在其特定情境中是否 वास्तव可被利用。不精確的漏洞比對會浪費修補資源，而真正可被利用的漏洞卻仍未獲處理。
• 忽視授權合規： 許多團隊在實作 SCA 工具時，只專注於漏洞識別，卻忽略授權合規風險。商業軟體稽核經常揭露授權衝突，包括散布時未附授權的開源元件，或造成法律義務不明確的客製化授權。這些風險可能使併購交易脫軌，或引發智慧財產訴訟。
• 不良的 CI/CD 整合： 在開發生命週期過晚的階段執行掃描，會推高修補成本。若在發現關鍵漏洞時未透過使建置失敗來強制採取行動，而只是產生漏洞報告，就會留下缺口。忽略 IDE 整合，會使發現結果脫離開發人員的工作環境。若將 SCA 視為時間點掃描，而非對已在正式環境中的元件進行持續監控，就會錯失新揭露的威脅。
• 缺乏開發人員訓練： 若沒有適當訓練，開發人員會將安全發現視為阻礙，而非可採取行動的情報。他們不了解傳遞相依性風險，缺乏不同修補策略的知識，也無法解讀漏洞報告以判斷實際風險。根據 OWASP 相依性指引，開發團隊需要具備應用程式安全技能，才能分析漏洞影響並理解複雜的傳遞關係。

避免這五個錯誤，能讓您領先大多數企業 SCA 部署。再搭配一套經驗證的最佳實務，將可進一步強化您的計畫。

Software Composition Analysis 最佳實務

SCA 是流於勾選核取方塊的作業，還是有效的安全控制，差別就在於五項營運實務。

實作以風險為基礎的漏洞優先排序： 不要只看簡單的漏洞數量，而要進行更成熟的風險評估。部署可透過靜態方式對傳遞相依性中的呼叫路徑建模的工具，以判斷從您的程式碼到有漏洞元件之間是否存在可能路徑。使用多種訊號進行優先排序：

• 以 CVSS 分數作為基準嚴重性
• 以 EPSS 分數作為實際利用可能性
• 針對您的程式碼庫進行的可達性分析
• 包含受影響應用程式關鍵性在內的業務情境

完整的 SBOM 管理： 在每次建置時，以標準格式（CycloneDX 或 SPDX）產生 SBOM，以支援互通性與法規遵循。以與安全相關的中繼資料強化 SBOM，包括元件來源、下載位置與密碼編譯雜湊，以改善 漏洞管理 並追蹤授權義務。

Shift-left 安全整合: 根據 NIST SP 800-204D 指引，組織應對 pull request 所涵蓋的所有成品執行自主檢查，包括安全掃描。透過在程式碼進入正式環境前整合至 CI/CD 管線的掃描，將 SCA 提前至開發生命週期早期。將工具設定為在發現關鍵漏洞時使建置失敗，而不是只產生開發人員可能忽略的報告。

有效的修補工作流程： 遵循 OWASP 指引，在嘗試修補之前，必須完整了解整體相依關係。對於 開源相依性，可考慮建立修補程式與 pull request，在保護您組織的同時，也協助他人保護其應用程式。實作持續監控，讓您的 SCA 平台監看已在正式環境中的元件是否有新揭露的漏洞。

開發人員訓練： 推動開源風險相關教育，讓團隊能有效整合 SCA 實務。訓練開發人員了解，傳遞相依性經常在他們未察覺的情況下引入漏洞。提供結合 CVSS、EPSS 與可達性分析的框架，而不是將所有漏洞視為具有相同急迫性。涵蓋不同開源授權的法律意涵，以及組織對可接受授權類型的政策。

有了這些實務，合適的平台就能將 SCA 從手動負擔轉變為自主防禦層。

使用 SentinelOne 強化 Software Composition Analysis

Singularity Cloud Security 透過結合無代理掃描與其 Offensive Security Engine™，強化您的漏洞管理。此平台會產生 Verified Exploit Paths™，模擬真實攻擊者行為，以判斷哪些漏洞在您的環境中確實可達且可被利用，從而區分理論風險與可被主動利用的弱點。這種方法可讓您的資安團隊將修補重點放在真正重要的曝險上，而不是追逐低風險發現。

透過 CI/CD 實現 Shift-left

將 CNS 整合至 CI/CD 管線，讓 IaC 範本、容器映像與登錄庫在每次建置時都能針對錯誤設定、漏洞與外洩機密進行掃描。原則控制可僅封鎖引入可利用風險的建置，讓健康的版本持續推進，並降低對高風險 hotfix 與 rollback 的需求。

掃描程式碼儲存庫、IaC 與安全的 SaaS 應用程式

持續掃描已設定 CNS 掃描的儲存庫與管線，偵測橫跨雲端平台、支付供應商、AI/LLM 服務、SaaS 應用程式及開發人員工具的 750 多種類型機密。於部署前發現這些問題，可降低因憑證遭入侵而導致的高成本資料外洩、服務中斷及事件回應作業風險。

掃描 AWS CloudFormation、Terraform 與 Kubernetes (K8s) manifests，以及 Helm charts 等熱門平台上的政策。SentinelOne 內建超過 1,000+ 條預先建置規則，可立即進行安全性檢查。其依據 CIS、NIST、GPDR 與 PCI-DSS 等合規框架建構。自訂政策引擎可讓您的安全團隊使用 OPA/Rego 指令碼建立並強制執行自訂規則，以符合業務標準。您也可以在 IaC 檔案與儲存庫中自動偵測 API 金鑰、雲端憑證與驗證權杖。

主動驗證您的機密

傳統的 機密掃描工具 會列出冗長的憑證清單，其中許多可能已輪替、撤銷，或綁定至已淘汰的測試服務。CNS 會驗證外洩的機密是否仍處於有效狀態，以及其使用位置，讓團隊避免將時間浪費在舊的／非冗餘的發現項目與低影響性的金鑰上。修復工作可集中於數量更少、仍在使用且高價值的憑證，因為這些憑證一旦遭入侵，極可能實際導致資料遺失、詐欺或服務中斷。

取得從程式碼到雲端的利用路徑脈絡

向開發人員精確展示程式碼或 CI/CD 中的風險，例如錯誤設定、具弱點的基礎映像或外洩的機密，如何被用來存取特定雲端資源或敏感資料。CNS 會將利用路徑詳細資訊與受影響資產附加至每項發現，將一般性警示轉化為可直接修復的工單，使其更容易理解、採取行動與排定優先順序。

由 Hyperautomation 驅動的修復工作流程

使用 Hyperautomation 將已排定優先順序且具利用依據的發現，連同負責人、嚴重性與脈絡，一併導入 Jira 與其他工作流程工具。安全與工程團隊可在單一待辦清單上協作。

Purple AI 可使用代理式推理，自主調查警示，並提示分析師將手動調查轉換為永久性的 hyperautomation 工作流程。SentinelOne 可透過其 100 多個預先建置的整合，經由 Singularity Marketplace，在 Jira、Okta、Slack 與 ServiceNow 等第三方工具之間自動化安全動作。

該平台會產生 SBOM，彙整您容器化與雲端工作負載中的元件、程式庫與相依性，以支援 NIST SSDF 與 Executive Order 14028 下對軟體供應鏈透明度的要求。Singularity Cloud Native Security 會掃描程式碼儲存庫、infrastructure-as-code 範本，以及容器登錄，以在漏洞進入正式環境前加以識別，而其 secrets 掃描引擎可偵測超過 750 種硬式編碼認證資訊。這使您的 安全團隊 以取得整體雲端資產的可視性，識別哪些應用程式包含具弱點的元件，以及哪些需要立即修復。

申請 SentinelOne 示範，了解 Singularity Platform 如何保護您的軟體供應鏈。

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

重點整理

Software Composition Analysis 已從選用工具演進為聯邦強制要求的安全實務，並由 NIST 的 Secure Software Development Framework 與 Executive Order 14028 提供支持。由於企業程式碼庫主要包含開放原始碼元件，且每個應用程式通常具有數百個相依性，再加上產業研究顯示其中絕大多數都包含具弱點的元件，因此 SCA 提供了必要的可視性。 

有效的實作需要採用以風險為基礎的優先排序，運用可達性分析、以標準格式管理 SBOM、透過 pre-commit 掃描進行左移整合，以及針對供應鏈風險提供開發人員訓練。