サプライチェーン攻撃の脅威と対策
この記事は約 6 分で読めます
サプライチェーン攻撃は、ソフトウェアの開発・配布プロセスに潜む信頼関係を悪用し、 正規のアップデートやライブラリを経由してマルウェアを配布する攻撃手法です。 Sonatype の 2024 年レポートによると、オープンソースのサプライチェーン攻撃は 前年比で 156% 増加し、累計で 70 万件以上の悪意あるパッケージが確認されています。 従来のマルウェア対策では検知が困難なこの脅威は、開発者だけでなく ソフトウェアを利用するすべてのユーザーに影響を及ぼします。 本記事では、サプライチェーン攻撃の仕組みから組織・個人の防御策まで、 具体的な事例とデータを交えて解説します。
サプライチェーン攻撃の仕組み
SolarWinds 事件に学ぶ攻撃の全体像
2020 年に発覚した SolarWinds 事件は、サプライチェーン攻撃の深刻さを 世界に知らしめた象徴的な事例です。攻撃者は SolarWinds 社の ビルドシステムに侵入し、ネットワーク監視ソフト Orion の正規アップデートに バックドア (SUNBURST) を埋め込みました。このアップデートは 約 18,000 の組織にインストールされ、米国政府機関を含む 約 100 の組織が実際に侵害を受けました。 攻撃者はビルドパイプラインの一部を改ざんしただけで、 ソースコードリポジトリには痕跡を残さなかったため、 コードレビューでは発見できませんでした。 この事件は、ソフトウェアの「信頼の連鎖」が一箇所でも破られると、 下流のすべてのユーザーが影響を受けるという構造的な脆弱性を浮き彫りにしました。
npm / PyPI の依存関係汚染
パッケージレジストリを標的とした攻撃は、より身近で頻発する脅威です。 npm では 2021 年に ua-parser-js (週間ダウンロード数 800 万以上) の メンテナーアカウントが乗っ取られ、暗号通貨マイナーを含む 悪意あるバージョンが公開されました。 PyPI では 2023 年に約 450 件のタイポスクワッティングパッケージが発見され、 正規パッケージ名の誤入力を狙って情報窃取コードが配布されていました。
依存関係汚染の手口は主に 3 つに分類されます。 第一に、メンテナーアカウントの乗っ取りによる正規パッケージの改ざん。 第二に、タイポスクワッティング (例: lodash から lodahs) による偽パッケージの公開。 第三に、依存関係の混乱 (Dependency Confusion) を利用し、 内部パッケージと同名のパッケージを公開レジストリに登録する手法です。 2021 年にセキュリティ研究者 Alex Birsan が Dependency Confusion を実証した際、 Apple、Microsoft、PayPal を含む 35 以上の企業のビルドシステムで コード実行に成功しています。
CI/CD パイプラインへの侵入
CI/CD パイプラインは、コードのビルド・テスト・デプロイを自動化する 開発インフラですが、攻撃者にとっては高価値の標的です。 2022 年の Codecov 事件では、CI ツールの Bash Uploader スクリプトが改ざんされ、 利用者の環境変数 (API キー、トークン、認証情報) が外部に送信されました。 GitHub Actions のサードパーティアクションが侵害されるケースも報告されており、 2024 年には人気アクション tj-actions/changed-files が改ざんされ、 約 23,000 のリポジトリに影響が及びました。 CI/CD パイプラインは本番環境へのデプロイ権限を持つため、 ここが侵害されると攻撃者は本番環境に直接アクセスできる点が特に危険です。
開発者アカウントの保護
パッケージレジストリのアカウント
npm、PyPI、RubyGems などのパッケージレジストリのアカウントは、 サプライチェーン攻撃の起点として最も狙われやすい標的です。 npm は 2022 年から上位 500 パッケージのメンテナーに二段階認証を義務化しましたが、 それ以外のパッケージでは依然として任意です。 パスつく.com で 20 文字以上のランダムなパスワードを生成し、 TOTP アプリまたはハードウェアセキュリティキーによる二段階認証を 必ず設定してください。SMS 認証は SIM スワップ攻撃のリスクがあるため推奨しません。
パッケージの公開権限を持つアカウントは特に厳重に管理する必要があります。 npm の場合、`npm access` コマンドで公開権限を持つユーザーを確認し、 不要な権限は速やかに削除してください。 チームで管理する場合は、公開権限を持つメンバーを最小限に絞り、 公開操作には必ず二段階認証を要求する設定にします。
ソースコードリポジトリの保護
GitHub や GitLab のアカウントは、ソースコードだけでなく CI/CD パイプラインの設定やシークレットへのアクセス権も持つため、 侵害された場合の影響範囲が広大です。 GitHub の 2024 年セキュリティレポートによると、 漏洩したトークンやパスワードによるアカウント侵害が リポジトリ関連インシデントの約 40% を占めています。
リポジトリの保護には、パスつく.com で生成した強力なパスワードに加えて、 以下の設定が不可欠です。ブランチ保護ルールを設定し、 メインブランチへの直接プッシュを禁止すること。 プルリクエストに最低 1 名のレビュー承認を必須にすること。 署名付きコミットを要求し、コミットの改ざんを検知できるようにすること。
CI/CD サービスのセキュリティ
GitHub Actions、CircleCI、Jenkins などの CI/CD サービスには、 デプロイキー、API トークン、クラウドの認証情報など 機密性の高いシークレットが保存されています。 これらのシークレットが漏洩すると、本番環境への不正アクセスに直結します。 シークレットは必ず CI/CD サービスの暗号化されたシークレットストアに保存し、 ログに出力されないよう設定してください。 GitHub Actions の場合、`GITHUB_TOKEN` の権限を最小限に設定し、 `permissions` キーで必要な権限のみを明示的に指定することが重要です。
サードパーティの CI/CD アクションやプラグインを使用する際は、 バージョンをコミットハッシュで固定してください。 タグやブランチ名での指定は、タグの付け替えによる改ざんリスクがあります。 開発者アカウントの保護について体系的に学ぶには、開発者アカウント保護とレジストリセキュリティの解説書 (Amazon)が参考になります。
組織としての防御策
SBOM (ソフトウェア部品表) の活用
SBOM (Software Bill of Materials) は、ソフトウェアに含まれる すべてのコンポーネントとその依存関係を一覧化した文書です。 米国では 2021 年の大統領令 14028 により、 連邦政府に納入するソフトウェアに SBOM の提供が義務化されました。 SBOM を作成・管理することで、使用中のライブラリに脆弱性が発見された際に、 影響を受けるシステムを迅速に特定できます。
SBOM の標準フォーマットには SPDX (Linux Foundation) と CycloneDX (OWASP) の 2 つがあります。 npm では `npm sbom --sbom-format cyclonedx` コマンドで CycloneDX 形式の SBOM を生成できます。 生成した SBOM を定期的に脆弱性データベース (NVD、OSV) と照合し、 既知の脆弱性を含むコンポーネントを検出する運用が推奨されます。 ただし、SBOM は静的なスナップショットであるため、 ビルドごとに再生成し、最新の状態を維持する必要がある点に注意してください。
コード署名と検証
コード署名は、ソフトウェアの作成者と改ざんの有無を検証する仕組みです。 Sigstore プロジェクトは、オープンソースソフトウェアの署名を 無料で提供するインフラとして注目されています。 npm は 2023 年から Sigstore ベースの来歴情報 (provenance) をサポートし、 パッケージがどのリポジトリのどのコミットからビルドされたかを 暗号学的に検証できるようになりました。 `npm audit signatures` コマンドで、インストール済みパッケージの 署名を検証できます。
コンテナイメージの署名には cosign (Sigstore) が広く採用されています。 Docker Hub や GitHub Container Registry に公開するイメージに署名し、 デプロイ時に署名を検証することで、改ざんされたイメージの実行を防止できます。 Kubernetes 環境では、Kyverno や OPA Gatekeeper などの ポリシーエンジンと組み合わせて、署名のないイメージのデプロイを 自動的にブロックする運用が可能です。
最小権限の原則
サプライチェーン攻撃の被害を最小化するには、 各コンポーネントに必要最小限の権限のみを付与する原則が重要です。 CI/CD パイプラインのサービスアカウントには、 デプロイに必要な権限だけを付与し、管理者権限を与えないでください。 AWS の場合、IAM ポリシーで具体的なリソース ARN とアクションを指定し、 ワイルドカードの使用を避けます。
依存パッケージの権限も制限すべきです。 Node.js では、実行時にネットワークアクセスやファイルシステムアクセスを 制限する `--experimental-permission` フラグが v20 から利用可能です。 Deno はデフォルトでサンドボックス化されており、 ネットワークやファイルシステムへのアクセスには明示的な許可が必要です。 これらの仕組みを活用することで、仮に悪意あるパッケージが混入しても、 被害の範囲を限定できます。
個人ユーザーができる対策
サプライチェーン攻撃は開発者や組織だけの問題ではありません。 ソフトウェアを利用するすべてのユーザーが影響を受ける可能性があります。 個人ユーザーとして実践できる対策を以下にまとめます。
まず、OS やアプリケーションの自動更新を有効にしてください。 ただし、大規模なアップデートは公開直後に適用せず、 1〜2 日待ってから適用する慎重さも必要です。 過去には正規のアップデートに悪意あるコードが混入した事例があり、 公開直後に問題が発覚して修正版がリリースされるケースがあります。 重要なデータのバックアップを取ってからアップデートを適用する習慣をつけてください。
ブラウザ拡張機能やスマートフォンアプリは、 インストール数やレビュー数が少ないものを避け、 開発元の信頼性を確認してから導入してください。 Chrome Web Store では 2023 年に約 34,000 件の悪意ある拡張機能が 削除されており、公式ストアであっても安全とは限りません。 不要になった拡張機能やアプリは速やかに削除し、攻撃対象面を縮小してください。
パスつく.com で各サービスに固有の強力なパスワードを設定し、 二段階認証を有効化することは、サプライチェーン攻撃への間接的な防御にもなります。 攻撃者がサービス提供者のシステムに侵入してパスワードハッシュを窃取した場合でも、 十分な長さのランダムパスワードであればオフラインでの解読は極めて困難です。 パスつく.com の強度メーターで 100 ビット以上のエントロピーが表示される パスワードを設定してください。 サプライチェーン攻撃の全体像を理解するには、サプライチェーン攻撃の事例分析と防御戦略の書籍 (Amazon)が参考になります。
サプライチェーン攻撃は、ソフトウェアの信頼モデルそのものを揺るがす脅威です。 完全な防御は困難ですが、SBOM による可視化、コード署名による検証、 最小権限の徹底、そして個人レベルでのアカウント保護を組み合わせることで、 リスクを大幅に低減できます。 ソフトウェアの依存関係は目に見えにくいからこそ、 意識的に管理し、定期的に見直す姿勢が求められます。