特権昇格の脆弱性

特権昇格の脆弱性 CI/CD pipelines

ほとんどのチームは、特権昇格の脆弱性をカーネルのバグまたは悪用された sudo 本番サーバー上。2026年には、より危険なバージョンが別の場所に存在します。 pipeline コードをビルドして出荷します。 CI/CD このジョブは、リポジトリへの書き込みアクセス権、パッケージレジストリのトークン、クラウドの認証情報を日常的に保持しています。このジョブ内でコードを実行できる攻撃者は、それほど権限を昇格させる必要はありません。 pipeline すでに彼らのためにやってくれた。

このガイドでは、特権昇格の脆弱性がどのようなものかを説明します。 CI/CD pipelineとコンテナについて解説し、攻撃者がよく使う経路を順を追って説明し、それぞれの経路を閉じる方法を示します。

TL;DR: 特権昇格の脆弱性 CI/CD pipelines

で pipeline攻撃者は権限昇格を必要としない場合が多い。 pipeline 既に持っている。 特権昇格の脆弱性 CI/CD これは通常、ジョブに必要な範囲よりも広い権限を設定し、その内部で信頼できないコードが実行されることを待機させるものです。

  • Pipelineは意図的に特権を与えられている。 彼らはソースコードを読み、機密情報を保持し、成果物を公開し、本番環境にデプロイするため、組織内で最も価値のあるエスカレーション対象の1つとなります。
  • ほとんどの権限昇格経路は、脆弱性を悪用したものではなく、設定ミスによるものです。 広範なデフォルトトークン、 pull_request_target フォークコードを実行するワークフローや、長期にわたって有効なクラウドキーは、あらゆるゼロデイ攻撃よりも大きな損害をもたらす。
  • コンテナの権限昇格により、1つのジョブがランナー全体に変わってしまう。 特権コンテナ、rootユーザー、マウントされたDockerソケットによって、ビルドコンテナは境界ではなく、入り口となる。
  • それは既に大規模に起こっている。 CHAINDROPワームは、GitHub Actionsランナーの管理者権限を利用して、ランナーのメモリから直接認証情報を読み取りました。
  • 解決策は、最小権限の原則を継続的に適用することである。 すべてのトークンの範囲を定め、すべてのコンテナを強化し、攻撃者が発見する前に権限の逸脱を検出します。

脆弱性とは何ですか?

特権昇格の脆弱性とは、ユーザー、プロセス、またはコードの一部が本来持つべき権限を超えて権限を取得できるあらゆる弱点のことです。MITRE ATT&CK はこれを独自の戦術として追跡しています。 TA0004: 権限昇格なぜなら、それは小さな足がかりを真の損害へと変える一歩だからだ。

古典的な形式は2つあります。

  • 垂直方向のエスカレーション: 例えば、一般ユーザーからrootユーザーへ、あるいは読み取り専用トークンから書き込み可能なトークンへと権限を昇格させる場合など。
  • 水平的エスカレーション: 例えば、あるジョブのアクセス権を利用して、別のチームのリポジトリ、シークレット、または環境にアクセスするなど、横方向への移動を行うこと。

攻撃者は、ソフトウェアのバグ、設定ミス、過剰な権限という3種類の脆弱性を通じて、権限昇格の脆弱性を悪用します。サーバーでは、バグが最も注目されます。 CI/CD pipeline設定ミスや過剰な権限設定が、ほとんどすべての作業を実行します。

なぜそれがそんなに危険なのか CI/CD pipelines

A pipeline これは単なる構築ツールではありません。社内で最も広範なアクセス権限を持つ自動化されたIDです。典型的なジョブは次のようになります。

  • ソースコードを確認して修正する
  • 環境変数、保管庫、クラウドメタデータサービスからシークレットを読み取る
  • パッケージ、イメージ、リリース成果物を公開する
  • ステージング環境と本番環境にデプロイする

その OWASPトップ10 CI/CD セキュリティリスク この問題を直接的に指摘する。そのリスク CICD-SEC-5: 不十分 Pipeline-ベースのアクセス制御 攻撃者が悪意のあるコードを実行する方法を説明します pipeline 横方向、内部、または外部に移動するために与えられた権限を悪用する CI/CD システム。

これは理論上の話ではない。2026年8月のCHAINDROPキャンペーン中、マルウェアは GitHub Actionsランナーのメモリから一時的な認証情報を抽出しました そして盗まれた公開トークンを使用してさらに多くのパッケージを感染させた。Linux ランナーでは、ペイロードは sudo を介してコレクターを実行しました ランナープロセスのメモリを読み取る。これは特権昇格である。 CI/CD pipeline最も純粋な形でのs:毒された依存、ランナーへの高度なアクセス、そして仕事が触れる可能性のあるすべての秘密。これは、毎週の調査結果で見られるパターンと同じです。 悪意のあるnpmパッケージ.

