開發人員經常使用第三方代碼來構建他們的應用程式，以提高效率和節省時間。然而，這種對外部元件的依賴，尤其是對開源軟體（OSS）的依賴，會帶來重大風險，包括漏洞和許可問題。根據 2023 年 GitHub 的一項調查，31% 的開發人員認為查找和修復安全漏洞是僅次於編寫代碼 （32%） 的第二重要任務。
因此，許多組織擔心他們對開放源碼軟體的依賴，因為它經常成為駭客的目標。組織面臨的挑戰是整個軟體供應鏈的脆弱性增加，以及瞭解如何在最近備受矚目的攻擊后有效降低風險。
ESG 的一份研究報告顯示，91% 的組織在過去 12 個月內經歷過軟體供應鏈事件。最常見的事件包括：
Log4J、Curl、Apache Struts 和 OpenSSL 等著名漏洞都曾導致許多運作損害。這些事件突顯了當軟體供應鏈中的單一弱點被利用時，對組織所造成的嚴重影響。為了因應這些日益增加的風險，世界各地的監管機構都在強調軟體的透明度與安全性。採用 Software Bill of Materials (SBOM)正成為管理軟體供應鏈風險的重要策略。
SBOM法規蓄勢待發
SBOM法規越來越普遍。許多政府已經發佈了有關 SBOM 實施的建議。在美國，SBOM 建議包含在幾項政府指南中，包括：
在歐洲，歐盟網路安全局 (EU Agency for Cybersecurity, ENISA) 發表了「物聯網供應鏈安全指南」，提供組織改善網路安全及管理軟體相關供應鏈風險的寶貴建議。
其他國家/地區也發佈了類似的指南，包括：
PCI DSS 如何需要生成 SBOM
支付卡產業資料安全標準 (PCI DSS) 已經意識到支付卡資料的風險不斷升級，並成為 SBOM 採用的推動力。最新版本 PCI DSS 4.0 強制要求使用 SBOM，強調 SBOM 在保護敏感資訊方面的重要作用。透過提供軟體元件的詳細清單，SBOM 可讓組織主動找出並處理漏洞，降低資料外洩和財務損失的風險。
PCI DSS 成立於 2004 年，是一項全面的安全標準，旨在保護信用卡資訊。它概述了對處理信用卡交易的企業的一系列嚴格要求，這些要求是根據每年處理的交易量客製的。2022 年發佈的 PCI DSS v4.0 引入了重大更改，包括 SBOM 授權，以應對不斷變化的威脅。在 2024 年 4 月之前必須遵守 PCI DSS v4.0，具體要求在 2025 年 3 月 31 日之前逐步實施。
來源： PCI DSS V4.0 概覽
透過強制執行 SBOM，PCI DSS 使組織能夠全面瞭解其軟體生態系統，使他們能夠主動識別和解決漏洞。這種方法大大降低了代價高昂的數據洩露和財務損失的風險。
PCI DSS 的較新版本（ 版本 4.0.1）已於 2024 年年中發佈。這意味著之前的版本 4.0 將在 2024 年 12 月 31 日之後不再有效。但是，新版本不會添加或刪除任何規則，也不會更改截止日期。因此，本文章中有關 SBOM 要求的資訊適用於版本 4.0 和 4.0.1。
符合PCI DSS要求6.3.2
PCI DSS v4.0 中的 SBOM 要求是 PCI DSS 在其最新版本中所做的更廣泛增強的一部分。作為 4.0 版中添加的 64 項新要求的一部分引入的 SBOM 要求專門解決了組織維護軟體元件庫存的需求，特別關注客製和客製軟體。
此要求歸類在PCI DSS要求6下，該要求要求透過實施強大的安全措施以及定期執行漏洞評估和更新來創建和維護安全系統和應用程式。此要求對於降低軟體漏洞帶來的風險和保護持卡人數據至關重要。第 6 部分涵蓋五個主要領域：
- 6.1 定義並理解開發和維護安全系統和軟體的流程和機制。
- 6.2 客製和客製軟體是安全開發的。
- 6.3 識別並解決安全漏洞。
- 6.4 面向公眾的 網路應用程式受到保護，免受攻擊。
- 6.5 對所有系統元件的更改都得到安全管理。
更具體地說，要求 6.3.2 是一項重要的更新，它是由幾起違規行為引起的，其中第三方元件中的漏洞或第三方元件供應商的違規行為導致持卡人數據洩露。該要求如下：
6.3.2.b檢查軟體文檔，包括整合了第三方軟體元件的客製和客製軟體，並將其與庫存進行比較，以驗證庫存是否包括客製和客製軟體以及第三方軟體元件。
組織必須徹底記錄和管理其應用程式中使用的特定元件和服務。雖然其中一些資訊可能已經包含在數據流圖中，但新的要求需要更詳細的文檔。隨著元件的更新和更改，跟蹤這些詳細資訊可能具有挑戰性。建議使用標準範本來捕獲此資訊。此外，一些原始程式碼倉庫（如 GIT）可能會提供用於匯出正在使用的元件清單的工具。您的庫存至少應包括：
- 應用程式元件（通常是儲存庫專案）
- 第三方元件清單
- 應用程式依賴項清單（即 Tomcat、Jboss、.NET、中間件）
- 授權付款頁面腳本清單
如何 OPSWAT SBOM 可以幫助滿足PCI DSS要求
法規越來越多地要求 SBOM 確保軟體供應鏈安全。然而，組織正在努力建立其軟體代碼組成的準確清單。
資料來源： EGS Report 2024
然而，創建準確和全面的SBOM對組織來說是一個巨大的挑戰。這些檔案要求對軟體元件進行細緻的清點，因此需要有關其來源、版本和相互依賴性的詳細資訊。如果沒有精確的 SBOM，組織就難以有效地識別、評估和減輕其軟體供應鏈中固有的風險。
生成 SBOM 的準則
OPSWAT SBOM 可自動生成代碼和容器的 SBOM，從而增強安全性並幫助實現軟體供應鏈中的合規性。
- 識別所有元件和依賴項
準確識別所有軟體元件，包括開源庫和第三方庫，以及它們的版本和依賴關係。這為強大的SBOM奠定了基礎。 - 評估 OSS 風險
評估與 OSS 元件相關的潛在風險。考慮許可證合規性、安全漏洞和維護狀態等因素。根據元件對軟體的重要性確定元件的優先順序。 - 掃描OSS漏洞
利用漏洞掃描和 SBOM 生成工具來識別 OSS 元件中的已知漏洞。根據漏洞的嚴重性和對軟體的潛在影響確定漏洞的優先順序。
用 OPSWAT SBOM公司
OPSWAT SBOM 可自動生成代碼和容器的 SBOM，從而增強安全性並幫助實現軟體供應鏈中的合規性。
以下是您可以利用的方法 OPSWAT 用於有效生成 SBOM 的 SBOM：
OPSWAT SBOM 支援 10 多種程式設計語言，包括 Java、JavaScript、Go、PHP 和 Python。這種廣泛的支持確保了全面的 vulnerability detection 跨越各種軟體開發生態系統。
對違規行為的處罰
不遵守PCI DSS標準（包括SBOM要求）的組織可能會受到每月5,000至100,000美元不等的經濟處罰。如果合規問題仍未得到解決，這些罰款可能會隨著時間的推移而增加。
除了經濟處罰外，不遵守PCI DSS還可能導致重大的法律和營運挑戰。法律後果可能包括訴訟、辯護費用和巨額和解。此外，不遵守規定可能會觸發聯邦貿易委員會 （FTC） 等機構的聯邦審計，從而導致額外的處罰。
PCI DSS 4.0 合規性的後續步驟
將 SBOM 整合到 PCI DSS 4.0 框架中，標誌著向更安全的軟體供應鏈的關鍵轉變。透過利用高級工具，例如 OPSWAT SBOM，組織可以有效地管理開源風險，提高合規性，並防止代價高昂的數據洩露。
使用 SBOM 不再是一種選擇，而是一種必需品。透過採取積極主動的措施來瞭解和解決軟體依賴性問題，組織可以構建一個強大的安全基礎，以保護他們的營運並建立客戶信任。
