聯系電話:
+886 2 77182788
-
創提部落格
希望我們能與您分享和探討成長中的點點滴滴
為何應立即實施 SBOM，以滿足《網路韌性法案》（CRA）的合規要求
創提科技
2026/07/16
分享到
CRA重要截止日期：
2026年9月11日，必須報告正在被利用的漏洞和嚴重安全事件。
2027年12月11日，全面落實關鍵網路安全要求，包括應要求提供軟體物料清單（SBOM）。
乍一看，許多組織將2027年視為SBOM的真正截止日期，但這種理解存在風險。
實際上，如果沒有完整、可靠且可按需獲取的軟體物料清單（SBOM），在操作層面根本無法履行2026年的報告義務。儘管該法規可能會分階段實施，但必須立即建立相關能力基礎。
沒有資產清單，漏洞管理便無從談起
漏洞管理的先決條件是可見性。看不見的漏洞，便無法管理。現代軟體產品通常包含：
現代軟體通常包含以下組成部分
● 開源庫
● 傳遞性依賴項
● 商業 SDK
● 容器鏡像
● 嵌入式組件
如果沒有軟體物料清單（SBOM），您將無法
● 識別新出現的通用漏洞披露與編號（CVE）
● 評估漏洞的可利用性
● 確定受影響的版本
● 在24小時內通知監管機構
在監管時間壓力下手動重建相依樹狀結構是不切實際的，而且在法律上也存在風險。當一個正在被積極利用的漏洞被公開披露時，監管機構不會接受“不確定”作為答覆。此外，僅依賴應用程式的包清單檔，無法看清未受管理的代碼、複製粘貼的代碼片段，以及可能複製協力廠商和開源元件的AI生成的代碼片段的來源。
唯一可靠的做法，就是對產品內部情況有可追溯的瞭解。
24小時報告義務改變了風險模型
從歷史上看，組織通常先進行調查，再進行報告。CRA 顛覆了這種慣例。一旦發現存在被積極利用的漏洞，製造商必須立即報告。這要求：
● 即時組件查詢
● 跨版本的版本追溯
● 歷史構建產物的保留
● SBOM 資料與漏洞情報源之間的自動關聯
這些能力並非一蹴而就。那些等到2027年才開始“啟用SBOM”的企業會發現，漏洞報告流程需要數月的運營磨合期才能穩定運行。
2026年的義務不僅僅是一個法律里程碑。它更是一個系統工程里程碑——即建立起自動化生成和管理軟體物料清單（SBOM）的能力。
符合性評估需要證據，而非敘述
到2027年12月，帶有數位元素的產品（PDEs）必須證明符合CRA的基本網路安全要求。
符合性評估將要求提供以下方面的客觀證據：
● 生命週期漏洞管理
● 安全設計開發流程
● 持續依賴項監控
● 發佈時不存在已知的可利用漏洞
SBOM 系統能夠提供結構化且符合監管要求的證據。如果沒有這一基礎，組織就可能面臨僅能提供政策聲明而非實際證據的風險。這兩者之間有著天壤之別。
延遲採用造成運營衝擊
SBOM 的實施不僅僅是一個工具選擇問題。它需要：
● 流程優化與重構
● 與開發人員工作流及 CI/CD 管道的集成
● 構建產物和發佈管理的更新
● 工程、安全和法務團隊之間的協作
推遲這項工作將增加以下風險：
● 2026年需進行緊急改造
● 2027年審計未通過
● 歐盟市場准入受阻
運營衝擊是可以避免的。但前提是企業必須將軟體物料清單（SBOM）視為基礎設施，而非單純的文書工作。
戰略優勢，而非合規負擔
儘早採用 SBOM 可帶來可量化的運營價值：
● 縮短漏洞影響評估的平均時間
● 提高軟體供應鏈透明度
● 更好地為美國、英國、亞洲及其他地區的平行市場做好準備
最有韌性的製造商不會把 SBOM 當作監管負擔，他們會把它當作產品基礎資訊（資產）。
需要明確的是
雖然《網路韌性法案》（CRA）並未規定必須在2026年9月11日前建立軟體物料清單（SBOM），但鑒於該法案對漏洞管理、報告和合規性的要求，若無SBOM，合規將難以實現。
2026年的報告要求取決於SBOM的成熟度。
2027年的文檔要求則將其正式化。
現在就開始實施的機構，將能夠從容應對CRA的要求。
將 SBOM 戰略付諸行動
如果CRA的時間表已經明確，那麼接下來的問題就是如何著手：我們該從哪裡開始？
1、注重準確性和完整性
構建 SBOM 終究是監管機構所期待的，它是特定版本中所有已編譯並發佈的元件清單。然而，如果輔以原始程式碼 SBOM（即開發過程中代碼庫中現有內容的清晰視圖），則能夠更輕鬆地持續生成可靠的構建 SBOM。原始程式碼 SBOM 有助於團隊在發佈前檢測未申報的元件、經過修改的開源組件以及 AI 生成的代碼片段。它並非取代最終的構建 SBOM，而是增強了其完整性。
2、在 CI/CD 生命週期內實現 SBOM 生成的自動化
構建 SBOM 應在構建時生成，與發佈工件一同進行版本管理，長期保存，並持續與漏洞情報源進行關聯。在 24 小時內必須提交報告的要求下，手動重建既無法實現規模化，也難以站得住腳。
將協力廠商 SBOM 視為輸入資料，而非保證依據，您仍需對投放歐盟市場的產品承擔責任。應驗證、規範化並整合供應商提供的 SBOM，將其整合為統一的產品級視圖，以便您在收到請求時能夠按需提供。
3、明確考慮 AI 輔助開發
生成的代碼可能會引入繞過傳統聲明的受許可代碼片段或依賴項。您的掃描和治理流程必須擴展至 AI 生成的輸出，以確保原始程式碼 SBOM 和構建 SBOM 均能真實反映實際情況。
CRA 準備工作旨在立即構建可操作的 SBOM 情報，從而確保 2026 年的漏洞報告和 2027 年的合規性驗證具有可預測性、可重複性和可審計、可證明。
作者簡介
Aaron Branson
首席行銷官（Chief Marketing Officer）
作為 FossID 首席行銷官，Aaron Branson 負責公司技術產品和專業服務價值的市場傳播，同時持續關注軟體供應鏈安全領域的發展趨勢以及客戶面臨的實際挑戰，並通過分享行業洞察和實踐經驗，説明企業更好地應對產品安全與開源軟體合規方面的挑戰。
Aaron 在軟體設計、軟體發展和專案管理領域擁有超過 25 年的豐富經驗。