先日発生したJavaScriptライブラリであるAxiosに対するソフトウェアサプライチェーン攻撃の話題が大きな注目を集めています。Axiosは、多くのWebアプリケーションで使用されているライブラリだけに、「自社のシステムは影響を受けるのか」と不安を感じた現場も少なくないのではないでしょうか。ところが、実際に調べるとなると、簡単には行きません。Node.jsを使っているWebサイトぐらいまでは、すぐわかるのですが、その配下で使われている個別ライブラリの使用有無を調査することは簡単ではないのです。
目次
なぜ「使っているか分からない」のか
最新のWebアプリケーション開発では、Node.jsをはじめとするモダンな開発環境が広く利用されています。これらの環境では、ゼロからすべてを実装するのではなく、既存のライブラリを組み合わせてシステムを構築するのが一般的です。その中心にあるのがnpm（Node Package Manager）です。npmには世界中で公開されているライブラリを取り込み、利用できる仕組みが整っています。
この仕組みは開発効率を飛躍的に高める一方で、依存関係を複雑にしています。例えば、開発者があるライブラリを1つ導入した場合、そのライブラリが内部でさらに別のライブラリを使用していることは珍しくありません。さらに、その先でも同様に依存が連鎖し、いわゆる「間接依存」が何層にも重なっていきます。
その結果、開発者自身が意識して使用していないライブラリが、組み込まれているケースが発生します。今回話題となったAxiosのようなライブラリも、意図的に使用している場合だけでなく、別のライブラリを経由して間接的に組み込まれている可能性があります。このような構造では、「自分たちは使っていない」と思っていても、実際には依存関係のどこかで使用されていることがあり得るのです。
さらに、この依存関係は固定されたものではありません。ライブラリのアップデートやビルドのタイミングによって構成が変化するため、ある時点では使用していなかったライブラリが、気づかないうちに追加されていることもあります。こうした変化を人手で追い続けることは現実的ではありません。
このように、モダンな開発環境では「どのライブラリが使われているか」を正確に把握すること自体が難しい構造になっています。冒頭で触れたように、「Node.jsを使っているかどうか」は把握できても、その内部でどのライブラリが使われているのかを調べることが難しいのは、この依存構造に理由があります。
SBOMとは何か―「見えない依存関係」を可視化する
この「見えない依存関係」をどのように管理すればよいのでしょうか。その解決策として注目されているのが、SBOM（Software Bill of Materials）です。SBOMとは、ソフトウェアを構成するコンポーネントの一覧、いわば「部品表」です。どのライブラリを、どのバージョンで使用しているのかを体系的に整理したものを指します。
重要なのは、SBOMが単なる一覧ではなく、「判断を可能にする情報」であるという点です。例えば、あるライブラリに重大な脆弱性が見つかった場合、自社のシステムに影響があるかどうかを迅速に判断できるかどうかは、対応のスピードに直結します。SBOMがあれば、該当ライブラリの使用有無や影響範囲を横断的に把握することが可能になります。
また、SBOMは直接利用しているライブラリだけでなく、間接依存も含めて可視化できるため、「知らないうちに使っていた」というリスクを減らすことにもつながります。サプライチェーンリスクが現実の脅威となっている今、SBOMは「何を使っているかを説明できる状態」を実現するための基本的な手段と言えるでしょう。
どのシステムからSBOMを導入すべきか
では、SBOMをどのシステムから導入すべきなのでしょうか。すべてのシステムに一律で適用することが理想ではあるものの、現実的には優先順位をつけて進める必要があります。その際の判断軸として最も重要なのが、「外部コンポーネントへの依存度」です。
前章で見たように、サプライチェーン攻撃の本質は、「自分たちが直接管理していないコンポーネントに依存していること」にあります。したがって、SBOMの導入対象も、「どれだけ外部コンポーネントに依存しているか」という観点で見極めることが合理的です。
具体的には、Node.jsやPython、Java（Spring）など、パッケージ管理ツールを前提とした開発環境で構築されたシステムが該当します。これらのシステムでは、npmやpip、Mavenといった仕組みを通じて多数のライブラリが取り込まれており、その多くはさらに別のライブラリに依存しています。その結果、開発者が直接認識していないコンポーネントが、システムの一部として組み込まれている状態が生まれます。
このようなシステムでは、「どのライブラリを使っているか」を完全に把握すること自体が難しく、今回のような事象が発生した際にも、影響の有無を即座に判断することができません。言い換えれば、外部コンポーネントへの依存度が高いシステムほど、「見えないリスク」を多く抱えていると言えます。
だからこそ、SBOMの導入は、こうした依存度の高いシステムから優先的に進めるべきです。すべてを対象にするのではなく、「外部コンポーネントに強く依存している領域」から可視化していくことで、ソフトウェアサプライチェーンリスクに対して最も効果的に対応することが可能になります。
SBOMは「小さく始めて運用に乗せる」
SBOMの導入で重要なのは、最初から完璧を目指さないことです。まずは、外部コンポーネントへの依存度が高いシステムを1つ選び、そのSBOMを生成してみるところから始めます。現在では、npmやMavenなどのパッケージ情報からSBOMを自動生成できるツールが整備されており、特別な準備をしなくても取り組むことが可能です。
SBOMにはCycloneDXやSPDXといった標準フォーマットがあります。一般的には、CycloneDX はアプリケーション開発やDevSecOpsの文脈で利用されることが多く、軽量で扱いやすい点が特徴です。一方、SPDXはライセンス管理やコンプライアンス対応の領域で広く利用されており、歴史が長く成熟しているという特徴があります。ただし、どちらを選ぶかに過度にこだわる必要はなく、利用するツールに合わせて選択すれば十分です。
次に重要なのは、SBOMを継続的に生成する仕組みを作ることです。依存関係は更新のたびに変化するため、CI/CDパイプラインに組み込み、ビルド時に自動生成する形にすることで、常に最新の構成を把握できる状態を維持します。
また、生成したSBOMは保管するだけでなく、脆弱性情報と突合できる形で活用することが重要です。特定のライブラリに問題が発生した際に、影響範囲を迅速に特定できるかどうかが、実務上の価値を大きく左右します。
SBOMは特別な仕組みではなく、「何を使っているかを把握する」ための基本的な管理の延長線にあります。小さく始めて、継続的に回る仕組みを作ることが、現実的で効果的な導入方法です。
委託先への統制
開発を外部ベンダーに委ねている場合、ビルドされた実行可能なファイルのみを受け取っているケースがあります。このようなケースでは、ライブラリの使用有無は委託先に調査を依頼しない限り分かりません。また、その調査には時間がかかることも少なくありません。
こうした状況を避けるためには、SBOMを「納品物の一部」として位置付けることが重要です。つまり、ソースコードや設計書と同様に、「どのライブラリを、どのバージョンで使用しているのか」を明示したSBOMの提出を、契約上の要件として求めるのです。
さらに、SBOMは一度提出させて終わりではなく、システムの更新に合わせて継続的に提出させる仕組みとする必要があります。リリースやアップデートのたびに最新のSBOMを提出させる、あるいはCI/CDの中で自動生成されたSBOMを納品物に含めるといった運用を設計することで、常に最新の構成情報を把握できる状態を維持することができます。
最後に
Axios におけるソフトウェアサプライチェーン攻撃が示しているのは、「脆弱性の有無」以前に、「自分たちが何を使っているかを把握できているか」が問われているという点です。モダンな開発環境では、外部コンポーネントへの依存は避けられず、その構成を正確に理解すること自体が難しくなっています。
だからこそ重要なのは、「何を作ったか」だけでなく、「何を使っているかを説明できる状態」を維持することです。SBOMはそのための特別な仕組みではなく、ソフトウェアを安全に運用するための基本的な前提と言えます。
すべてを一度に整備する必要はありません。まずは外部コンポーネントへの依存度が高いシステムから、小さく始めて確実に運用に乗せること。そして、委託先を含めた開発全体で可視性を確保すること。その積み重ねが、サプライチェーンリスクに強いシステムと組織をつくる第一歩となります。
SBOM機能対応「CSIRT MT.mss」
SBOMによるソフトウェア情報管理およびSBOMを利用した脆弱性管理に対応する機能
https://www.grcs.co.jp/products/csirtmt
北尾 辰也
サイバーセキュリティコンサルタント。三菱UFJ銀行で12年間サイバーセキュリティに従事し、2022年4月にフリーランスとして独立。現在はサイバーセキュリティに関するコンサルティングやアドバイザー業務を行うとともに、国土交通省最高セキュリティアドバイザーや日本シーサート協議会専門委員、⾦融ISAC個⼈賛助会員として活動している。