ソフトウェアサプライチェーンセキュリティを「品質」で読み解く:ソフトウェアサプライチェーンの守り方(3)(4/4 ページ)
米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。最終回となる第3回は、SBOMの流通によってどんな「良いこと」と「悪いこと」が起こるかを整理しつつ、品質保証の枠組みへの取り込みについても考察する。
製造業にとって脆弱性のリスク管理は「品質管理」と同じ
コロナ禍となって機会が大幅に失われたが、展示会やカンファレンスでアプリケーションやソフトウェアのセキュリティについて会話すると、開発者から次のような意見を伺うことが多い。
- 脆弱性があるからって簡単にOSSのコンポーネントを入れ替えられない
- 脆弱性の対処に時間が取られて肝心な機能やサービスの開発が手間取ってしまう(あるいは、脆弱性の対処を後回しにする)
- セキュリティテストの自動化に取り組んでいるが、漏れ抜けがどうしても出てしまう
- 機能テストはやっているが、セキュリティテストまでは手が回らない
一方で、運用者(あるいは運用組織のセキュリティ担当者)はどう考えているのだろうか?
ソフトウェアを利用/運用する組織や企業の経営層は、ソフトウェアサプライチェーンという新しい言葉に「今までの脆弱性管理と何が違うのか?」と思われるかもしれない。しかし、役割と責務をサプライチェーン全体で共有するモデルに変わろうとしている。
そもそも、利用/運用するシステムのソフトウェアリスクの継続的な監視や評価を行っている組織であればきっとこう思うに違いない。「システム内のブラックボックスを減らせれば、より正確なリスク評価ができる」と。
リスクを評価するということについては「品質」という観点で長い取り組みの歴史を持つ組織が多いと思う。特に製造業では、当然のように「品質管理」という部署を抱え、自社が製造する製品の検品をして「検印」を押して出荷していることだろう。
身近な例で言えば、旅行先で買ったお土産、あるいはコンビニでおやつに買ったお菓子のパッケージには、ご丁寧に「アレルゲン」の一覧や、商品に問題があった際の連絡先の「お客さま相談室」の連絡先が印刷され、さらには検品した担当者が押印した紙が入っているものもある。もちろん、どのような原材料を用いて製造したのか、製造ラインで他のアレルゲンを含む材料と一緒に加工しているのかなど、納得し、安心して食べることのできるようになっているのは、業界全体でルール化し、それを守ってきたからだ※2)。
※2)出発点は1947年(昭和22年)に施行された食品衛生法。同法は、森永ヒ素ミルク事件などにより食品添加物に関する条項を追加するなどし、2003年には食品安全基本法の成立と併せて大幅な改定がなされている。例えば、第10条では「食品添加物として指定された以外の物質やそれを含む食品の販売を制限」、第11条は「規格基準に適合しない添加物および食品の販売を禁止」。違反に対しては、懲役または罰金あるいは、その両方を課すと定めている。そして2015年の食品表示法によって「安全で身体によい食品を分かりやすく選べる」ようにするため、原材料やアレルゲンの表示を義務付けることとなった。
さて、ITシステムやソフトウェアの開発者にとっての「品質」とはなんだろうか。現在の、そして今までの「品質」についての全体像を把握したい方は、ぜひ、@ITで加藤大受氏が執筆しているの連載記事『変わる「ソフトウェア品質」再考』を読んでほしい。「セキュリティ」が品質に期待されていることが示され、今後も安心安全を実現するためにも必要だとしている。
では読者のみなさんは、利用する製品やサービスの「セキュリティ」について何を期待しているだろうか。多くの皆さんの期待は、主に以下の2つではないかと思う。
- 個人情報(クレジットカード情報、各種アカウントのIDやパスワードなど)が盗まれないこと
- 仕事や個人で利用しているWeb会議やオンラインゲーム、SNSなどがサイバー攻撃などで停止するなどしないこと
では、これらを実現するためには「開発者」だけが頑張ればよいのか?
食品表示法やSBOMは確かに食品やソフトウェアの製造を行う組織が中心となることは間違いないが、それらが共有されることで消費者や利用者にも役割と責務が与えられている。例えば食品の場合、「そばアレルギー」を持つ人はアレルゲンの表示を確認して、アレルゲンの表示に「そば」と書かれた食品を積極的に「摂らない」ことが求められていると考えていいはず。だとすると、SBOMも同様に「Log4j」を含むソフトウェアの利用については「セキュリティパッチを適用してから」実運用を行うと「ポリシーを定めて運用する」というように、「リスクを回避」することが求められるということではないだろうか。
セキュリティの問題も食品添加物の問題も「目に見えない」が、社会にとっては重要な課題」であり、いままでも対処してきた歴史がある。確かに、細部の違いをどのように埋めていくのか、ソフトウェア開発の現場が課題解決のためにまずは手を動かして、何が管理でき、何を管理できないのかについて学ぶことからはじめなければその先へは進めないはずだと思う。そして、これらの問題は「品質」に対する取り組みの一環なのである。
その上で、個々の業界のサプライチェーンや組織において議論する必要があるだろうし、実現するための人や予算を確保できない組織や業界のサプライチェーンのための政策が必要になる、ということではないかと思う。(連載完)
筆者プロフィール
松岡 正人(まつおか まさと)
新潟県立長岡工業高校電気科卒。組み込み含む元ソフトウェア開発者。主に制御システムや組み込みソフトウェア開発を中心に昔ながらのベタな開発現場を経験した後、外資系で組み込み開発、サイバーセキュリティビジネスに携わる。JNSA IoTセキュリティWGリーダー、セキュリティ・キャンプ2022講師、サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース メンバーを務める。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「ソフトウェアサプライチェーンの守り方」バックナンバー
- 日本におけるソフトウェアサプライチェーンセキュリティとSBOMの目的
米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。第2回は、日本でのソフトウェアサプライチェーンセキュリティに関する取り組みの状況について紹介する。 - 米国大統領令とEUのCRAが示すソフトウェアサプライチェーンセキュリティとは
米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。第1回は、米欧が唱えるソフトウェアサプライチェーンセキュリティの全体像と目的と併せて、製造業などでも増大しつつあるセキュリティインシデントを減らすための基本的な考え方を紹介する。 - 米国大統領令の影響か? 商用ソフトウェアの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)レポート」の結果について説明した。