特権昇格の脆弱性はどこに隠れているのか pipeline?

よくある6つの攻撃経路、それぞれの経路が攻撃者にもたらす可能性、そしてそれらを阻止する手段。

エスカレーションパスそれがどのように起こるか攻撃者が得るもの閉じ方
恵まれすぎている pipeline トークンワークフローは、デフォルトのトークンスコープが広く実行されるため、 permissions ブロックが設定されていますコード、リリース、その他のワークフローへの書き込みアクセス権読み取り専用のデフォルト設定を行い、必要な場合にのみジョブごとに書き込みアクセス権を付与する
中毒 pipeline 実行pull_request_target または同様のトリガーが信頼できないフォークからコードをチェックアウトして実行しますリポジトリのシークレットと書き込みトークンを単一の pull request特権コンテキストでフォークコードを実行しないでください。信頼できるジョブと信頼できないジョブを分離してください。
コンテナ権限の昇格ビルドコンテナは、root権限で、特権モードで、またはDockerソケットをマウントした状態で実行されます。ランナーホスト上でのroot権限と、そのホストが実行するすべてのジョブへのアクセス権非rootユーザーとして実行し、コンテナ仕様で権限を削除し、権限昇格をブロックする
長期有効なクラウド認証情報静的クラウドキーは、シークレットまたは環境変数として保存されます。ジョブ終了後もクラウドアカウントへの永続的なアクセスが可能有効期限の短い連邦認証情報を使用し、 公開された秘密情報を自動的に取り消す
継続的に自己ホストするランナーランナーは再構築されることなく、ジョブやリポジトリ間で再利用されます。粘り強さ、そして他チームのビルドを妨害する能力一時的なランナーを使用し、信頼レベルごとにそれらを分離する
特権階級の人間アカウント非アクティブな管理者、外部協力者、未確認の権限変更が積み重なる変更可能な有効なアカウント pipelinesと分岐の保護アクセス状況を継続的に監視し、異常な権限変更があった場合は警告を発する。

コンテナ権限昇格:ビルドコンテナが境界ではない場合

コンテナは隔離されたような感覚を与えるため、チームはしばしばそれをセキュリティ境界として扱います。 CI/CDしかし、それらは必ずしも一つではありません。コンテナの権限昇格は、ビルドコンテナ内のコードがホストの制御権を取得し、それによってそこで実行される他のすべてのジョブの制御権も取得したときに発生します。

ほとんどのケースは、以下の3つの設定で説明できます。

  1. root権限で実行しています。 コンテナ内のプロセスがルート権限を持っている場合、いかなる脱出も可能な限り最も強力な立場から開始される。
  2. 特権モード。 特権コンテナは、その上で直接実行されるプロセスとほぼ同じようにホストへのアクセス権を持つ。
  3. マウントされたDockerソケット。 取り付け /var/run/docker.sock ジョブに組み込むことで、イメージを効率的に構築できるようになります。また、ホスト上でジョブのルート権限を渡すことで、新しい特権コンテナを起動できるようになります。

セキュリティ研究者たちは、これが実際の CI システムでどのように展開されるかを示しました。よく文書化されたあるケースでは、研究者たちは CI コンテナ内で実行されているビルド スクリプトから Cloudflare Pagesのビルドホストにおけるフルコンテナエスケープ、前cisなぜなら、コンテナがセキュリティ境界として扱われていたからです。

強化されたKubernetesジョブ仕様は次のようになります。重要な設定は allowPrivilegeEscalation: false、その プロセスが親プロセスよりも多くの権限を取得することを防ぐ例えば、setuidバイナリを介して。

ci-build-pod.yamlKubernetes
# 強化されたビルドポッド:最も一般的なコンテナ権限昇格経路をブロックします
APIバージョン: v1
種類: ポッド
 :
  名: ci-build
当社は、シームレスなサービスと一流の旅行商品を専門としており、限界を押し広げ、常に時代の先を行くことでお客様に最高の体験を提供することに全力で取り組んでいます。:
  セキュリティコンテキスト:
    非ルートとして実行: true
    runAsUser: 10001
    seccompProfile:
      type: ランタイムデフォルト
  コンテナ: - 名: ビルド
      画像: registry.example.com/build-image@sha256:
      セキュリティコンテキスト:
        権限昇格を許可する: false
        特権を持つ: false
        読み取り専用ルートファイルシステム: true
        機能:				

