ソフトウェアの推移的依存関係をどこまで把握できるか？
まずはソフトウェアのサプライチェーンについて考えてみよう。簡単に言えば、ソフトウェアが本番環境にデプロイされ、ユーザーの元へ届くまでの一連の流れを指す。物流のサプライチェーンを想像してみると分かりやすい。原料が工場に届き、加工され、別の工場に移送されて別の加工が施され……最終的には消費者の元へと届けられる。そうした供給の一連の流れだ。
一方、ソフトウェアのサプライチェーンの流れを見ると、コードには外部ライブラリ（主にOSS）が多く組み込まれている。つまりソースコードは何らかのOSSに依存し、そのOSSはまた別のOSSに依存し、それが何重にも連鎖したものとなっている。悪意あるコードやパッケージを潜ませることをソフトウェアのサプライチェーン攻撃と言う。
開発から本番環境までのサプライチェーン全体に良くないものが混入していないかをチェックするフレームワークにSLSAがある（元々はGoogle社内で使われていたもの）。ソースコードに脆弱性などが混入するポイントには多数ある。例えばソースコードは外部から攻撃されるようなリポジトリに置かれていないか、ビルドされたソースコードが後から改ざんされていないかなど。ソフトウェア開発ではサプライチェーン全体を見て、脆弱性を割り込ませる隙を作らないようにする必要がある。それがサプライチェーン攻撃の防止策となる。
どのくらいの脅威があるのかを数字で見ていこう。JFrog Japanの横田氏は自身の調査結果として「ソフトウェアの99％、エンタープライズ向けソフトウェアなら85％にオープンソースのコンポーネントが含まれます。昨今生じている攻撃の62％がサプライヤーの信頼を悪用したものとなり、2015〜2021年で6.5倍に増加しました。2022年にはさらに4倍に増加すると予想されています」とまとめた。
直近で印象的な事例がLog4Shellだ。2021年末にJavaでよく使われるロギングのライブラリに致命的な脆弱性が含まれていたことが発覚し、問題となった。クリスマス前後で対応に追われた人もいるだろう。
繰り返しになるが、ソフトウェアの依存関係は深く連鎖している。推移的依存関係とも言われる。多くのプログラマが自分のコードや自分が参照したコードであれば、目が届く。しかし遠い依存先までは把握するのは難しい。
横田氏は「身近なところならパッケージマネージャを定義しているファイルがあります。そこにあるのが皆さんが直接使うOSSです。そこに書かれているOSSがさらに何を使っているかを対策していかないと、完全なセキュリティ対策ができているとは言えないのです」と指摘する。
SBOMで抑えるべきポイント3つを詳しく解説
こうしたソフトウェアのサプライチェーンに潜む脅威にどう対策するか。ひとつの答えが「SBOMを作る」こと。もちろん、これだけで全て解決するわけではないが、重要な柱となるのは確かだ。
あらためてSBOMとは「Software Bill Of Materials」の略であり「ソフトウェア部品表」と訳されることもある。食品なら食品成分表をイメージするといいだろう。ソフトウェアを構成するコンポーネントとメタデータの一覧となる。脆弱性やライセンスの観点で安全性を確認する、あるいは保証するのに使われる。
アメリカでは政府と関わる重要なソフトウェアではSBOMが義務化されるほど、ソフトウェア開発ではメジャーなものとなりつつある。日本では自動車業界や医療業界でも徐々に浸透してきている。
SBOMに記載するコンポーネントは、ソフトウェアが依存または使用するOSSやサードパーティーのライブラリ、ソフトウェアが使うアドオン、プラグイン、拡張機能、プロプライエタリなコード、SaaSの場合はAPIやサードパーティーのサービスに関する情報を含んでもよい。プログラムで使うものは全て網羅すると考えていいだろう。SBOMで抑えるべきポイントは次の3つ。
（1）Data Fields
SBOMに記録する情報で、大きく分けてSBOMそのものの情報とソフトウェアの情報となる。前者はこのSBOMが用いているフォーマット、作成者、作成時のタイムスタンプで、後者はコンポーネント（パッケージ）の名前、識別用のキー、バージョン、サプライヤ、そして大事な依存関係だ。依存するものを記載していく。
（2）Automation Support
SBOMの生成や利用を自動化しやすくするための配慮。SBOMのフォーマットは標準的なものに則り生成すること。最近SPDX（Software Package Data Exchange）が国際標準となったが、他にもSWID（Software Identification）やCycloneDXも有名だ。できれば一貫して同じフォーマットで管理したほうがいいだろう。なおSPDXはコロンでタグと値を区切るタグバリュー（tag:value）形式で、他にもJSON、YAML、XMLなどにも対応している。
SBOMに関するツールは大きく分けて生成のためのツール、使用（消費：consume）のためのツール、変換のためのツールがある。生成のツールは自動または手動でSBOMを生成する。自動ならビルド時に生成するといいだろう。使用のためのツールは人間が分かりやすい形で表示するためのもので、SBOMとSBOMを比較するなどSBOMを読み込んで活用する。変換のツールは別のフォーマットに変換したり、複数のSBOMを統合したりする。横田氏によると多くが発展途上でデファクトスタンダードと呼べるツールはまだないとのこと。
（3）Practices and Processes
SBOMは作るだけではなく、活用方法や運用方法も定義しておく必要がある。例えばSBOMを作成する頻度やタイミングならビルドやリリース時にSBOMを新規作成するとか、SBOMを修正するタイミングなど。また推移的依存関係をどれだけ深く含めるかも大事なポイントとなる。横田氏は「悪意あるパッケージが“ない”ことを証明するには完全な網羅性が必要となります。なるべく深いところまで完全に書ききれるようなツールを使うのが大事なポイントです」と強調する。依存関係で不明なところがあれば、不明な箇所を「既知の未知」として明記しておく。
他にも必要とする人が適切なタイミングで使用できるようにする、要件に応じたアクセス制御を定めておく（ライセンスや契約などで定めておく）なども念頭においておこう。なおサプライチェーンのリスク管理は発展途上なので課題や変化には寛容でいるといいだろう。大事なのは「成熟を待つより、今日から始めること」と横田氏は言う。
