米国大統領令とEUのCRAが示すソフトウェアサプライチェーンセキュリティとは:ソフトウェアサプライチェーンの守り方(1)(2/2 ページ)
米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。第1回は、米欧が唱えるソフトウェアサプライチェーンセキュリティの全体像と目的と併せて、製造業などでも増大しつつあるセキュリティインシデントを減らすための基本的な考え方を紹介する。
2つの規制に共通する「サプライチェーンセキュリティ」という考え方
さて、これら2つの規制に共通な点が「サプライチェーンセキュリティ」という考え方である。ここでいう「サプライチェーン」は、製造業で使われる「サプライチェーン」とほぼ同じ意味合いであるものの、そこに「セキュリティ」とあることからイメージできると思うが、「サプライチェーンを安全なものにする」ことが目的だと言っていいだろう。つまり「製品やサービスの開発から利用、運用」までの一連のフェーズを通して「安全である」ことを担保するため、開発者/提供者は、製品やサービスの品質が十分に検証されていること、使用されているOSS(オープンソースソフトウェア)、商用ソフトウェアの一覧をSBOM(ソフトウェア部品表)として提供すること、既知の脆弱性が含まれていないことなどを証明することが求められている。
なぜこのような規制が始まったのか。ここで問題となるのはソフトウェアの欠陥や不具合、あるいはそれらを悪用したサイバー攻撃などによる生活や社会インフラへの影響が甚大となり、経済や行政への影響が大きくなりすぎたからだろう。
2019年からの主なサイバーインシデントを振り返ってみると、個人情報の漏えいだけでなく、企業の機密情報の取得、政府組織に対する攻撃など多岐にわたっていることが俯瞰できる。
- 2019年
- 2020年
- 2021年
- 2022年
個々のインシデントについては、それぞれの記事を読んでいただくこととして、「なぜこれらのような問題が起こるのか?」という点について、読者のみなさんの多くは、これらのインシデントが攻撃者、あるいは悪意ある第三者が、ソフトウェアやシステムの脆弱性を悪用することで発生するのだと理解されていると思う。
しかし、シノプシスが発行する商用ソフトウェアにおけるOSSの利用状況を調査した「2022年オープンソース・セキュリティ&リスク分析(Open Source Security and Risk Analysis:OSSRA)レポート」でも指摘しているように、2021年末に大きく騒がれた「Log4j」の脆弱性についての対策は停滞しており、多くの既知の脆弱性はインシデントが発生するまで放置されていると考えられる。このように、脆弱性が放置される理由について、米国で興味深い「COST OF POOR SOFTWARE QUALITY IN THE U.S」という隔年発行のレポートがあるので紹介したい。
CPSQ(Cost of Poor Software Quality)と命名されたこのレポートが語るのは、脆弱性への対処を含めた品質への取り組みに対する費用をなおざりにしてしまうことで、より大きなコストを将来に持ち越してしまっているというものだ。これを「技術的負債」として説明しているが、レポートそのものの体裁も含め、品質の問題は組織だけでなく社会の「負債」として増えていくことを「コスト」という観点で俯瞰して解説しているのが特徴で、経営層に対して品質を経営目線で理解してもらうためのレポートとなっている。
⇒「COST OF POOR SOFTWARE QUALITY IN THE U.S」の日本語版はこちら
では、どうしたらこのようなインシデントを減らすことができるだろうか。
多くの場合、運用の現場におけるサイバーセキュリティ対策は、インシデントの発生を発見してから対処するのが基本であって、病気が発症してから対処することと似ている。しかし、これら米欧が始めた取り組みは「サプライチェーン」という観点を持ち込み、そもそもインシデントの原因となる可能性のあるもの、マルウェアやエクスプロイトが混入している可能性のあるソフトウェアや、既知の脆弱性のあるOSSコンポーネントやコンテナ、商用ソフトウェアというようなものを可能な限り排除し、十分にテストされ検証済みの安全性の高い製品やサービスを利用することを目指そうとしている。言い換えるならば、病気を予防するために不衛生な食べ物やアレルギーのある食べ物、あるいは毒性のある薬物を摂取しないということだろう。
このような取り組みがうまく機能すれば、インシデントの発生をある程度抑え込めるということなのだろう。より健全で安全な社会に進化していくためには、リスクの高いものを低いものに置き換えていく必要があるが、掛け声だけでは変わらないので「規制」という手段を用いることになる。
身近な例で言うならば、自動車の排ガス規制だろうか。スモッグによる公害に悩まされた米国カリフォルニア州で、1962年に「クランクケース・エミッション規制」、そして1965年には連邦政府に先駆けて排気ガスの一酸化炭素と炭化水素に対する規制、1971年には窒素酸化物の規制が加えられた。そして1970年、「マスキー法」とも呼ばれる大気清浄法が制定され多くの自動車メーカーが対策に苦しむ中、1974年にホンダはCVCC(複合渦流調整燃焼方式)技術を採用したエンジンを搭載したシビックのEPAの認定を取得し、さらに最も燃費の良いことが強みとなって市場での高い評価を得ることにも成功し、規制の壁を乗り越えただけでなく、自動車メーカーとしての地位を築いたといえる。
思うに、米欧が目指す先にあるより良い世界を実現するためには、自動車の排ガス規制同様、ソフトウェア産業とそれを利用する社会全体が次の成熟期に向かうために必要な産みの苦しみと考えてもよいと思う。
筆者プロフィール
松岡 正人(まつおか まさと)
新潟県立長岡工業高校電気科卒。組み込み含む元ソフトウェア開発者。主に制御システムや組み込みソフトウェア開発を中心に昔ながらのベタな開発現場を経験した後、外資系で組み込み開発、サイバーセキュリティビジネスに携わる。JNSA IoTセキュリティWGリーダー、セキュリティ・キャンプ2022講師、サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース メンバーを務める。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「ソフトウェアサプライチェーンの守り方」バックナンバー
- 米国大統領令の影響か? 商用ソフトウェアのOSS由来脆弱性が減少傾向に
日本シノプシスは、商用ソフトウェアにおけるOSS(オープンソースソフトウェア)の利用状況を調査した「2022年オープンソース・セキュリティ&リスク分析(Open Source Security and Risk Analysis:OSSRA)レポート」の結果について説明した。 - シフトレフトからシフトエブリウェアへ、全プロセスでソフトウェアテストが必須に
日本シノプシスは、BSIMM(Building Security In Maturity Model:セキュア開発成熟度モデル)の調査レポートの最新版「BSIMM13」について説明した。 - オープンソースソフトウェアの採用率は98%に拡大、脆弱性含む割合も増加の一途
日本シノプシスは、商用ソフトウェアにおけるOSS(オープンソースソフトウェア)の利用状況を調査した「2021年オープンソース・セキュリティ&リスク分析(Open Source Security and Risk Analysis:OSSRA)レポート」の結果について説明した。 - ソフトウェアのオープンソース比率が70%に、5年前の36%からほぼ倍増
日本シノプシスは、各種産業におけるOSS(オープンソースソフトウェア)の利用状況を調査した「2020年オープンソース・セキュリティ&リスク分析(2020 Open Source Security and Risk Analysis:OSSRA)レポート」の結果について説明。調査対象となったアプリケーションに占めるOSSコンポーネントの比率は70%に達したという。 - 避けて通れぬ自動車のセキュリティ、ソフトウェア開発は何をすべきか
サイバーセキュリティにさらに力を入れるには、ソフトウェア開発のライフサイクル中のサイバーセキュリティ活動も含めて、自動車業界における文化的および組織的なシフトの必要性がある。自動車業界の課題や解決策について解説していく。