ソフトウェアサプライチェーンの盲点をなくす：SBoMによる可視化と防御の戦略

みなさんこんにちは。エーピーコミュニケーションズ ACS事業部の亀崎です。

2025年は、OSSパッケージのタイポスクワッティングをはじめソフトウェアサプライチェーンの脆弱性をつく攻撃がいくつか発生しました。

つい先日もGitHub社などから「Shai-Hulud」に関する対策が発表されています。

こうしたことから、私達ソフトウェア開発組織自身もソフトウェアサプライチェーンセキュリティを意識する必要性が高まっているのではないでしょうか。

ということで今回はあらためてソフトウェアサプライチェーンセキュリティやSBoMについてお伝えしようと思います。

なお、今回の内容はつぎのセッションの内容をNotebookLMで整理し、自分自身でまとめ直したものです。

現代のソフトウェア開発において、オープンソースソフトウェア（OSS）の利用は避けられませんが、それは同時にあらゆる側面からの攻撃にさらされていることを意味します。開発のスピードと安全性を両立させるためには、サプライチェーンの透明性を確保する「SBoM」の活用が不可欠です。

ソフトウェアの中・裏側では多くのサードパーティパッケージが動いており、そこには既知の脆弱性（CVE）や推移的なリスクが潜んでいます。

巧妙な攻撃手法:
有名なパッケージに似せた名前でマルウェアを配布するタイポスクワッティング （例：matに対するmatcなど）や、CI/CDパイプライン自体を侵害して悪意あるスクリプトを混入させる手法が確認されています。

AI生成コードの危うさ:
AIは学習データに基づきコードを生成するため、脆弱性が含まれる古い実装や、入力値検証の欠如を見逃すことがあります。また、AIが提案した「存在しないパッケージ名」を攻撃者が先回りして登録する、AIハルシネーションを悪用した攻撃にも注意が必要です。

実例に見る脅威: 実際に、デバイスへのAPIキーのハードコード（Rabbit R1）や、「Shai-Hulud」等のサプライチェーンの弱点を突いた深刻なインシデントが国内外で発生しています。

SBoMは、ソフトウェアに含まれるすべての構成要素を記録したリストです。これを持つことで、開発者は「自分が何を出荷しているのか」を正確に把握できます。

SBoMに含まれる内容主な内容

これらの情報を活用して以下のようなことが実現できます。

インシデント対応の迅速化: ベンダーやパッケージが侵害された際、SBoMがあれば自社への影響を即座に特定し、修正モジュールの適用や以前のバージョンへのロールバック、隔離などの対策を講じることができます。
コンプライアンス: 監査やリスク管理において適切な管理体制を示す重要な証拠となります。また、米国では連邦政府プロジェクトでのSBoMが義務付けられるなど、社会的に重要なプロジェクトなどSBoMの提供を求められるケースも増えています。

SBoMは作成するだけでなく、ライフサイクル全体で自動化・統合することが重要です。

生成の自動化: メジャーリリースの際や、メインブランチへコミットへされるたびに自動生成し、そのバージョンやコミットと紐付けて保存します。
「コード」と「コンテナ」の両面管理: アプリケーションの依存関係だけでなく、ベースOSのパッケージを含むコンテナイメージのSBoMも作成すべきです。脆弱性はOSのベースレイヤーに隠れていることが多いからです。
リアルタイムの脆弱性追跡: SBoMを生成しただけで満足せず、リリース後に出現した新たな脆弱性を毎日自動チェックする体制が推奨されます。
証明（Attestation）の活用: SBoMが「正しくビルド環境で生成されたこと」を証明するために、Sigstore（Cosign）や in-toto** を用いてデジタル署名を付与します。これにより、ビルドパイプラインの途中で成果物が改ざんされていないかを自動検証できるようになります。

4. 開発プロセス全体の硬化（Hardening）

SBoM以外の対策も組み合わせることで、より強固な防御が可能になります。

ソフトウェアサプライチェーンの防御において、「何を使っているかを知らない（盲目状態）」は最大の不備です。 SBoMをCI/CDパイプラインに組み込み、継続的なモニタリングを行うことで、目に見えない脅威を可視化し、迅速に対応できる体制を構築しましょう。

私たちもお手伝いさせていただきます。