ソフトウェアは通信、エネルギー、防衛産業などの重要インフラを始め、私たちの日常を支える無数のデジタルサービスに深く組み込まれている。しかし、その開発・流通・運用における可視性が十分とは言いがたく、しばしばブラックボックス化が進行しているのが実情である。こうした状況は、組織にとってセキュリティリスクだけでなく、法的・運用的リスクもはらむ構造的課題である。
2024年12月に刊行された『ソフトウェア透明性 攻撃ベクトルを知り、脆弱性と戦うための最新知識』は、このような背景のもと、ソフトウェア・サプライチェーンセキュリティ（SSS）に対する包括的な視点と実践的な対応策を提示している。
本稿では、訳者として本書に関わった筆者が、その要点と示唆を整理する。
2024年12月に発刊した本書は、サプライチェーン領域における著名な実務家である、クリス・ヒューズ氏とトニー・ターナー氏による『Software Transparency：Supply Chain Security in an Era of a Software-Driven Society』を全訳したものである。
本書は、いわゆるソフトウェア・サプライチェーンセキュリティ(以下、「SSS」と表記)について、その背景や脅威、対応する政府機関や民間団体の対応状況などについて体系的・網羅的にまとめた良書として米国内でも評価されている。
SSSについては、日々最新の脅威や攻撃トレンドが発生していることもあり、多くの事業者は手探りで対応策を模索しながら検討している状況である。このような中で本書は、訳者たち（NRIセキュア）がグローバルでの最先端の動向や対応事例などについての調査を実施していた過程で入手したものの一冊であった。
SSSについて特定の脅威動向や特定の対策（たとえばSBOMなど）に特化した参考資料は類書が多数存在している。しかしながら、SSSの背景情報や関連する技術トレンド、それを踏まえた民間・政府の取り組み状況、そしてソフトウェア提供者、利用者双方への示唆等を体系的に整理している文献などはまだそれほど多くはない。
その中で本書は、著者たちの実務経験やサイバーセキュリティ業界をリードする立場から、SSSの対応に必要となる情報を取捨選択しつつ、最低限必要となる前提知識から原著執筆時点である2023年前半時点までの動向を体系的に整理している。また、脅威や技術面の解説だけではなく、ソフトウェアのサプライヤやユーザーなどのための実践的ガイダンスも記載されており、具体的にソフトウェアを取り扱う際の一定の指針も示されている。
著者たちの主張は明確であり、タイトルにもあるとおり「ソフトウェア透明性」の重要性を訴えるものだ。私たちが日常的に利用している自動車や飛行機、医薬品などについては、利用者がその安全性評価について高度な知見を有していなくとも安全に利用することができるよう、国による安全制度や業界ごとのさまざまな仕組みなどによって安全性が担保される仕組みが構築されている。
しかしながら、ソフトウェアについては、通信やエネルギー、防衛産業などの重要インフラを始め、私たちが利用する日常的なサービスがあらゆるデジタルサービスに組み込まれているにもかかわらず、その安全性を担保する仕組みや技術がいまだ確立されていない。ソフトウェアが組み込まれたサービスにおけるサプライチェーンの流れも含めてブラックボックス化されており、利用者（あるいはソフトウェアを購入した事業者）からは、ソフトウェアの安全性を把握するのが非常に困難となっている。一方で、そこに付け込んだサイバー攻撃などは増えてきており、これらへの対応が急務となっている状況である。
このような状況を踏まえ、現在世界中の政府や国家がセキュアでないソフトウェア、透明性の欠如、安全な製品と技術に対する説明責任の欠如への対応として、透明性の強化を促す動きが起こっている。本書では単に透明性向上を訴えるだけではなく、それを実現するためのツールの高度化や組織の高度化なども合わせて必要であると述べ、抽象的な理想論だけではなく、具体的な改善策、アプローチ方法にまで踏み込んだ指摘がなされている。
本課題に対応するためには、ソフトウェアサプライヤだけではなく、利用者や関連ベンダーなどの多様なステークホルダーが関係してくるが、それらの多様なステークホルダーごとに必要なアプローチ、視点を提供している点も、本書の1つの特徴であるといえるだろう。
本書の内容は基本的には米国の事例を中心に記載されているものの、記載されている内容・示唆についてはSSSに取り組む日本の事業者を始め、政府のセキュリティ政策立案者やソフトウェアを利用するユーザーなどの幅広い方々にとっても参考になる情報が含まれていると考える。ぜひ手にとって内容を確認いただき、本書がSSSに対する理解や関心をさらに深めるきっかけとなれば幸いである。
我が国におけるSSSの取り組みについては、関心が高まったのは、2020年12月に公表されたSolarWinds社の製品「Orion Platform」に対するソフトウェア・サプライチェーン攻撃の事案以降である。これ以降、SSSに対する危機感が高まり、米国が規制の強化に取り組んでいることを踏まえ、日本を含めたその他主要各国も規制強化の検討を進めている。現在では、G7 などの主要な国際会議に挙げられる重要な取り組み課題の1つとなっている。
日本においても、各省においてSSSについての具体的な検討が進められているところであるが、法規制という観点では、2022年5月11日に成立した経済安全保障推進法が、SSSの対応を求める法規制として注目を集めている。
以下、簡単に本法の内容について紹介する。
本法は4つの柱から構成されるが、このうち第2の柱である「基幹インフラの安全性・信頼性の確保」は、基幹インフラの重要設備が役務の安定的な提供を妨害する行為の手段として使用されることを防止するため、 国が一定の基準のもと、基幹インフラ事業（特定社会基盤事業）および事業者（特定社会基盤事業者）を指定するものである。そして、国が指定した重要設備（特定重要設備）の導入・維持管理等の委託をしようとする際には、事前に国に届け出を行い、審査を受ける制度が構築された。本制度は、2024年5月17日より制度運用が開始されたところである。
本制度に基づき、特定社会基盤事業者として指定を受けた事業者は、特定重要設備の導入および重要維持管理等の委託について、導入等計画書の事前届け出が必須となり、「リスク管理措置」などへの対応が求められている。国によって対応が求められるリスク管理措置は多岐にわたるが、とくにSSSの観点に着目して求められるリスク管理措置が含まれている点が重要であろう。
内閣府は、特定社会基盤事業者向けに特定社会基盤役務の安定的な提供の確保に関する制度の解説書を公表している。その中で、特定社会基盤事業者が特定重要設備を導入する場合に求めるリスク管理措置として6つの措置の実施を求め、導入等計画書において実施したリスク管理措置の項目にチェックを付して届け出ることを義務付けている。
|
＃ |
リスク管理措置（一部抜粋） |
|
① |
製造等の過程で、特定重要設備及び構成設備に不正な変更が加えられることを防止するために必要な管理がなされ、当該管理がなされていること。 |
|
② |
将来的に保守・点検等が必要となることが見込まれる場合に、当該保守・点検等を行うことができる者が特定重要設備又は構成設備の供給者に限られるかどうか等の実態も踏まえ、供給者を選定している。 |
|
③ |
不正な妨害が行われる兆候を把握可能な体制がとられており、不正な妨害が加えられた場合であっても、冗長性が確保されているなど、役務の提供に支障を及ぼさない構成となっている。 |
|
④ |
特定重要設備及び構成設備の供給者や委託の相手方について、過去の実績を含め、我が国の法令や国際的に受け入れられた基準等の遵守状況を確認している。 |
|
⑤ |
特定重要設備及び構成設備の供給や委託した重要維持管理等の適切性について、外国の法的環境等により影響を受けるものではないことを確認している。 |
|
⑥ |
特定重要設備及び構成設備の供給者や委託の相手方に関して、我が国の外部からの影響を判断するに資する情報の提供が受けられることを契約等により担保している。 |
出典：内閣府公表資料を元にNRIセキュアテクノロジーズが作成
従来も重要インフラ事業者に対しては、国は一定の情報セキュリティ対策を求めていたものの、経済安全保障推進法で求められるリスク管理措置は一歩踏み込んだ対策まで求めるものとなっている。たとえば、リスク管理措置①では、その具体的な管理策の1つとして、「特定社会基盤事業者等において、特定重要設備に悪意のあるコード等が混入していないかを確認するための受け入れ検査その他の検証体制が構築されており脆弱性テストが導入までに実施されることを確認」することを求めている。
ここでいう「悪意のあるコード等が混入」とは、特定重要設備等の機能を停止または低下するような、設計書や仕様書に含まれていない意図していない機能が組み込まれることを指しているが、このような要求事項に対応していくためには、不正なプログラム混入対策や脆弱性管理、ソフトウェア改ざん検知などの個別の対策ごとに検討することが必要である。
このようにリスク管理措置に対応するためには、サプライチェーンセキュリティ、とくにソフトウェアセキュリティの観点での対応が求められるが、図にあるとおり、現状日本企業の多くはこれらの対応が遅れている状況である。
出典：NRIセキュアテクノロジーズ株式会社「NRI Secure Insight 2023」
このうちSBOMについては、ソフトウェア透明性を実現する主要なツールではあるものの、米国では約8割が導入済み／検証中であるのに対して、日本は導入済み／検証中の事業者は3%程度で、ほとんどの事業者は検討中／もしくは未検討の状況であり、そもそもSBOMを「知らない」と回答した事業者が36%もいるという点は、米国が2%程度である点と比較すると大きく遅れていることがわかる。
なお、ソフトウェア・サプライチェーンには、さまざまな種類のリスクが存在しているため、SBOMはその対策の1つとなりうるが、それ以外にもさまざまな対策が求められる。
具体的に例を挙げると、委託先の監査や開発時のルール策定による統制といった、組織やルールに働きかけるアプローチもあれば、取得したライブラリの検査やソースコードのレビューといった、テストフェーズで実行される対策もある。これらには、ソフトウェアのセキュリティ水準を向上させるための一般的な取り組みと重なるものが多いが、今日の脅威事例などを踏まえて既存の対策で対応できるか、改めて確認・検証が求められる。たとえば、ソースコードのレビュー時には、設計書・仕様書とソースコードの突合チェックなどの実施まで踏み込んで対応することが重要であろう。
ソフトウェア・サプライチェーンリスク対策自体に新しい技術や対応は多くなく、従来のソフトウェア品質向上の対策がほとんどである。しかしながら、それらの対策は非常に多く、どのシステムに対しても一律で対策のすべてを行うことは現実的ではない。ここで重要になるのはシステムに対する脅威分析とリスクベースのアプローチである。脅威分析とは、システムで取り扱う情報の重要度や、求められる可用性要件、利用形態などを考慮して、どの対策を実施するべきかを検討することだ。これを効率的に行う方法を検討するのがソフトウェア・サプライチェーン対策検討の第一歩であるといえる。
システムの重要度を見極め、サプライチェーンリスクのうち、どのようなリスクが自社システムに内在しているか（どのリスクの対策が未実施であるか）を判断し、リスクベースで対策を検討することが求められる。事業者が不正なプログラムなどを検出するのは容易ではないため、開発時だけではなく、運用フェーズでの監査などを含めた多層防御の考え方が重要となる。
日本においても経済安全保障推進法などに基づくSSSに対する対応強化の動きが活発になっている。その一方で、その対応にあたるセキュリティ人材は限られており、各社対応に苦慮している状況でもある。SSSの対応に統一的な施策はなく、自社サービス・システムのリスクに応じた対応が求められるが、その対応にあたり当社からの情報が少しでも参考になり、SSSの対応強化に貢献できれば幸いである。