全3798文字
PR

 トヨタ自動車が「ソフトウエア部品表(Software Bill of Materials:SBOM)」の活用に力を入れている。SBOMによって車載ソフトに含まれる脆弱性を管理し、自動車へのサイバー攻撃を未然に防ぐ。

 コネクテッド機能や先進運転支援システム(ADAS)などの普及を背景に、車載ソフトは大規模化、複雑化の一途をたどっている。中でも、コネクテッド機能を持つ車載情報システム(IVI)は、オープンソースソフト(OSS)の比率が高く、OSSの脆弱性を突くサイバー攻撃のリスクが高まっている。

 SBOMを使い、車載ソフトに含まれるOSSなどの構成要素をすべて一覧表にし、脆弱性の有無を把握することは、サイバー攻撃を未然に防ぐ上で重要である。これまではSBOMの作り方やフォーマットなどの仕様が統一されておらず、SBOMの活用は自動車業界ではあまり進んでいなかった。ここへ来て、2020年12月にSBOMの仕様が国際標準「ISO/IEC 5230」として固まり、普及への期待が高まっている。

 ISO/IEC 5230は、米Linux Foundation傘下のプロジェクト「OpenChain」が策定した仕様を基にする。同プロジェクトには、米Google(グーグル)や同Microsoft(マイクロソフト)などのIT大手に加え、自動車関連の企業も参画している。中でもトヨタは17年から同プロジェクトに参加し、積極的に推進してきた。ISO/IEC 5230への準拠を発表した最初の企業もトヨタである。

https://www.openchainproject.org/featured/2020/12/15/toyota-iso-5230

 同標準は自動車に限らず、幅広いソフトを対象にしているが、トヨタが活動に力を入れていることから、「今後、車載ソフトのサプライチェーンにSBOMが浸透する可能性が高い」(日本シノプシス ソフトウェア・インテグリティ・グループ プリンシパル・オートモーティブ・セキュリティストラテジストの岡デニス健五氏)という。車載ソフトはさまざまな企業が開発に関わるため、サプライチェーンが複雑で、責任の所在が曖昧になりがちだ。SBOMを使えば、サプライチェーンのどこに問題があるのか、ひと目で分かる。

 ISO/IEC 5230は、OSSのライセンス順守を目的としたものだが、「脆弱性の管理にも利用できる」(同氏)という。OpenChainは、そのための参照ガイド「Security Assurance Reference Guide 1.0」を21年8月に公開した。こちらはまだ国際標準にはなっていないが、ISO/IEC 5230に近い仕様で、「既知の脆弱性」を管理できる。今後、SBOMを使ってOSSのライセンスや脆弱性を管理する手法が自動車業界に広がりそうだ。

https://www.openchainproject.org/news/2021/08/12/openchain-iso-5230-security-assurance-reference-guide-now-available

 日本や欧州では22年7月から国連規則(UN-R)に基づく自動車セキュリティー対策の義務化が始まる。現状では国連規則の中にSBOMに関する具体的な記述はないものの、「今後自動車メーカーとサプライヤーの間で契約を交わす際にSBOMが要件として盛り込まれる可能性がある」(同氏)という。国連規則が参照する標準「ISO/SAE 21434」では、脅威分析をした上で、脆弱性の有無をチェックする必要があるとしているからだ。サプライチェーンにおける“サイバーセキュリティーインターフェース”の要件にSBOMが加わる可能性が高い。

ツールベンダーの競争が激化

 自動車業界でSBOMへの期待が高まっていることを背景に、ツールベンダーの競争が激しくなってきた。通常、SBOMの作成や脆弱性の把握・管理には、SCA(Software Composition Analysis)と呼ぶ自動化ツールを使う。自動車業界では米Synopsys(シノプシス)の「Black Duck」や、カナダBlackBerry(ブラックベリー)の「Jarvis」、イスラエルの新興企業Cybellum(サイベラム)のツールなどがある。

 シノプシスのツールは、ソースコードからSBOMを抽出し管理する「ソースコード解析」で高い実績を持つ。コンパイル後のバイナリーコードからSBOMを作成する「バイナリー解析」にも対応するが、「バイナリー解析ではすべての構成要素を抽出できないことがあるため、ソースコードからSBOMを作成する方が確実」(日本シノプシスの岡氏)と説明する。ソースコード解析なら、「自動車特有のマイコンなどのハードウエア構成を考慮する必要がない」(同氏)という利点もある。

 具体的には、サプライヤーがソースコードを解析してSBOMを作成し、バイナリーコードのソフト本体とセットで提供する形を想定する。また、ソフトを受け取る側は、念のためバイナリー解析を実施し、提供されたSBOMの内容と一致するか確認する。こうしたSBOMの具体的な利用方法は、「自動車業界ではまだ定まっておらず、これからだ」(同氏)という。

車載ソフトのサプライチェーンとOSSリスク
車載ソフトのサプライチェーンとOSSリスク
(出所:シノプシス)
[画像のクリックで拡大表示]

 一方、ブラックベリーやサイベラムのツールは、バイナリー解析に特化している。「100%とは言わないが、すでにバイナリー解析の抽出精度は十分に高い。既知の脆弱性を管理するためには、最終的な車載ソフトの形態であるバイナリーコードを解析すべきだ」(サイベラム日本法人ジェネラルマネージャーの奥田正和氏)と説明する。

 バイナリー解析の場合、自動車メーカーはサプライヤーからSBOMを入手しなくても、自らSBOMを抽出できる。ただ、その場合は「すべての責任とリソースを自動車メーカーが負担する形になる」(同氏)。米国や欧州の自動車メーカーでは、そのような事例があるという。一方、ユニットごとに役割分担をし、「ユニットの責任者である1次部品メーカー(ティア1)がSBOMを抽出し管理する形もありうる」(同氏)とする。

 バイナリー解析の課題は、車載ソフトの構造的な欠陥に起因する「未知の脆弱性」を抽出しにくいことだ。例えば、サイベラムのツールはバイナリーから未知の脆弱性を抽出する機能を持つものの、「見つけられるのは重要な欠陥に限られている」(同氏)という。既知の脆弱性はバイナリー解析、未知の脆弱性はソースコード解析が中心になると話す。ただ、車載ソフトで特に複雑性が増しているIVIの領域ではOSSが多用されていることから、「まずは既知の脆弱性への対処を優先すべきだ」(同氏)とする。