新車のボンネットを開けても、レンチで直せるものはほとんど見当たりません。代わりに目にするのは大量のソフトウェアです。ダッシュボードの画面はおそらくAndroidかLinux系OSで動いており、路上の状況を監視するシステムには、航空機や工場のラインを制御するのと同種のコード――QNXやVxWorksが使われている場合もあります。
自動車メーカーはこの10年をかけてこの移行に取り組み、その結果アプリストアやワイヤレスアップデート、より短いリリースサイクルを手に入れました。しかしその一方で、あまり歓迎されないものも背負い込むことになりました。それは、こうしたプラットフォームがこれまでに蓄積してきた、公開済みの既知の不具合すべてです。
Télécom SudParisの研究者たちは、その「積み荷」を数えてみることにしました。VERAと呼ばれるスキャナーを開発し、現行の自動車に搭載されているオペレーティングシステムに向けて実行し、既知の欠陥を集計したのです。その量は膨大でした。同時に、単なる数字が示す以上に複雑な実態も浮かび上がり、そちらの方がむしろ興味深い話になっています。
あなたの車で何が動いているのか
まず研究者たちは、どのメーカーが何を使っているのかを調べました。自動車メーカーはこの種の情報を企業秘密として扱っているため、これは見た目以上に難しい作業です。2023年型のBMWのダッシュボードは、Qualcomm製チップ上でAutomotive Grade LinuxとAndroidを動かしています。GMとCadillacは、2026年型モデルでRed Hatの車載OSへの移行を進めています。Teslaは何年も前からひっそりとLinuxを採用してきました。こうして並べてみると、自動車の車列は、セルラー通信、Wi-Fi、Bluetooth、そして車内の内部配線に接続された、汎用コンピューターの集合体のように見えてきます。
次に研究者たちはスキャンを実行しました。結果の数値はまちまちでした。Automotive Grade Linuxは、検証対象のバージョンにおいて1,203件の既知の欠陥を抱え、トップに立ちました。Androidもそれに迫る数でした。一方、安全性を重視した軽量スタックであるEclipse S-COREは、わずか8件にとどまりました。この差の一因は、各プラットフォームが搭載する追加ソフトウェアの量の違いにあります。もう一因は注目度です。人気のあるオープンなプラットフォームほど多くの研究者に調べられるため、その分多くの欠陥が記録として残ります。注目されること自体が、一種の露出リスクなのです。
認証済みだからといって鉄壁とは限らない
安全性の認証を受けたシステムなら問題がないはずだと思うかもしれませんが、実際はそうではありません。QNX Neutrinoは高く評価されるセキュリティ認証を取得していますが、検証対象のビルドでも56件の既知の脆弱性が記録されていました。VxWorks 7はさらに上位の認証レベルに位置していますが、それでも数十件近くの脆弱性が見つかっています。
もちろん、認証には実質的な効果があります。攻撃対象領域を縮小し、コードの構築方法に規律をもたらします。しかし、認証をもってしても、周囲を取り巻く膨大なソフトウェア群が新たな不具合を生み出し、誰かがそれにパッチを当て続けなければならない状況を止めることはできません。
大きな数字は「対応すべき課題」であり「判決」ではない
ここでこの研究は自らに正直になり、そして世間を騒がせる見出しの多くが崩れ落ちる地点にたどり着きます。記録された脆弱性とは、あくまで「可能性」にすぎません。条件がそろえば問題になり得る弱点であって、そもそも脆弱なコードが有効化されているか、攻撃者がそこに到達できるか、環境設定がたまたま条件に合致するか――それらすべてが揃って初めて意味を持ちます。1,000件の欠陥があるということは、防御側が注意を払うべき対象が1,000個あるということであり、車への侵入経路が1,000通りあるという意味ではありません。
その違いを示すため、研究チームは実際に機能する2種類の攻撃を構築しました。一つはAndroid Automotive上で動く、さまざまなアプリに組み込まれているデータベースエンジンSQLiteの不具合を狙ったものです。もう一つはSOME/IPと呼ばれるサービスディスカバリプロトコルを標的にしたもので、こちらは物語全体を凝縮したような結果になりました。
研究チームは同じ攻撃を3種類のプラットフォームに対して実行しました。Red HatのAutoSDとTeslaのソフトウェアに対しては攻撃が成功し、サービスをダウンさせることができました。一方Android Automotiveでは失敗に終わり、研究者たちはこれをプラットフォームがポート番号をランダムに変更していることが原因だとみています。一つの不具合、三つのシステム、そして全く異なる結果です。書類上の深刻度スコアは同じでも、実際にどの防御策が有効になっているかによって結果は大きく変わったのです。
これらの検証はすべて、再現性を重視して選ばれたラボ環境のDockerコンテナ内で行われました。この構成は、ファイルシステムや導入済みパッケージ、設定内容についてはきちんと再現しますが、メーカー独自のカスタムカーネルやファームウェアの特性、ハードウェアによる保護機構は再現できません。つまりこの数字が語っているのは、あくまでソフトウェアイメージに含まれる内容であり、実際に自宅の駐車場に停まっている車の中で何が起きるかまでは示していません。
スキャナーにも「車問題」がある
ここには現場目線の課題もあります。セキュリティ担当者が日常的に頼る一般的なスキャナーは、構成部品がきちんと整理されたクリーンなシステムを前提としています。しかし車はそう都合よくはできていません。人気のスキャナーの一つであるTrivyは、あるロボティクス用イメージ単体に対して1,000件を超える誤検知を吐き出した一方、他のイメージではほとんど有用な結果を出せませんでした。VERAは既存のツール群の上に構築され、自動車特有の実情に合わせてフィルタリングを行い、ロックダウンされた車では絶対に露出しないようなコマンドラインユーティリティや開発者向けツールの欠陥を除外します。その結果得られるのは、より短く的を絞ったリストであり、誰かが実際に対処しきれる分量に収まります。
ここから持ち帰るべき教訓はこうです。今や自動車に搭載されているコードは、コンピューティングの世界全体と系譜を共有し、いわば「前科」も共有しています。その前科リストの長さは、監視すべき対象がどれほどあるかを示しています。しかし本当に重要な仕事は、その古い不具合の中で、実際にあなたの車に誰かが手を出せてしまうものはどれなのかを見極めることなのです。
翻訳元: https://www.helpnetsecurity.com/2026/07/24/car-research-automotive-software-vulnerabilities/
