汽車軟體 SBOM 是什麼？UN R155 與 CRA 下的軟體供應鏈管理

資安事件發生時，第一個問題永遠是：「我們的產品有沒有用到那個元件？」——某個開源函式庫爆出重大弱點，全世界的資安團隊連夜清查。有 SBOM 的團隊查一份清單，十分鐘有答案；沒有的團隊翻原始碼、問供應商，兩週後還在等回覆。這就是 SBOM 存在的理由：弱點是常態，清單決定反應速度。

SBOM 是什麼：軟體的成分標示

SBOM（Software Bill of Materials，軟體物料清單）就是軟體的「成分表」：這個軟體由哪些元件組成、每個元件的名稱、版本、來源與授權，以及元件之間的相依關係。業界有兩種主流交換格式——SPDX 與 CycloneDX——都是機器可讀的結構化格式，讓清單能在供應鏈之間傳遞、能自動與弱點資料庫比對。

車用軟體的 SBOM 特別複雜，因為一顆 ECU 的軟體堆疊往往橫跨多方：晶片商的驅動、AUTOSAR 基礎軟體、第三方協定棧、開源元件、自家應用層——每一層都可能帶進弱點，而多數團隊只看得到自己寫的那一層。

為什麼法規都指向 SBOM

• UN R155／ISO/SAE 21434：CSMS 要求對整個供應鏈的資安風險負責，並持續監控新弱點。做過 TARA 的團隊都知道，「資產識別」的前提是知道自己有什麼——沒有 SBOM 的弱點監控是在盲掃。
• 歐盟 CRA（網路韌性法）：要求製造商建立弱點處理程序、對已知可利用弱點通報，這些義務的技術基礎都是一份即時的元件清單。通報義務自 2026 年 9 月起適用，主要義務 2027 年 12 月全面上路——CRA 對車用供應鏈的影響有專文解析。
• OEM 的採購要求：車廠正把資安要求往 Tier 2 供應商與軟體商延伸，「交付軟體附 SBOM」開始出現在合約條款裡——這對台灣供應鏈是最直接的推力。

SBOM 的管理循環：清單只是起點

一份放著不動的 SBOM 沒有價值。完整的循環是：

1. 產出：在建置流程中自動生成（人工維護的清單三個月就過時）。
2. 比對：定期把 SBOM 對照公開弱點資料庫（CVE），找出受影響元件。
3. 評估：不是每個 CVE 都要修——用 TARA 的邏輯評估攻擊可行性與影響，決定處置。
4. 修補與再驗證：更新元件後跑迴歸測試，並更新 SBOM——清單要跟著軟體版本走。

工具面，Vector 的 COMPASS 支援 TARA 與弱點管理的規劃、執行與評估，把「發現弱點之後」的評估流程工具化；Vector 自身也設有 PSIRT（產品資安事件應變）與公開的安全公告，這是供應商資安成熟度的實例——你的客戶未來也會用同樣的標準看你。

台灣供應鏈該從哪開始

先回答三個問題：交付的軟體能不能自動產出 SBOM？收到供應商的 SBOM 有沒有地方放、有沒有流程比對弱點？合約裡的資安條款要求什麼格式？——第一步不是買工具，是把建置流程改成能自動產清單，格式選 SPDX 或 CycloneDX 其中一種並堅持下去。

常見問題釐清

SBOM 是什麼？

SBOM（Software Bill of Materials，軟體物料清單）是軟體的成分表：列出組成軟體的所有元件、版本、來源、授權與相依關係，以 SPDX 或 CycloneDX 等機器可讀格式交換。它是弱點管理的基礎——新弱點揭露時，有 SBOM 才能立即知道哪些產品受影響。

UN R155 有強制要求 SBOM 嗎？

R155 沒有點名「SBOM」這個詞，但它要求 CSMS 對供應鏈風險負責並持續監控弱點——實務上沒有元件清單就做不到。歐盟 CRA 則更直接地要求弱點處理與通報能力。兩者殊途同歸：SBOM 是滿足這些義務的事實標準做法。

SPDX 和 CycloneDX 該選哪個？

兩者都是被廣泛支援的開放格式：SPDX 源自 Linux 基金會、在授權合規領域歷史較久；CycloneDX 由 OWASP 推動、在資安使用情境的生態成長快。實務上先看你的客戶合約與工具鏈支援哪一種——多數現代工具兩種都能產出，重點是選定一種並在流程中自動化。