自動車業界のオープンソースコンプライアンス：1 億行のコードが公道を走るとき

現代のスマートカーは 1 億行を超えるコードを搭載する——旅客機をはるかに上回る量だ。しかもその大半は OEM が書いたものではなく、オープンソースコミュニティとサプライチェーンが書いたものである。車載 OS、自動運転スタック、コックピットアプリ、OTA フレームワーク——幾重にも重なるオープンソースコンポーネントが車と一緒に公道を走り、それが 15 年続く。ゆえに自動車はオープンソースガバナンス要求が最も厳しい業界の一つとなった。問いは「オープンソースを使うか」ではなく「この 1 億行の 15 年間に誰が責任を持つか」である。

規制はソフトウェアサプライチェーンを市場参入条件に書き込んだ

3 つの文書が世界の自動車ソフトウェアセキュリティ規制の土台を成す。UN R155 は OEM に車両ライフサイクル全体を覆うサイバーセキュリティ管理システム（CSMS）の構築を要求し、EU では全新車に強制適用されている——CSMS 認証なしに車は欧州に入れない。ISO/SAE 21434 はその対となるエンジニアリング標準で、サプライチェーン上のソフトウェアコンポーネントのリスク管理を明示的に求める。中国では強制性国家標準 GB 44495（自動車整車情報セキュリティ技術要求）が公布され実施段階に入った——「強制」の二文字に注意。推奨標準ではなく参入の閾値だ。三者が指す方向は同じである。OEM は車に何のソフトウェアが載り、どんなリスクがあり、どう継続管理しているかを証明しなければならない。

自動車業界の 4 つの特殊性

圧力はティアを伝って波及する。規制は OEM に落ち、OEM は調達契約で Tier 1 に要求を課し、Tier 1 は Tier 2 へ課す。SBOM 納品、脆弱性対応 SLA、ライセンス保証は自動車サプライチェーン契約の標準条項になりつつある。部品・ソフトウェアサプライヤーにとって、オープンソースガバナンス能力は加点項目から入札資格へ変わりつつある。

組込み形態が盲点を増幅する。車載ソフトウェアは C/C++ 中心で静的リンクが常態、納品物の多くはバイナリファームウェアだ——マニフェストレベル検出の盲点のすべてを踏み抜く形態である。自動車の成分透明性はスニペットレベル検出とバイナリ成分分析の組み合わせでしか成立せず、依存宣言だけから作った SBOM は OEM の検収を通らない。

15 年のライフサイクルとコンポーネント EOL の衝突。車載ソフトウェアのサポート期間は 10 年単位、オープンソースコンポーネントの活動期間はしばしば数年——今日導入したコンポーネントは、高い確率で車両のライフサイクル内に保守を終える。EOL ガバナンスは自動車業界では選択肢ではない。導入時のコミュニティ持続可能性評価と量産後の EOL 継続監視を制度化する必要がある。

OTA はコンプライアンスの時間形態を変えた。従来の車載ソフトウェアコンプライアンスは「出荷時の一回きり」だったが、OTA はそれを「プッシュのたびに成立し直すべきもの」に変えた。OTA の各リリースには対応する SBOM スナップショットとライセンスコンプライアンス確認が必要だ。さもなければ一度のプッシュが新たな GPL 衝突を 10 万台に配ってしまう。

実装の要点

サプライヤー向けの 3 点：SBOM 生成をビルドパイプラインに組み込み、納品バージョンごとに自動でスナップショットを出す。ライセンスポリシーは「車両と共に配布される」という最も厳格な解釈で設定する——車載ソフトウェアはほぼすべて配布に該当し、ライセンス衝突に「内部利用」の免除余地はない。外部調達のバイナリコンポーネントはツールで検証してから受け入れる——サプライヤーのコンプライアンス宣言には証拠の裏付けが要る。

OEM 向けの 2 点：検収を「SBOM 文書の要求」から「納品物と SBOM の一致をツールで検証」へ格上げする——車載プロジェクトの監査で、実際の成分と一致しない美しい清単を我々は何度も見てきた。全車種のコンポーネント台帳を構築し、新しい脆弱性インテリジェンスが届いたら影響を受ける車種とバージョンを分単位で特定する——これが R155 の「継続的監視」要求のエンジニアリング上の実体である。

自動車業界は 20 年をかけて機能安全（ISO 26262）の完全な体系を築いた。今度はサイバーセキュリティとサプライチェーンセキュリティが同じ道を歩む——ただし今回は 20 年の猶予がない。規制当局はすでに時計を設定済みだ。