サプライチェーン攻撃とは何か

ソフトウェアサプライチェーン攻撃とは、ソフトウェアの開発・配布プロセスの中で、第三者のコンポーネントやツールを経由して悪意のあるコードを混入させる攻撃手法です。近年、SolarWinds事件やLog4Shell脆弱性をはじめ、大規模なインシデントが相次いで発生し、業界全体でその対策の重要性が認識されるようになりました。

現代のソフトウェア開発では、OSSライブラリへの依存が当たり前になっています。あるプロジェクトが直接依存するライブラリが数十程度であっても、推移的依存関係を含めると数百から数千のパッケージに依存しているケースは珍しくありません。この複雑な依存関係の中に一つでも脆弱性や悪意あるコードが紛れ込めば、大きな被害につながるのです。

SBOM（Software Bill of Materials）とは

SBOMは、ソフトウェアを構成する全てのコンポーネントの一覧を記述したドキュメントです。製造業における部品表（BOM）をソフトウェアに適用した概念であり、「このソフトウェアは何で作られているか」を明確にするものです。

SBOMに含まれる情報

• コンポーネント名：使用しているライブラリやフレームワークの名称
• バージョン情報：各コンポーネントの正確なバージョン
• ライセンス情報：各コンポーネントのライセンス種別
• 依存関係：コンポーネント間の依存関係のグラフ
• サプライヤー情報：コンポーネントの提供元
• ハッシュ値：コンポーネントの整合性を検証するためのダイジェスト

SBOMを整備することで、新たな脆弱性が発見された際に「自社のソフトウェアが影響を受けるかどうか」を迅速に判断できるようになります。Log4Shellの際に多くの組織が「自社でLog4jを使っているかすら把握できません」状況に陥ったことは記憶に新しいでしょう。

SBOMの主要なフォーマット

SBOMのフォーマットには主に2つの国際標準があります。

SPDX（Software Package Data Exchange）

Linux Foundationが策定したフォーマットで、ISO/IEC 5962として国際標準化されています。ライセンスコンプライアンスにルーツを持ち、ライセンス情報の表現が充実しています。JSON、YAML、RDF、Tag-Valueなど複数の出力形式をサポートしている点も特徴です。

CycloneDX

OWASPが策定したフォーマットで、セキュリティの観点から設計されています。脆弱性情報との紐付けが容易であり、VEX（Vulnerability Exploitability eXchange）との統合が進んでいます。JSON形式とXML形式をサポートし、軽量で扱いやすい設計が特徴です。

どちらのフォーマットを選ぶかは組織の要件次第ですが、セキュリティ重視であればCycloneDX、ライセンスコンプライアンス重視であればSPDXが適しています。実務的には、両方の形式に対応したツールが増えているため、あまり選択に悩む必要はなくなりつつあります。

SBOM生成ツールの選定

SBOMの生成を自動化するツールは多数存在します。代表的なものを紹介します。

• Syft（Anchore）：コンテナイメージやファイルシステムからSBOMを生成。CycloneDXとSPDXの両方に対応しており、CI/CDパイプラインへの組み込みが容易
• Trivy（Aqua Security）：脆弱性スキャナーとして有名だが、SBOM生成機能も備える。一つのツールでスキャンとSBOM生成を同時にこなせる利点がある
• cdxgen：CycloneDX形式のSBOM生成に特化したツール。多数のプログラミング言語とパッケージマネージャーに対応
• GitHub Dependency Graph：GitHubのネイティブ機能として依存関係の可視化とSBOMエクスポートが可能

私の経験では、まずSyftで始めるのが最もバランスが良いと感じています。対応範囲が広く、出力形式の柔軟性も高いため、後から要件が変わっても対応しやすいです。

CI/CDパイプラインへの統合

SBOMは一度生成して終わりではなく、ソフトウェアのリリースサイクルに組み込んで継続的に更新する必要があります。以下のようなタイミングでSBOMを生成・更新するのが理想的です。

1. ビルド時：CIパイプラインの一環としてSBOMを自動生成する
2. コンテナイメージ作成時：コンテナレジストリへのプッシュ時にSBOMを添付する
3. リリース時：リリースアーティファクトと共にSBOMを成果物として保管する
4. 定期スキャン：新たな脆弱性が公開された際に、既存のSBOMと照合して影響を評価する

重要なのは、SBOMの生成を開発者に意識させないことです。手動での作成は現実的ではなく、自動化されていなければ確実に形骸化します。

脆弱性管理との連携

SBOMの真の価値は、脆弱性管理と組み合わせた時に発揮されます。SBOMで管理されたコンポーネント一覧を脆弱性データベース（NVD、OSV、GitHub Advisory Database等）と照合することで、影響範囲を即座に特定できます。

さらに、VEX（Vulnerability Exploitability eXchange）を活用することで、「脆弱性は存在するが、当該コンポーネントの使い方では悪用不可能」といった判断結果を記録し、不要なアラートを抑制することも可能です。これは実務上非常に重要で、全ての脆弱性に同じ優先度で対応するのは現実的ではないからです。

導入のロードマップ

SBOMの導入は段階的に進めるのが成功のコツです。

• フェーズ1：まず主要プロジェクトでSBOM生成を自動化し、可視化します。この段階では出力を確認するだけでも十分な効果がある
• フェーズ2：脆弱性スキャンと連携し、新規脆弱性の影響評価を自動化します。アラートの仕組みを構築する
• フェーズ3：ライセンスコンプライアンスチェックを追加し、ポリシー違反を検出します。承認ワークフローを整備する
• フェーズ4：サプライヤーへのSBOM提供要求と、受領したSBOMの管理体制を整備する

全てを一度に導入しようとすると失敗します。まずは可視化から始めて、組織の成熟度に合わせて段階的に高度化していくことをお勧めします。ソフトウェアの透明性を高めることは、セキュリティの基盤を固めることに直結します。