軟體組成分析

在軟體開發過程中，常會使用不同的組件來進行開發[6]。使用软件组件可以將複雜的較大組件分割成較小的程式碼，增加靈活性，以後也可以配合新的需求而復用（reuse）這些組件[7]。在1990年代末，開放原始碼軟體（OSS）開始流行，此作法應用得更廣，也可以加速軟體開發時程，縮短產品上市時間[8]

不過，使用開源軟體也為應用程式引入了風險，風險可以分為以下五類[9]：

• 開源軟體版本控制：導入新版本時，可能會有軟體變更造成的風險。
• 安全性：組件漏洞的風險（CVE）。
• 授權：智慧財產（IP）法律要求的風險。
• 開發：已有代碼以及開源軟體之間的相容性風險。
• 支持：文件化（documentation）不足或是軟體組件過期的風險。

在开放源代码促进会在1998年2月建立之後不久[10]，也有人注意到開源軟體相關的風險[11]，各組織就試著用試算表以及文件來追蹤開發者所使用的開源組件，設法進行管理[12]。

對於密集使用開源組件的組織，需要自動化開源風險的分析及管理。因此產生了幫助組織管理開源風險的軟體，稱為軟體組成分析（Software Composition Analysis, SCA）。SCA設法偵測軟體應用程式中有的所有第三方組件，減少相關安全漏洞、IP授權需求、及軟體過期的相關風險。

組織中的不同部門裡，SCA會有不同的用途。依組織的大小以及結構不同，會使用SCA的部門也會不同。IT部門會用SCA，和共同利害相關者（包括資訊長CIO、技術長CTO以及主企業架構師 Chief Enterprise Architects）來實現及運作相關技術。安全和授權的資料會讓資安長（Chief Information Security Officers, CISO）確定安全風險，由Chief IP officer或首席合規官（Chief Compliance officer）處理智慧財產權的風險[13]。

有些SCA產品可以和開發產品時會使用的整合開發環境（IDE）整合，也有些SCA產品會是軟體品質控制流程中的一個步驟[14][15]

SCA產品（特別是其產生軟體材料表的能力）在一些國家（例如美國）是必要的，若要販售軟體給美國政府，軟體供應商，需要提供軟體材料表[16]。

另一個使用SCA的情境是在技術的盡責查證。在開始併購（M&A）流程前，需由獨立諮詢公司審核目標團隊軟體相關的風險[17]。

SCA產品自動化的特點是其主要優點。開發者使用及整理開源組件時，不需另外花費心力整理資料[18]。

目前SCA的產品有以下的缺點：

• 複雜及費心力的配置，可能需要花幾個月才能完全正常運作[19]
• 每一個SCA產品都有其專屬的開源組件資料庫，在大小以及覆蓋率上有很大的差異[20]
• 會把漏洞資料限制在只在NVD上公開報告的資料（可能是在發現漏洞後數個月才會公開報告）[21]
• 在依照SCA報告所採取的行動上，沒有自動化的指南[22]
• 在開源軟體授權的法律要求上，沒有對應的指引[23]

• 安全性測試
• 开源软件
• 公共漏洞和暴露
• 開源授權
• 軟體智能

• GSS資安電子報0181期【 SAST vs. SCA: 這就像蘋果與橘子的比較】