同じ原則はDockerfile自体にも適用されます。非rootユーザーを追加し、エントリポイントの前にそのユーザーに切り替えるようにしてください。

ドッカーファイルデッカー
# コンテナを非ルートユーザーとして実行する
FROM node:22-スリム
RUN useradd --uid 10001 --create-home ビルダー
作業ディレクトリ /アプリ
COPY --chown=ビルダー:ビルダー 。 。
USER ビルダー
CMD ["ノード", "index.js"]
なぜ重要なのか: 無し USER この指示に従うと、コンテナはroot権限で実行されます。エントリポイントの前に専用ユーザーに切り替えることで、侵害されたプロセスは可能な限り最小限の権限で開始されます。

Kubernetes のドキュメント セキュリティコンテキストの設定 本書では、これらの設定をそれぞれ詳細に解説しています。

GitHub Actions:見過ごされがちな権限昇格の脆弱性

GitHub Actions は、多くのチームが最初に特権昇格に遭遇する場所です。 CI/CD pipelineなぜなら、危険なパターンは見た目には全く普通に見えるからです。今日では、すべてのリポジトリでチェックする価値のあるものが2つあります。

トークンのスコープ。 すべてのワークフローには GITHUB_TOKENGitHub独自のガイダンス 自動トークン認証 明確に言えることは、明示的にトークンを渡さなくてもアクションはそのトークンに到達できるため、常にその権限を最小限に制限する必要があるということです。ワークフローの最上位で読み取り専用権限を設定し、ジョブごとに書き込みアクセスを許可することで、最も一般的な権限昇格経路を一度に排除できます。

.github/workflows/build.ymlGitHubアクション
名: ビルド
on:[プッシュ]

# すべてのジョブのデフォルト: 読み取り専用
パーミッション:
  中身: read

jobs:
  test:
    連続する: Ubuntu最新版
    ステップ:
      # サードパーティのアクションを完全な commit SHAは変更不可能なタグです
      - 使用されます: アクション/チェックアウト@commit-sha>
      - ラン: npm ci && npm test

  リリース:
    ニーズ: test
    連続する: Ubuntu最新版
    # このジョブだけが書き込み可能で、必要なものだけを書き込むことができる
    パーミッション:
      中身: 書きます
    ステップ: - 使用されます: アクション/チェックアウト@commit-sha>
      - ラン: ./scripts/release.sh
なぜ重要なのか: すべてのジョブは読み取り専用で開始され、書き込み権限を持つのはリリースジョブのみです。テストジョブ内の依存関係が侵害された場合、そのジョブがアクセスできるトークンはリポジトリへの書き込み権限を持ちません。

信頼できないトリガー。 ワークフローは以下によってトリガーされます pull_request_target ターゲットリポジトリのシークレットと書き込み可能なトークンを使用して実行します。 pull request これはフォークから来ています。そのワークフローがフォークのコードをチェックアウトして実行する場合、誰でも開くことができます pull request そして、あなたの権限でコードを実行します。これは、エクスプロイトを全く必要としない権限昇格の脆弱性です。 pull request特権ステップは信頼できるコード上で実行し、信頼できないコードは秘密情報を使用せずに別のワークフローで実行します。

これらのパターンを安全な場所で見たい場合は、 キシゲニヤギ リポジトリは意図的に安全でない情報を収集します pipeline (NAIST) と IaC トレーニングの設定。GitHub の設定に関するより詳細なレビューについては、次のガイドを参照してください。 GitHubアプリやリポジトリが安全かどうかを知る方法.

特権昇格の脆弱性を防ぐ方法 CI/CD pipelines

特権昇格の終了 CI/CD pipeline要するに、最小権限の原則をすべての階層に適用し、一度だけでなく継続的にチェックするという原則です。実用的なチェックリストは以下のとおりです。

  1. すべてのトークンをスコープする。 デフォルトでは読み取り専用、書き込みアクセスはジョブごと、リポジトリワークフローでは組織全体のトークンは使用不可。
  2. 信頼できるコードと信頼できないコードを分離する。 機密情報を含むジョブでは、フォークや外部コントリビューターのコードを実行しないでください。
  3. すべてのビルドコンテナを強化してください。 非ルートユーザー、特権モードなし、Dockerソケットなし、機能削除、 allowPrivilegeEscalation: false.
  4. 長年守られてきた秘密を置き換える。 有効期限の短い連邦認証情報を優先し、漏洩した認証情報は直ちに失効させる。
  5. 自分が走っているものをピン留めしてください。 参照するサードパーティのアクションと画像 commit SHAまたはダイジェストを使用するため、侵害されたタグは変更できません。 pipeline.
  6. ドリフトに注意してください。 権限は時間とともに拡大します。新しい管理者、弱体化したブランチ保護、予期しないワークフローの変更について警告します。
  7. ゲート pipeline. 重大な設定ミスが発生した場合は、マージする前にビルドを失敗させる。

