檢查及驗證程式代碼基底以符合規範

在實施自動化軟體組合分析工具之前，組織必須了解其程式碼庫中需要檢查和驗證的內容。 現代應用程式包含數百或數千個依賴項，使得手動檢查不切實際。 依賴性發現、漏洞評估和合規性驗證的系統方法至關重要。

為什麼檢查和驗證很重要

依賴性挑戰： 應用程式不僅僅依賴於您直接匯入的套件。 每個直接依賴通常依賴於其他套件（可轉移依賴），從而創建深層依賴樹。 典型應用程式可能會直接參照 20-30 個套件，但間接依賴 200-500 個套件。 您應對所有相依性中的漏洞和授權義務負責，而不僅僅是直接相依性。

安全必要條件： 相依性中的安全性弱點代表重大風險。 攻擊者積極利用流行軟體包中的已知漏洞，使未修補的依賴項成為有吸引力的目標。 備受矚目的違規行為通常涉及利用組織未能更新的開源元件中的已知漏洞。

合規要求： 違反許可證可能會導致法律訴訟、強制開源專有程式碼、分發限制和聲譽受損。 組織必須追蹤每個相依性的授權義務，並確保遵守授權條款。

操作現實： 依賴關係不斷變化。 每天都有新的漏洞被披露，軟件包收到更新，維護者放棄項目，並發布新版本。 一次性檢查是不夠的，需要持續驗證。

檢查和驗證項目

全面的程式碼庫檢查涵蓋多個維度：

依賴關係盤點

建立完整的物料清單：

• 直接依賴： 套件資訊清單檔案中明確列出的套件 （package.json、 requirements.txt、 pom.xml、 *.csproj） 。
• 可轉移相依性：您的直接相依性所需的套件，多個層級深度。
• 開發依賴： 在開發和測試期間使用但未隨生產程式碼一起提供的套件。
• 版本追蹤： 目前使用中的每個套件的特定版本。
• 相依性來源： 哪些套件登錄提供相依性 （npm、PyPI、NuGet、Maven Central、私人登錄）。

為什麼完整庫存很重要：

• 漏洞管理： 您無法修復您不知道的漏洞。
• 授權合規性： 必須追蹤所有相依性的授權義務，而不僅僅是直接相依性。
• 更新規劃： 了解相依性關係有助於規劃不會破壞相容性的更新。
• 供應鏈可見性： 確切地知道您的應用程式中包含哪些外部程式碼。

安全漏洞檢測

識別已知漏洞：

• CVE（常見漏洞和暴露）映射： 將相依性版本與包含已知弱點的 CVE 資料庫進行比對。
• 嚴重性評估： 使用 CVSS（通用漏洞評分系統）分數評估漏洞嚴重性，範圍為 0-10。
• 可利用性分析： 判斷漏洞是否在野外被積極利用。
• 修補程式可用性： 確定哪些版本修復了漏洞以及補丁是否可用。

了解漏洞資料庫：

• 國家漏洞資料庫 （NVD）： 基於 CVE 識別碼的美國政府漏洞數據存儲庫。
• GitHub 諮詢資料庫： 針對跨多個生態系統的套件策劃安全建議。
• 安全郵件列表： 語言和架構特定的安全性通知。
• 供應商資料庫： 商業 SCA 工具維護具有額外情報的專有漏洞資料庫。

相依性中的弱點類別：

• 插入缺陷：Web 架構中的 SQL 注入、命令注入、跨網站指令碼弱點。
• 驗證問題： 身份驗證實作薄弱、會話管理問題、憑證處理缺陷。
• 敏感資料外洩： 資料儲存不安全、加密不充分、資訊外洩。
• 安全性設定錯誤： 具有已知弱點的預設配置，啟用了不必要的功能。
• 拒絕服務： 資源耗盡漏洞、演算法複雜性問題。
• 還原序列化缺陷： 不安全的還原序列化導致遠端程式碼執行。

授權合規性驗證

確定許可義務：

• 授權偵測： 識別哪些授權適用於每個相依性。
• 授權分類：將授權分類為寬鬆、弱式 Copyleft、強式 Copyleft 或專屬。
• 相容性分析： 確認不同相依性的授權在組合時是否相容。
• 義務追蹤： 記錄歸屬、原始程式碼揭露或衍生作品授權等要求。

常見的合規問題：

• Copyleft 污染：專屬軟體中的 GPL 授權相依性可能需要將整個應用程式的程式碼開放。
• 歸因失敗： 分散式軟體中缺少所需的版權聲明和授權文字。
• 不相容的組合：使用具有衝突授權，無法合法合併的相依性。
• 授權變更： 專案有時會在版本之間變更授權，需要重新評估。

授權風險評估：

• 高風險： 在專有軟體分發中使用強制性版權許可證（如GPL、AGPL）。
• 中等風險：弱式 Copyleft 授權 (LGPL、MPL) 需要謹慎的整合做法。
• 低風險： 具有最小限制的寬鬆許可證（MIT、Apache 2.0、BSD）。
• 未知風險： 自訂授權、授權不清楚或缺少授權資訊。

依賴性品質評估

評估依賴可維護性：

• 維護狀態： 判斷相依性是主動維護還是放棄。
• 更新頻率： 評估相依性接收更新和錯誤修正的頻率。
• 社區健康： 評估貢獻者活動、問題回應時間和社群參與。
• 文件品質： 檢閱依賴項是否有足夠的文件以正確的方式使用。
• 安全實踐： 驗證專案是否有負責任的揭露流程和安全建議。

