汽車行業開源合規：當一億行代碼開上路

一輛智能汽車的代碼量已經超過一億行，遠超一架現代客機——而其中大部分不是主機廠寫的，是開源社區和供應鏈寫的。車載操作系統、自動駕駛棧、座艙應用、OTA 框架，層層疊疊的開源組件跟着整車跑在路上，一跑就是十五年。汽車因此成為開源治理要求最嚴苛的行業之一：問題不在"用不用開源"，而在"誰為這一億行代碼的十五年負責"。

監管把軟件供應鏈寫進了准入條件

三份文件構成了全球汽車軟件安全的監管底座。UN R155 要求整車廠建立覆蓋全生命週期的網絡安全管理體系（CSMS），歐盟已對所有新車強制適用——沒有 CSMS 認證，車賣不進歐洲。ISO/SAE 21434 是與之配套的工程標準，明確要求對供應鏈上的軟件組件進行風險管理。國內，強制性國家標準 GB 44495《汽車整車信息安全技術要求》已經發布並進入實施階段——注意"強制"兩個字，這不是推薦性標準，而是准入門檻。三者共同指向一件事：整車廠必須證明自己知道車上跑着什麼軟件、有什麼風險、怎麼持續管理。

汽車行業的四個特殊性

壓力逐級傳導。監管落在主機廠，主機廠用採購合同把要求壓給 Tier 1，Tier 1 再壓給 Tier 2——SBOM 交付、漏洞響應時限、許可證擔保正在成為汽車供應鏈合同的標準條款。對零部件和軟件供應商來説，開源治理能力正在從加分項變成投標資格。

嵌入式形態放大盲區。車載軟件以 C/C++ 為主，靜態鏈接是常態，大量交付物是二進制固件——恰好全部踩在清單級檢測的盲區上。汽車行業的成分透明必須靠片段級檢測加二進制成分分析的組合拳，只讀依賴聲明的 SBOM 在主機廠驗收時過不了關。

十五年生命週期對撞組件 EOL。車規軟件的支持週期以十年計，而開源組件的活躍週期往往只有幾年——今天引入的組件，大概率在整車生命週期內停止維護。停更組件治理在汽車行業不是可選項，准入時評估社區可持續性、量產後持續監測 EOL 狀態，必須制度化。

OTA 改變了合規的時間形態。傳統汽車的軟件合規是"出廠一次性"，OTA 讓它變成"每次推送都要重新成立"：每個 OTA 版本都應有對應的 SBOM 快照與許可證合規確認，否則一次推送就可能把新的 GPL 衝突刷進十萬輛車。

落地要點

給供應商的三條：把 SBOM 生成嵌進構建流水線，每個交付版本自動出快照；許可證策略按"隨整車分發"的最嚴口徑配置——車載軟件幾乎全部構成分發，許可證衝突沒有"內部使用"的豁免空間；對外採的二進制組件用工具核驗後再簽收，供應商的合規聲明需要證據支撐。

給主機廠的兩條：把驗收從"要 SBOM 文檔"升級為"用工具核驗交付物與 SBOM 的一致性"——我們在車載項目審計中見過太多與實際成分對不上的精美清單；建立全車型的組件台賬,新漏洞情報到達時分鐘級定位受影響車型與版本，這是 R155"持續監測"要求的工程本體。

汽車行業用二十年建立了功能安全（ISO 26262）的完整體系,現在輪到網絡安全和供應鏈安全走同樣的路——區別是這次沒有二十年，監管已經把表定好了。