SBOMで依存関係の可視性を確保する: Log4Shellが残した教訓

はじめに

供給チェーン攻撃シリーズでは、cooldownは「新しく公開された悪意あるバージョンを受け取らない」という時間ベースの防御であることを解説しました。しかし供給チェーンセキュリティには、その前段階の問いがあります。

新しい脆弱性が公開されたとき、私たちのプロジェクトは影響を受けるか?

この問いに即答できなければ、どれだけ精巧な防御を整えていても、インシデント発生時の対応速度が決定的に遅くなります。この記事では、その問題を解決する**SBOM（Software Bill of Materials）**とGitHubによる自動化の方法を解説します。

どんなリスクがあるか: 「私たちは影響を受けるか?」に答えられない

現代のフロントエンドプロジェクトは数百〜数千個の依存関係を取り込みます。package.jsonに直接記載した依存関係が50個だとすると、それらが引き込む間接依存関係（transitive dependency）まで合わせると1,000個を超えることも珍しくありません。

この状況で新しいCVEが公開されると、次のようなことが起きます。

セキュリティニュースに[有名ライブラリ] CVE-XXXX-XXXXX発見というヘッドラインが出る
チームで「私たちも影響を受けるか?」という問いが始まる
開発者がpackage.json・yarn.lock・pnpm-lock.yamlを掘り起こし、ライブラリ名をgrepで検索する
直接依存関係にはないが間接依存関係として入り込んでいないかをさらに確認する
影響を受けるアプリ・サービスが特定されて初めてパッチ作業が始まる

このプロセスが速ければ1〜2時間、遅ければ数日かかります。そしてその時間の間、すでに私たちのシステムが攻撃されている可能性があります。

Log4Shellが示した可視性不足の代償

2021年12月に公開されたLog4Shell（CVE-2021-44228）は、Apache Log4jの任意コード実行の脆弱性でした。CVSSスコア10点、事実上すべてのJavaアプリケーションが直接・間接的に影響を受けていました。

このインシデントが世界中のセキュリティチームに残した最大の教訓は、脆弱性そのものではなく、**「私たちの組織のどこにLog4jがあるか、誰も分からない」**という事実でした。

直接依存関係として記載したことはなくても、別のライブラリが依存しているために入り込んでいるケース
ビルドされたJARファイルの中にfat jarとして含まれており、コード検索では見えないケース
古いサービスの依存関係ツリーを誰も最新の状態で把握していないケース

CISAの公式アドバイザリでも、最初に求められる行動として明記されているのは_「Log4jの使用状況を特定する（Identify the use of Log4j）」_でした。パッチより先に特定が来ていたのです。

米国政府はこのインシデント直後にExecutive Order 14028を通じて、連邦政府にソフトウェアを納品するすべてのサプライヤーにSBOMの提出を義務化しました（CISAのSBOMポリシーページ）。可視性自体がセキュリティの前提条件であることが政策として確認された瞬間です。

SBOMとは何か

SBOM（Software Bill of Materials）は文字通り**「ソフトウェア部品表」**です。どのライブラリが、どのバージョンで、どのような依存関係として私たちのビルド成果物に入り込んでいるかを、機械が読み取れる形式で記録したものです。

SBOMがあれば、先の5ステップが次のように変わります。

セキュリティニュースにCVEが出る
SBOMとCVEデータベースをマッチングする（自動）
影響を受けるシステムの一覧が即座に出力される
その一覧に従ってパッチを始める

「私たちは影響を受けるか?」への答えが、人の時間ではなくコンピューターの時間で出ます。

代表的なSBOM標準は2つです。

CycloneDX: OWASPが主導する形式。JSON・XMLの両方をサポート
SPDX: Linux Foundationが主導する形式。ISO/IEC 5962標準

どちらを使ってもツールはほぼ同じで、重要なのは「SBOMを定期的に作成・管理すること」自体です。

どのように適用するか

SBOMと聞くと別途ツール・ワークフローが必要だと思いがちですが、GitHub上で作業しているなら最も重要な部分はすでに自動で動いている可能性が高いです。導入を2つの層に分けて考えると正確です。

基本: GitHub Dependency Graphは自動稼働中

GitHubはリポジトリにpackage.json/yarn.lock/pubspec.yaml/Gemfile/pom.xmlのような標準マニフェストファイルがあれば、別途設定なしに自動でDependency Graphを生成します。このグラフがGitHub Advisory DatabaseとマッチングされてDependabot Alertが機能します。

確認場所は次のとおりです。

**Settings → Security → “Dependency graph”**が有効になっているか（デフォルトで有効）
**Securityタブ → “Dependabot alerts”**で既知のCVEマッチングの通知を受信

この2つが正常に動作していれば — npm・pub・gradleなどGitHubがサポートする主要エコシステムであればほぼ確実に — 新CVE公開後すぐに影響を受ける依存関係に対してDependabot Alertが自動で表示されるはずです。

結論として、日常的な供給チェーンの可視性・CVE検知が目的であれば、追加のワークフローは必要ありません。

この記事の冒頭で取り上げた「Log4Shellが出たとき、私たちが影響を受けるかどうかを即答する」という最大の実用的な価値は、GitHubユーザーにはすでに無料で提供されています。

追加: 標準SBOMファイルが必要な場合

次のシナリオではSPDXまたはCycloneDX形式のSBOMファイルを別途生成する必要があります。

政府・金融などのコンプライアンス要件でSBOM提出が義務づけられている場合
顧客・監査人にSBOMをリリースartifactとして添付しなければならない場合
Trivy・Grype・Snyk Containerのような外部分析ツールにSBOMをパイプラインで渡す場合
ビルド成果物のvendoredライブラリ・native binaryなどGitHubが自動認識しない領域まで追跡しなければならない場合

このような要件がある場合に限り、ワークフローを1つ追加します。

# .github/workflows/sbom.yml
name: SBOM
on:
  release:
    types: [published] # リリース時点でartifactとして添付
  workflow_dispatch:

permissions:
  contents: write

jobs:
  generate-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<SHA> # v6
      - uses: actions/setup-node@<SHA> # v6
      - run: corepack enable && yarn install --immutable
      - uses: advanced-security/sbom-action@<SHA>
        with:
          path: ./

advanced-security/sbom-actionの他にAnchoreのsbom-action、CycloneDXのGitHub Actionなど選択肢が豊富です。どのツールを使っても出力はSPDX/CycloneDX標準形式なので外部ツールと互換性があります。

効果のまとめ

目的	必要な作業
GitHubでDependabot Alertを受け取る	自動（別途設定不要）
依存関係ツリーのインベントリを確保する	自動（別途設定不要）
外部コンプライアンス用SBOMファイルの添付	`sbom-action`ワークフローが必要
外部分析ツール（Trivyなど）へのSBOMパイプライン	`sbom-action`ワークフローが必要

限界

SBOMは可視性ツールであり、防御ツールではありません。次の点に注意が必要です。

SBOMがあっても人が確認しなければ意味がありません。DependabotアラートチャネルをSlackなどに接続するフォローアップ（/github subscribe <ORG>/<REPO> vulnerability_alerts）が必要です。
SBOMはビルド時点のスナップショットです。その後に依存関係が変われば再生成が必要です（そのため定期的なcronが推奨されます）。
SBOMがすべての出所を捕捉するわけではありません。CDN経由でロードされる外部スクリプト（例: Google Fonts）はSBOMに含まれません。この部分はSRIのような別のツールで補います。