質量指標：

• 主動維護： 定期提交、最新版本、響應式維護者。
• 大型社區： 許多貢獻者、星標、分支和用戶確保可持續性。
• 清晰的溝通： 活躍的問題追蹤器、響應式討論、清晰的發行說明。
• 安全意識： 發布的安全政策、提示漏洞修補、安全建議。

危險信號：

• 廢棄項目：多年沒有更新，維護人員反應遲鈍，累積了未解決的問題。
• 單一維護者風險： 由一人維護的關鍵依賴，且該維護者可能會無法協助。
• 品質不佳：測試不足，錯誤頻繁，次要版本的重大變更。
• 缺乏安全性： 沒有安全策略，漏洞響應緩慢，未公開的安全問題。

手動檢測挑戰

為什麼手動檢查難以擴充：

音量壓倒性

• 數百個依賴項： 即使是小型應用程式也會仰賴數百個套件。
• 多種應用： 組織維護數十或數百個應用程式，使相依性計數成倍增加。
• 不斷變化： 每天發布的新版本會使任何手動庫存立即過時。
• 人為錯誤： 手動追蹤不可避免地會遺漏依賴關係，尤其是傳遞依賴關係。

資訊分散

• 多個來源： 漏洞資訊來自 CVE 資料庫、安全郵件清單、GitHub 諮詢、供應商通知和安全研究人員揭露。
• 許可證研究： 判斷確切的授權需要檢查每個套件中的原始程式碼檔案、自述文件和授權檔案。
• 特定版本的詳細信息： 漏洞和許可證可能會在版本之間發生變化，需要針對特定版本進行研究。
• 相互矛盾的資訊： 不同的來源有時會提供相互矛盾的漏洞或授權資訊。

耗時的分析

• 漏洞評估： 研究每個漏洞的嚴重性、可利用性和修補程式狀態需要大量時間。
• 許可證分析： 了解授權條款、相容性和義務需要法律專業知識。
• 更新規劃： 考慮重大變更和相依性衝突來判斷安全的更新路徑很複雜。
• 持續監控： 持續監控新漏洞和更新需要專用資源。

延遲偵測

• 發現延遲： 手動流程會在揭露後數週或數月偵測漏洞。
• 反應： 組織從安全事件中了解漏洞，而不是主動掃描。
• 審核週期： 定期稽核會讓應用程式在稽核之間容易受到攻擊。
• 緊急補丁： 如果沒有持續監控，關鍵漏洞就需要破壞性的緊急修補。

自動化解決方案

軟體成分分析工具解決了手動檢查挑戰：

自動探索

• 依賴解析： SCA 工具會自動剖化套件資訊清單檔，以識別相依關係。
• 傳遞解析： 工具會遵循依賴鏈條來生成完整的材料清單。
• 鎖定檔案分析： 分析鎖定檔案（package-lock.json、Pipfile.lock），準確顯示安裝的版本。
• 二進位掃描： 某些工具會掃描已編譯的二進位檔和容器，以發現內嵌的相依性。

持續監控

• 即時漏洞警報： 當新漏洞影響您的依賴項時立即收到通知。
• 自動更新： GitHub Dependabot 等工具會在安全性更新可用時自動建立提取要求。
• 儀表板可見性： 集中式儀表板顯示所有應用程式的漏洞狀態。
• 排程掃描： 定期自動掃描可確保依賴性資料保持最新狀態。

綜合資料庫

• 彙總的弱點資料： SCA 工具彙總來自 NVD、GitHub 諮詢資料庫、安全性郵件清單和供應商資料庫的資訊。
• 授權資料庫： 維護全面的許可證信息，包括完整的許可證文本和義務摘要。
• 策劃與驗證： 供應商驗證和策劃漏洞資料以減少誤報。
• 專有情報： 商業工具提供公共資料庫之外的額外研究和分析。

智慧分析

• 嚴重性評分： 自動計算 CVSS 分數並按風險確定漏洞的優先順序。
• 可達性分析： 判斷應用程式中是否實際使用易受攻擊的程式碼路徑。
• 補救指引： 提供特定的版本建議，以修復漏洞，同時保持相容性。
• 政策執行： 偵測到原則違規時，自動失敗建置或封鎖部署。

建立驗證基準線

在實施自動掃描之前，請建立驗證標準：

安全性原則

• 漏洞容忍度： 定義可接受的漏洞嚴重性（例如，不包括關鍵或高風險，有限的中等風險）。
• 補丁時間範圍： 確定必須以多快的速度修復不同嚴重性漏洞。
• 例外處理程序： 建立程序，以便在無法立即修補時接受風險。
• 報告要求： 定義誰需要漏洞通知以及需要多快。

合規性原則

• 核准的授權： 列出始終可接受的許可證（例如，MIT、Apache 2.0）。
• 受限授權：確定需要特殊批准（例如 LGPL）或禁止（例如專有軟體的 GPL）的許可證。
• 歸屬要求： 定義如何在分散式軟體中提供歸因。
• 審計跟踪： 指定合規性證據的文件要求。

質量標準

• 維護要求： 定義最低維護期望（例如，去年內的更新）。
• 社區規模： 為可接受的社區健康指標建立閾值。
• 文件標準： 指定相依性的最低文件需求。
• 安全實踐： 要求相依性具有已發佈的安全原則和回應式弱點處理。

了解要檢查和驗證的內容為實施自動化軟體組合分析工具奠定了基礎。 下一個單元將探討 SCA 基礎知識，以及自動化工具如何解決手動相依性管理的挑戰。