AUTOMOTIVE CYBERSECURITY
汽車 SBOM 是什麼？從 UN R155、ISO 21434 到供應鏈安全完整解析
隨著汽車朝向智慧化、聯網化與軟體定義汽車發展，SBOM逐漸成為汽車供應鏈安全、漏洞管理與產品生命周期維護的重要基礎。
一、什麼是汽車 SBOM？為什麼供應鏈需要它？
SBOM 是 Software Bill of Materials 的縮寫，中文通常稱為軟體物料清單或軟體組成清單。它用來記錄產品中使用了哪些軟體元件，以及這些元件之間的依賴關係。
汽車產品可能包含開源軟體、第三方函式庫、作業系統元件、容器映像、韌體模組及其他外部軟體。當其中某個元件出現漏洞時，企業需要快速確認哪些產品或版本受到影響。
- 開源軟體元件
- 第三方函式庫
- 直接依賴與傳遞依賴
- 作業系統元件
- 容器映像
- 軟體版本與供應商資訊
- 元件唯一識別資訊
- 授權與依賴關係
SBOM的價值不只是列出軟體清單，更重要的是建立可追蹤、可分析及可維護的軟體組成視圖。
二、UN R155 與 ISO 21434 為何重視 SBOM？
1. UN R155：關注車輛網路安全管理
UN R155是車輛網路安全相關法規，要求適用的汽車製造商建立並維持網路安全管理系統。供應商需要協助整車廠了解產品與軟體可能帶來的網路安全風險。
SBOM可以協助企業說明產品使用了哪些軟體元件，並在漏洞事件中進行影響分析。但SBOM本身並不等於UN R155合規，也不能取代其他必要的安全管理活動。
2. ISO/SAE 21434：將網路安全融入產品生命周期
ISO/SAE 21434是汽車網路安全工程標準，涵蓋治理、風險管理、產品開發、持續活動及供應商協作等主題。
SBOM可以為軟體組成管理、漏洞追蹤與供應鏈風險分析提供資料基礎。
- 網路安全風險評估
- 威脅分析與風險評估
- 安全需求管理
- 安全設計與驗證
- 元件與供應鏈風險管理
- 漏洞監控與安全更新
三、汽車供應鏈為何不能只管理源碼 SBOM？
汽車軟體產品通常由多個層次組成，包括應用程式、第三方函式庫、作業系統、容器映像、ECU韌體、驅動程式及預先編譯的二進位檔案。
源碼層的SCA工具可以分析套件依賴；而對於已編譯的韌體或二進位映像，企業可能還需要專門的韌體分析工具。
從源碼 SBOM 到產品級 SBOM
應用層
分析源碼、開源套件與容器映像，建立應用軟體SBOM。
韌體層
識別二進位元件、作業系統、驅動程式及嵌入式軟體。
產品層
整合不同來源的SBOM，建立產品與版本的完整軟體組成視圖。
四、汽車 SBOM 應該包含哪些重要資訊？
SBOM的欄位會依照企業流程、客戶要求及採用的格式而有所不同，但供應鏈管理通常需要足夠的識別與追溯資訊。
1. 元件識別資訊
記錄元件名稱、版本、供應商及可識別元件身分的資訊。
2. 依賴關係
除了直接依賴，也應掌握傳遞依賴，避免遺漏間接引入的軟體元件。
3. 版本與產品關聯
將SBOM與產品版本、ECU型號、韌體版本、建置編號及OTA更新建立關聯。
4. 格式與交換能力
常見的SBOM格式包括CycloneDX與SPDX。企業應與供應鏈夥伴確認格式、欄位、交付頻率與資料範圍。
五、汽車 SBOM 如何協助漏洞管理與 OTA 安全更新？
1. 新漏洞出現時快速進行影響分析
當某個開源元件出現新的CVE時，企業可以利用版本化SBOM確認產品是否使用受影響的元件，並建立初步的影響範圍清單。
企業仍需要結合受影響版本、實際部署方式、漏洞觸發條件及緩解措施，判斷實際風險。
2. 支援長生命周期產品維護
汽車產品可能需要維護多年，因此企業需要保存歷史版本資訊，並追蹤OTA更新前後的軟體組成變化。
- 版本回溯
- 軟體變更分析
- 漏洞影響追蹤
- OTA更新管理
- 安全維護紀錄
- 供應鏈安全資訊交換
六、Mend.io 如何協助汽車供應商建立 SBOM 能力？
Mend.io提供軟體組成分析（SCA）等能力，可協助企業識別開源元件、分析依賴關係、追蹤漏洞及管理軟體供應鏈風險。
1. 自動化分析軟體依賴
在應用程式與源碼層面，SCA可以協助識別直接依賴與傳遞依賴，整理軟體組成資訊。
2. 整合開發與持續整合流程
企業可以將軟體組成分析整合至CI/CD流程，在建置、測試或發布階段進行安全檢查。
3. 結合漏洞風險分析
SBOM是元件資訊的基礎。企業還需要分析漏洞嚴重性、實際可利用性及產品環境，制定適合的處理方案。
4. 與其他來源的 SBOM 協作
對於同時涉及源碼與韌體的汽車零部件供應商，可以評估將源碼層、容器層及韌體層SBOM整合，建立更完整的產品級軟體組成視圖。
七、汽車零部件企業如何落地 SBOM 管理？
- 盤點產品軟體組成： 確認源碼、函式庫、作業系統、韌體、容器映像與二進位檔案。
- 建立分層分析策略： 根據不同軟體層次選擇適合的分析工具。
- 將SBOM與產品版本綁定： 保存每次建置與發布對應的SBOM。
- 整合漏洞監控流程： 依照漏洞風險與產品情境進行影響分析。
- 建立供應鏈交付機制： 確認SBOM格式、更新頻率、必要欄位與漏洞通報流程。
- 持續維護與改善： 隨著軟體更新與新漏洞披露，持續更新軟體組成資訊。
八、汽車 SBOM 的未來：從軟體清單走向供應鏈信任
隨著汽車軟體數量增加，SBOM不再只是產品交付時的一份附件，而可以成為連接軟體透明度、元件識別、漏洞管理、風險評估、安全更新與供應鏈信任的重要資料基礎。
對希望進入全球汽車供應鏈的零部件企業而言，提早建立SBOM生成、版本管理、漏洞監控與持續維護能力，有助於提升產品安全管理效率。
但SBOM不是單獨的合規證明。成熟的汽車網路安全能力仍需要結合治理、風險管理、安全工程、漏洞處理、供應商協作與生命周期維護。
FAQ
Q1：什麼是汽車 SBOM？
汽車SBOM是用來記錄汽車軟體產品中所使用的軟體元件、版本、供應商及依賴關係的清單，可協助企業進行軟體透明度管理、漏洞追蹤與供應鏈風險分析。
Q2：UN R155 是否要求企業單獨提交 SBOM？
SBOM不能直接等同於UN R155的單一強制交付項目。企業應根據適用法規、整車廠要求、供應鏈協議及自身網路安全管理流程確認必要的資訊與證據。
Q3：ISO 21434 與 SBOM 有什麼關係？
ISO/SAE 21434關注汽車網路安全工程與生命周期管理。SBOM可作為軟體組成管理、供應鏈協作及漏洞影響分析的資料基礎，但不能取代完整的網路安全工程流程。
Q4：汽車供應商為什麼需要分析韌體 SBOM？
汽車產品可能包含已編譯的韌體、作業系統元件、驅動程式及二進位軟體。只分析源碼未必能掌握完整產品組成，因此企業可能需要搭配專用韌體分析工具。
Q5：Mend.io 可以取代所有韌體安全分析工具嗎？
不宜直接這樣理解。Mend.io可協助源碼、開源依賴及軟體供應鏈安全管理；若產品包含複雜的二進位韌體，企業仍應依照產品架構與分析需求評估其他專用工具。
Q6：SBOM 是否等於汽車網路安全合規證明？
不是。SBOM是產品軟體組成與追溯能力的重要資料基礎，但完整的汽車網路安全合規與工程管理，還需要結合風險評估、設計、測試、漏洞處理、更新及相關證據。
