米国大統領令から考えるソフトウェアサプライチェーンとその課題
欧米のサプライチェーンに関するサイバーセキュリティの動向
いま米国を中心に、ソフトウェアの安全性を高める取り組みとして、サプライチェーンにセキュリティの考え方を取り込もうという動きが出ている。ここではソフトウェアを開発するにあたり、品質やテストについての取り組みを考察する。
実は昨年、欧米のサイバーセキュリティ政策に大きな動きがあった。米国では、2021年5月に大統領令として「E0 14028」が発令され、欧州でも「NIS2」のドラフトが明らかにされた。この中で2つキーワードが注目を浴びた。1つは「ゼロトラスト」、もう1つが本稿のテーマである「サプライチェーン」である。
まず、米国大統領令EO 14028は「Improving the Nation’s Cybersecurity」というもので、すでに米国内で多くのドキュメントやガイドラインが出ている。特にサプライチェーンというテーマで重要な点は、セクション4の「サプライチェーンの向上」である。ソフトウェアを流通するに当たり、「ソフトウェア自体の透明性をいかに高めていくかという点が、非常に重要な取り組みである」と指摘している。そのためのツールとして「SBOM」、あるいは自動化テストの「AST」（Application Security Testing）の活用を推奨している。
この背景としては、数年にわたり米国を中心に起きている、大規模かつ巧妙な国家レベルのサイバー紛争とサイバー攻撃が挙げられる。そこで悪用された脆弱性が、サプライチェーンに関連するものであったことが大きなトリガーになった。ところが、サプライチェーンのリスク評価は、あまり適切に行われていない。この問題に関しては、欧米でも同様の傾向が見られる。
なぜ、いまSBOMがサプライチェーンセキュリティで重要なのか？
このような状況で、ソフトウェアを物流品とみなし、サプライチェーンのセキュリティを高めるために重要な取り組みが、前出の透明性ということになる。一般的な製造業では、これまで「部品表」（Bill of Materials）、あるいは実際にモノを作る際の「生産部品表」という形で、同じデータを異なるデータベースで参照できる仕組みを持っていた。
ただ気をつけたいのは。これらはあくまでモノを作って売るためのデータベースで、そこには脆弱性やセキュリティといったキーワードはほとんど出てこないのが実態である。おそらく今後は何らかの形でセキュリティ情報が紐づくかもしれないが、現状はそこまでは落とし込まれていない。そこで登場するのがソフトウェア部品表の「SBOM」というものだ。
このソフトウェア部品表は、開発あるいは運用しているソフトウェアの中に含まれるソフトウェア部品が何かを明らかにするリストである。これがあると、特にサプライチェーンでいう下流側の運用者にとって、セキュリティを担保するための大きなメリットがあると考えられる。
いままでもSBOMはあったかもしれないが、開発組織内で脆弱性を管理するためだけに内部で閉じて使われていた。ところが昨年の大統領令でも書かれている通り、「SBOMをサプライチェーン、つまり開発側だけでなく、下流ユーザーにも利用できるようにするためには機械可読式で動的に更新できるような仕組みであるべき」ということが述べられている。
「サプライチェーン全体の中で最終的に市場で運用されるソフトウェアは、世の中に数多ある部品を選択して使うことになり、そのとき部品類を統合した複合品にどんなものが含まれ、どのようなリスクや脆弱性があるのか、あらかじめ判明していれば、より適切な対処ができる」と説明するのは、米国でSBOMの推進を長く続けているNTIAという団体である。たとえば、医療関係に例えれば、アレルゲンを取れない人は当然いるわけで、そのような判断を下せるはずだ。
SBOMの課題と規制当局、および業界団体からのアプローチ
ただし、SBOMのサプライチェーンへのセキュリティの取り組みは、まだ始まったばかり。技術的な問題も多く残っている。たとえば、脆弱性情報を取り込めても、セキュリティアドバイザリー情報を適切にハンドルする枠組みが確立されていない。その仕組みとしてCSAFやVEXがあり、CSAFでは脆弱性情報だけでなく、セキュリティアドバイザリー情報も流通できる機械可読式（JSON）にて情報を提供する枠組みを提案中である。
業界ごとに取り組みが進む中で、主要業種でいうと医療用機器分野では、FDAやIMDRFといった規格・規制により、すでにSBOMの利用が促されている。また前出の大統領令EO 14028は、米国政府のソフトウェア調達に関連するものであり、また自動車分野では現時点でライセンスが中心だが、OpenChian（ISO 5230）を利用したライセンス・マネジメントが進んでいる。
先ほどの医療用機器ではNTIAが中心となり、SBOMに関するPoCが行われた。機器メーカーと医療機関の双方が参加し、実際に運用でどんな課題があったのかをレポーティングしている。前出のVEXも、このPoCの中で初めて運用された。ここでSBOMのコンポーネントを特定するPID（主キー）に「psckage URL」を使ったことが明記されている。
すでに終了したが、IMDRFでもパブリックコメントが求められた。SBOM運用に関してのガイドラインのパブコメが募集され、日本シノプシスもパブリックコメントを出している。サプライチェーンのSBOMボムの取り組みがある一方で、そもそもソフトウェアを安全なものとして開発できるようにしていく必要もある。そのための新しいガイドラインが、NSAやCISAを中心に開発されているところである。
たとえば「Software Supply Chain Guidance for Developers」が登場しているが、これはサプライチェーンの考え方を取り入れた開発者、利用者向けのガイドライン＆ガイダンスである。いずれにしても、ソフトウェアが流通する際に、開発・提供・運用・利用のプロセス全体を俯瞰して、どのような対策が必要なのかを、今回の大統領令でうたっているわけだ。
SBOMはサプライチェーンセキュリティの要だが、取り組むべきことは多数
ただ気をつけなければいけない点は、SBOMのソフトウェア部品表という考え方は、サプライチェーンの要になっても、取り組まなければならないことのほんの一部でしかないということである。大統領令でのセクション4において、サプライチェーンを向上するための取り組みとして、ソフトウェアの透明性を高めるという話があったが、その中でSBOMを利用したり、自動化テストの価値を広げたりする必要があると説明している。
実は前出の新しいガイドラインだけでなく、既存ガイドラインもEO 14028に合わせてアップデートされている。特にNISTに関してのガイドラインが出ている。全体を見るときは、大統領令セクション4がサマリーになり、個別の話はガイドラインの記述がアップデートされ、大統領令の記述に合わせられる形となっている。
たとえば、NISTではサプライチェーン全体のセキュリティについて、「Software Supply Chain Security Guidance」を見ることを推奨し、実際にどんなテストを行うのかという点は「Recommended Minimum Standards for Vendor or Developer Verification of Software」を読むことを勧めている。特に開発全体のフレームワークについては「SP80-218 SSDF」（Secure Software Development Framework）で規定しており、大統領令に合わせてバージョン1.1にアップデートされている。
この冒頭に重要なことが記載されている。「下流に問題が発生するようなことを、上流で起こさないこと」を強く訴えている点である。これがサプライチェーン対策の考え方の基本になる。さらにSP800-218で「開発組織が行う各アクティビティに対し、どのような手順で何を行うべきか」という点も、42のプラクティス（項目）に細かく分けて説明している。
重要なポイントとして、適切な運用や開発を行うために教育やプロセスや技術など、組織全体で準備しなければならない項目が13個ほど挙げられている。またソフトウェアそのものを保護するために必要な項目が4個、安全性の高いソフトウェア開発に関する項目が16個、脆弱性への対応の項目が9個、延べ42のプラクティスで構成されている。ただし42個もあるため、ドキュメントを読んでも、なかなか腹落ちしないかもしれない。
そこでシノプシスでは、もう少し簡単な項目から手をつけられるガイドラインを用意した。6つのポイントから、サプライチェーンのセキュリティ対策を考えるものだ。
たとえば、「セキュアのオープンソースを使用していますか？」といった質問に答えていくと、自身の組織が抱える問題が明らかにされ、それらに対してどんな対策が打てるのか、そのヒントが得られるようになっている。
セキュリティは一体、誰が担保するものなのか？ という素朴な疑問
さて、ここまで説明してきたものの、開発者から見ると「セキュリティは誰が担保するものなのか？」と疑問を持つ方も多いだろう。本件については、国際規格が数年前にアップされており、実は日本のメンバーが強く働きかけたことで有名である。これによると「セキュリティは品質指標の1つ」となっている。「JIS X 25010:2013」（ISO/IEC 25010:2011、日本では「SQuaRE」）という製品品質モデルで知られるものだ。
従来までは、セキュリティ項目はJIS X 0129-1の副特性という位置づけだったが、新たに品質特性として追加されている。特性のトップティアの一つとして取り込まれたが、これは現在のセキュリティの課題を考えると当然のことだろう。
プロジェクトマネジメントのためのガイド「PMBOK」や、ソフトウェアエンジニアリングのガイド「SWEBOK」はあるが、実はソフトウェア品質のガイドとして「SQuBOK」もある。このSQuBOKは日本発のもので、それだけ日本は品質について真剣に取り組む方が多いという証になるものだ。ソフトウェア品質指標の一つとして、セキュリティが取り上げられているのである。
グローバルで見ると、開発にセキュリティを取り込む動きは、2013年に米国で大規模な形で実施された。BSI（Build Security In）といわれるもので、形式知化された当時のベスト・プラクティスが開示されている。これはセキュリティの観点で18の項目があり、そのなかで開発に対して16項目が挙げられている。それぞれ粒度は違うものの、これらをまとめたものが現在CERTで公開中だ。いわゆる形式知を共用したものになる。
以下、詳しい内容について2つに分けて紹介する。サプライチェーンについては、実は2013年時点でリスクがあることが指摘されていた。「企業買収、購買やベンダーによるコードの納入や統合に伴う事柄も扱う」とあり、現在の問題が、この段階で掲げられていたことが分かる。また実運用者は、6番のガバナンスの問題が重要になる。インシデントや内部脅威の問題、レガシーシステムをいつまで動かすのか、パフォーマンスが落ちた運用体制をどうすべきか、といった点も挙げられている。
一方、後半を見ると、たとえば16番ではシステムとしてどんな環境を用意すべきか、17番では要求内容が常に変わってくるため、トレーニングや意識向上の改善も必要になることなど、重要な項目が挙げられている。
このBSIは10年前に公開されたものだが、当時集めた18個のベスト・プラクティスが本当に実践できているのかを振り返って、前出のNIST SP800-218 Rev1.1、あるいは前段階となるシノプシスのホワイトペーパーなどを読んで、どこから着手すべきか、どこに課題があるのかを認識することが非常に重要であろう。
たとえば4つの項目を挙げると、いまサプライチェーンで課題になっている点は、開発段階で検証がしっかりできているか、ブラックボックスになったバイナリを使うケースが製造業では多く、クラウドの世界でもネイティブのWebアプリケーションの世界でもコンテナが登場したが中身までテストしていない、精査していないこともあるだろう。
そういうことも含めて、自分たちがどこまで検証しており、どこにリスクがあるのかを把握ですること、あるいはリスク分析ができているかという点が非常に重要なポイントになる。当然テストされていない点はリスクだが、それらを踏まえてどこから手をつけていくのがベストなのか、10年前の先人が残したBSIの知見を利用するところから始めてみるのも良いのではないだろうか。
