IT用語集 2024/11/22

アップストリーム攻撃とは？ 10分でわかりやすく解説

コラム

アップストリーム攻撃は、ソフトウェアサプライチェーン攻撃のうち、開発、依存関係、ビルドなど上流側の工程を侵害し、下流の製品や利用者環境へ影響を広げる攻撃です。攻撃者は、ソースコード、OSSパッケージ、ビルド環境、署名鍵、CI/CDなどの信頼されている工程に悪意ある変更を混入させます。正規の開発・配布プロセスに紛れ込むため、利用者側では不正な変更を見分けにくく、被害範囲の特定にも時間がかかります。

アップストリーム攻撃とは

アップストリーム攻撃という語は、文脈によって指す範囲が変わります。この記事では、サプライチェーン攻撃の中でも、ソフトウェアの上流工程を狙う攻撃として扱います。対象になるのは、ソースコード管理、依存パッケージ、ビルド環境、リリース前の成果物、署名・検証の仕組みなどです。

重要なのは、攻撃者が最終利用者の端末を直接狙うとは限らない点です。上流側で悪意あるコードや設定を混入させると、その後のビルド、配布、更新の流れを通じて、多数の組織や利用者へ影響が及びます。利用者は正規のソフトウェアや更新として受け取るため、侵害の発見が遅れやすくなります。

ソフトウェアサプライチェーン内での位置づけ

ソフトウェアサプライチェーンは、企画、開発、依存関係の取得、ビルド、テスト、署名、配布、運用、更新までの一連の流れで構成されます。アップストリーム攻撃は、このうち主に開発からビルドまでの工程を狙います。

一方、更新配布基盤の侵害や正規アップデートの悪用は、厳密には配布・更新工程の侵害です。ただし、上流で混入した悪意ある変更が配布される経路にもなるため、ソフトウェアサプライチェーン全体の対策としてあわせて管理します。

狙われやすい工程と主な手口

アップストリーム攻撃では、単一の脆弱性だけでなく、開発者アカウント、依存パッケージ、ビルド設定、署名鍵、配布手順などが狙われます。代表的な対象は次の通りです。

ソースコード管理	リポジトリ、ブランチ、プルリクエスト、レビュー権限が侵害され、正規コードに悪意ある変更が混入します。小さな差分や設定変更に見せかけられると、レビューで見落とされる可能性があります。
依存関係	悪意あるOSSパッケージ、タイポスクワッティング、依存関係の置き換え、保守者アカウントの侵害などにより、開発者が意図しない部品を取り込む可能性があります。
ビルド環境	CI/CD、ビルドサーバー、ビルドスクリプト、コンテナイメージ、生成物の保管場所が侵害され、ソースコードが正しくても成果物に不正な変更が加えられる可能性があります。
署名・検証	署名鍵、証明書、検証手順、成果物の来歴情報が不適切に管理されると、改ざんされた成果物を正規のものとして扱うリスクがあります。
配布・更新	配布サーバー、パッケージレジストリ、更新機構が侵害されると、利用者が正規更新として不正な成果物を受け取る可能性があります。

アップストリーム攻撃で起きる影響

アップストリーム攻撃の影響は、侵害された開発元だけで完結しません。同じ成果物、同じライブラリ、同じ更新経路を使う組織へ連鎖する可能性があります。

機密情報や認証情報の流出

開発環境やビルド環境には、ソースコード、APIキー、アクセストークン、署名鍵、クラウド認証情報が置かれている場合があります。これらが盗まれると、攻撃者は追加のシステムへ侵入し、顧客情報や業務データを取得する可能性があります。

不正なコードやバックドアの混入

正規の成果物に不正なコードが混入すると、利用者は通常の更新やインストールとして受け取ってしまいます。その結果、情報窃取、遠隔操作、バックドア設置、ランサムウェアの配布などにつながる場合があります。

影響範囲の特定が遅れる

依存関係やビルド工程が複雑な場合、どの成果物に影響があるかを特定するだけで時間がかかります。特に、利用しているOSS、パッケージの取得元、ビルド時の依存関係、成果物の署名・来歴情報を管理していない場合、調査と復旧の負担が大きくなります。

取引先・利用者への説明負荷が高まる

ソフトウェアサプライチェーンに関わる事故では、自社が直接侵害された場合だけでなく、利用者や取引先への説明も必要になります。影響を受けたバージョン、確認手順、回避策、修正版の提供時期、再発防止策を整理して示せなければ、信頼回復に時間がかかります。

アップストリーム攻撃への対策

対策は、開発者の注意やコードレビューだけでは不十分です。開発、依存関係、ビルド、署名、配布、運用をつなげて管理し、どこで混入しても検知・追跡・遮断できる状態を作ります。

開発アカウントとリポジトリを保護する

開発者、管理者、CI/CD用アカウントに多要素認証を適用する
権限を最小限にし、管理者権限や共有アカウントを制限する
重要ブランチへの直接コミットを制限し、レビューと承認を必須にする
署名付きコミットや保護ブランチを利用し、変更者と変更理由を追跡できるようにする

依存関係を可視化する

利用しているOSS、ライブラリ、フレームワーク、コンテナイメージ、取得元、バージョン、ライセンス、更新履歴を管理します。依存関係を把握できなければ、脆弱性や不正パッケージが見つかったときに影響範囲を判断できません。

SBOMを整備すると、ソフトウェアを構成する部品を一覧化し、脆弱性対応や利用者への説明に使いやすくなります。ただし、SBOMは一覧であり、改ざんを自動的に防ぐ仕組みではありません。署名、検証、取得元の制御、ビルド来歴の確認と組み合わせて使います。

ビルド環境とCI/CDを堅牢化する

CI/CDは、開発から配布までを自動化するため、侵害された場合の影響が大きくなります。ビルド環境では、ジョブの権限、シークレットの保管、外部通信、ビルドスクリプトの変更、成果物の保管先を管理します。

ビルドジョブごとに必要最小限の権限を割り当てる
シークレットをコードやログに出さず、専用の管理機能で保護する
ビルドスクリプトと設定変更をレビュー対象に含める
成果物に署名し、配布前に検証する
再現可能なビルドや来歴情報の記録を検討する

取得元と更新ルートを固定する

依存パッケージやベースイメージは、信頼できる取得元から入手し、必要に応じて社内ミラーや承認済みレジストリを使います。バージョンを固定せずに取得すると、意図しない更新や置き換えを取り込む可能性があります。

更新は速さだけで判断しません。更新物の正当性、署名、ハッシュ、変更内容、テスト結果、ロールバック手順を確認し、重要システムでは段階的に適用します。

SSDFやSLSAの考え方を取り入れる

NIST SSDFやSLSAは、ソフトウェアサプライチェーンを守るための実践を整理する際の参考になります。SSDFは、安全なソフトウェア開発の実践を、組織、ソフトウェア保護、安全な開発、脆弱性対応の観点から整理します。SLSAは、成果物の来歴やビルドの信頼性を高め、ソースコードで確認した内容が配布されるバイナリにも反映されているかを扱いやすくします。

これらをそのまま形式的なチェックリストとして扱うのではなく、自社の開発形態、リスク、利用者への影響、運用負荷に合わせて採用範囲を決めます。DevSecOpsの実践として、開発、セキュリティ、運用が同じ情報を見ながら判断できる状態を作ることが重要です。