難しいのはこれらのルールを知ることではない。難しいのは、日々変化する何百ものリポジトリとワークフロー全体にこれらのルールを適用することだ。

Xygeni はどのようにして特権昇格の脆弱性を阻止するのですか? CI/CD?

各エスカレーション経路は、それを検知または阻止するXygeniの機能と対応付けられています。

リスクXygeniが行うこと
Pipeline 誤設定設定ミス検出器 GitHub、GitLab、Azure DevOps、Bitbucket、CircleCI、Jenkins 全体にわたる CI ジョブ定義、ビルドスクリプト、構成ファイルをスキャンし、ベストプラクティスで許可されている範囲を超える権限をフラグ付けします。
コンテナ権限の昇格IaC コンテナ検査 Dockerfile、docker-composeファイル、Kubernetesマニフェスト、Helmチャート、およびroot権限で実行されるコンテナを網羅します。
特権を過剰に享受している非アクティブなユーザー最小権限分析は、非アクティブなユーザーと過剰な権限を持つユーザーを特定し、 Health Check 発見したものをチケットに変える
権限ドリフト異常な権限変更、異常なマージ、予期しないプラグインのインストールに関する異常検知アラート
認証情報が漏洩しました秘密検出はコードを対象としています。 pipelinesとコンテナイメージ、サポートされているシークレットタイプの自動失効機能付き
悪意のあるコード pipelineリバースシェルとマルウェアのダウンロードをブロックします pipelineMEWはリアルタイムで悪意のあるパッケージを検出し、署名が存在する前に悪意のあるパッケージを検出します。
執行Pre-commit hooks およびCI guardrails 重大な問題が発生した場合にビルドを失敗させ、独自のルールをカスタム YAML ポリシーで適用します。

チェックは以下に準拠します OWASPトップ10 CI/CD セキュリティリスク (NAIST) と standardなどの CISNIST、および OpenSSFすべての発見は Xygeni ASPMコード、依存関係、および機密情報の発見と並んで優先順位が付けられるため、実際に本番環境に影響を与える権限昇格の脆弱性が最初に修正されます。

ほとんどの特権の拡大は CI/CD pipelinesは既にワークフローファイル内に存在し、信頼できないコードの実行を待っています。 

FAQ

特権昇格の脆弱性とは何ですか CI/CD?

実行中のコードが pipeline ジョブに必要な以上のアクセス権限を取得すること。例えば、過剰な権限を持つトークン、秘密情報を含む信頼できないコードを実行するワークフロー、ホストにアクセスできるビルドコンテナなど。

コンテナ権限昇格とは何ですか?

コンテナ権限昇格とは、コンテナ内のプロセスがより高い権限(多くの場合、ホスト上でroot権限)を取得することです。一般的な原因としては、root権限での実行、特権モード、マウントされたDockerソケットなどが挙げられます。

か allowPrivilegeEscalation: false コンテナの脱出を阻止しますか?

これは、例えばsetuidバイナリなどを通じて、プロセスが親プロセスよりも多くの権限を取得するという重要な経路を遮断します。非rootユーザー、権限の放棄、および特権モードの無効化と組み合わせることで、最も効果を発揮します。

Is pull_request_target 常に危険?

それ自体ではそうではありません。ワークフローがコードをチェックアウトして実行すると、特権昇格の脆弱性になります。 pull requestなぜなら、そのコードはあなたの秘密情報と書き込み可能なトークンを使って実行されるからです。

複数のリポジトリにわたる権限昇格の経路を見つけるにはどうすればよいですか?

手動レビューは拡張性に欠ける。自動化された CI/CD セキュリティツールは、すべてのワークフロー、コンテナ仕様、および権限セットを継続的にスキャンし、何らかの異常が発生した場合に警告を発します。

sca-tools-ソフトウェア構成分析ツール
ソフトウェアのリスクを優先順位付けし、修復し、保護する
無料アカウントを作成しましょう。
いいえ、クレジットカードは必要ありません。

ソフトウェア開発と配信を安全に

Xygeni製品スイートと共に