デフォルトで危険：MITRE、Splunk、その他のオープンソースリポジトリで発見された安全でないGitHub Actions

デモを依頼
By 清水 孝郎 - JUNE 17, 2025
Topics: クラウド セキュリティ, 脅威リサーチ

SHARE:

本文の内容は、2025年6月17日にStefano Chierici が投稿したブログ(https://sysdig.com/blog/insecure-github-actions-found-in-mitre-splunk-and-other-open-source-repositories/)を元に日本語に翻訳・再構成した内容となっております。

Sysdig脅威リサーチチーム（TRT）は設立以来、世界をより安全で、より情報に富んだ場所にすることに尽力してきました。このコミットメントを貫くには、セキュリティ上の懸念事項を特定、修正し、コミュニティと共有することを目指し、現実世界の問題を積極的に調査する必要があります。 

Sysdig TRTは、主要なリポジトリとそのGitHub Actionsを対象に継続的インテグレーションと継続的デリバリー（CI/CD）のセキュリティ調査を実施した結果、安全でないワークフローを悪用した数十のオープンソースプロジェクトにアクセスし、その脆弱性を報告しました。Pwnリクエストなどのこれらの手法は長年にわたり公開されていますが、多くのオープンソースプロジェクトは依然として重大なCI/CDセキュリティギャップを抱えており、深刻なインシデントにつながる可能性があります。 

この記事では、Sysdig TRT がセキュリティ上の問題を確認し、保護を支援したいくつかの GitHub リポジトリについて紹介します。これらには、MITRE や Splunk といった組織が管理するプロジェクトや、コミュニティによって構築されたプロジェクトが含まれます。

また、pull_request_target を使用する際のベストプラクティスに関する推奨事項や、pull_request の利用に関する提案も紹介します。最後に、オープンソースの Falco Actions を活用して CI/CD ワークフローへの脅威を監視・検知する方法についても説明します。

GitHub Actions とは何ですか？

GitHub Actionsは、オープンソースプロジェクトにおけるCI/CDパイプラインのビルド、テスト、デプロイメントを自動化するための最も広く利用されているプラ​​ットフォームの一つであり、スピードと柔軟性を無料で提供しています。しかし、多くのメリットと同時に、深刻なセキュリティリスクも伴います。 

最近、多くの最新のサプライチェーン攻撃が、安全でないGitHub Actionsワークフローを悪用することから始まることが確認されています。これらのワークフローには、APIキーや認証情報などのシークレットが含まれていることが多く、これらを利用することで権限の昇格やリポジトリ内における横方向の移動、さらには組織全体への侵入が可能になります。

これらの脆弱性を特定し、悪用する方法を詳述したツール、テクニック、公開調査が利用可能であるにもかかわらず、多くのオープンソースプロジェクトの全体的な成熟度は依然として驚くほど低いままです。Sysdig TRTは、これらの問題がいかに蔓延し、危険であるかを示すいくつかの事例を発見しました。

Pull_request_target の不正使用

私たちは、GitHub検索を使って様々なリポジトリをスクレイピング・分析することで、実際のプロジェクトを評価し、状況を把握し始めました。まずは、よく知られていて比較的分かりやすいものから始めたかったので、pull_request_target が 最適な選択肢でした。

Pull_request_targetは、GitHub Actions の非常に有名なトリガーイベントで、リポジトリをターゲットとしたプルリクエストでアクティビティが発生した際にワークフローを実行します。pull_requestマージコミットのコンテキストで実行されるイベントとは異なり、このイベントはpull_request_targetベースブランチ（通常はデフォルトブランチ（例：main または master））のコンテキストで実行されます。もう一つの違いは、シークレットへのアクセスとGITHUB_TOKENpull_request_targetへの書き込み権限を持つことです。以下の表は、これらの違いをより明確に示しています。

MITREとSplunkで安全でないGitHub Actionsが発見される

では、なぜ pull_request_target は悪名高くなってしまったのでしょうか？

メンテナーはしばしば pull_request_target を使用して、プルリクエストで提案された変更（多くの場合、外部のコントリビューターによる信頼されていないコード）をテストします。しかし、プルリクエストのコードをチェックアウトすることで、そのワークフローが任意の、場合によっては悪意のあるコードを実行してしまうリスクが生じます。

さらに悪いことに、GITHUB_TOKEN の権限やシークレットの存在も忘れてはなりません。上記の表に示されているように、pull_request_target によってトリガーされるワークフローはすべてのリポジトリシークレットにアクセスでき、GITHUB_TOKEN にはデフォルトで読み書きの権限が付与されます。

これらが組み合わさることで、pull_request_target を使ったワークフローがフォーク元のコードをチェックアウトすると、すべてのシークレットと高い権限を持つ GITHUB_TOKEN が露出し、重大なセキュリティリスクが生じることになります。

私たちが分析を進める中で、脆弱な pull_request_target ワークフローが予想以上に多く存在することに驚かされました。こうした問題は、目立たないリポジトリや非アクティブなプロジェクトに限られていると考えるかもしれませんが、実際にはそうではありませんでした。数万のスターを持つ有名プロジェクトの中にも、依然として安全でない設定を使用しているものが複数見つかりました。 

発見事項１: spotipy-dev/spotipy (CVE-2025-47928)

リポジトリspotipy-dev/spotipy は、5,200 個のスターと約 1,000 件のフォークという人気ぶりから注目を集めました。Spotipy はSpotify Web API用のオープンソースの Python ライブラリで、ユーザーはこれを利用して独自の軽量音楽アプリケーションを作成できます。ワークフローを調査したところ、pull_request_target を使用しているものが確認されました。

pull_request_target:

    types: [opened, synchronize, reopened]

...

...

      - uses: actions/checkout@v4

        with:

          ref: ${{ github.event.pull_request.head.ref }}

          repository: ${{ github.event.pull_request.head.repo.full_name }}

...

...

      - name: Install dependencies

        run: |

          python -m pip install --upgrade pip

          pip install .

....

ワークフローpull_request_targetが脆弱になり、悪用される可能性があるのは次の場合です。

  • head.refから信頼できないコードを明示的にチェックアウトして実行する
  • リポジトリ内の変更された1つ以上のファイルを実行するワークフローステップがあります

このケースでは、pip install によってワークフロー内でコードを実行する手段が容易に得られます。

setup.py を悪意のある Python パッケージに書き換えることで、そのパッケージが pip を通じてインストールされると同時に、注入されたコードが実行されます。

スニペット コードは、memdump.pyと呼ばれるよく知られたスクリプトを実行して、メモリからシークレットを抽出し、そのシークレットを外部バケットに流出させます。 

memdump.py

sleep コマンドはワークフローの実行を継続するため、GITHUB_TOKEN はアクティブなままです。この場合、GITHUB_TOKENやその他のシークレットを盗み出すことができます。トークンの権限を確認すると、デフォルトで高い権限を取得していることがわかります。

GITHUB_TOKEN Permissions

  Actions: write

  Attestations: write

  Checks: write

  Contents: write

  Deployments: write

  Discussions: write

  Issues: write

  Metadata: read

  Models: read

  Packages: write

  Pages: write

  PullRequests: write

  RepositoryProjects: write

  SecurityEvents: write

  Statuses: write

デフォルトの高い権限を取得すると、ユーザーはメインリポジトリのコンテンツを完全に制御できるようになります。GHSA -h25v-8c87-rvm8経由でSpotipyチームに脆弱性を報告したところ、チームは問題を認識し、速やかに修正しました。この脆弱性はCVE ID 2025-47928として発行され、リポジトリを完全に乗っ取ることができたため、重大と分類されました。  

発見事項２: mitre-attack/car

spotipy-dev リポジトリで問題を発見した後 、私たちは別の興味深いリポジトリを発見しました。最初は信じられないくらい驚くべき内容でした。それがmitre-attack/carです。MITRE CAR（サイバー分析リポジトリ）は、検知ルールやロジックを含む分析情報のコレクションで、ブルーチームがMITRE ATT&CKフレームワークにマッピングされた敵対者の行動を特定できるように設計されています。このリポジトリで、Spotipy のワークフローに非常によく似た、注目すべき別のワークフローを発見しました。

on:

  pull_request_target:

...

      - name: Pull down repo

        uses: actions/checkout@v3

        with:

          repository: ${{ github.event.pull_request.head.repo.full_name }}

          ref: ${{ github.head_ref }}

...

...

      - name: Install script dependencies

        run: pip install -r ./scripts/requirements.txt

...

驚くべきことに、今回も以前とほぼ同じ手法で悪用に成功しました。

このケースでは、ワークフローが head ブランチをチェックアウトするため、pip install コマンドは通常の requirements.txt ファイルに依存しており、攻撃者がこのファイルを完全に制御できます。

結果として、私たちは再びデフォルトで高い権限を持つ GITHUB_TOKEN やその他のシークレットを外部に流出させることに成功し、リポジトリ内で特権を獲得しました。

この脆弱性を MITRE に報告したところ、速やかに認識され、MITRE チームによって迅速に修正されました。

発見事項３: splunk/security_content

MITRE に驚かされていた最中、私たちはセキュリティコミュニティでよく知られた別の名前のリポジトリ、Splunk の splunk/security_content にも疑わしいワークフローが存在するのを発見しました。

これまでの例と同様に、pull_request_target を利用してワークフローを改変し、Python を悪用することが可能でした。

on:

  pull_request_target:

    types: [opened, reopened, synchronize]

jobs:

  appinspect:

    runs-on: ubuntu-latest

    steps:

      - name: Check out the repository code

        uses: actions/checkout@v4

        with:

            ref: refs/pull/${{ github.event.pull_request.number }}/merge

 ...

      - name: Install Python Dependencies and ContentCTL and Atomic Red Team

        run: |

          echo "- Contentctl version - $(cat requirements.txt)"

          pip install -r requirements.txt

 ...

この場合、抽出されたGITHUB_TOKENは読み取りコンテンツアクセスのみで適切にスコープ設定されていました。しかし、ワークフローでは2つのシークレットが盗み出されています。

  • APPINSPECTUSERNAME
  • APPINSPECTPASSWORD 

ノート：Splunkにセキュリティ問題を報告しましたが、返答はありませんでした。Splunkに通知してからワークフローは修正されましたが、抽出されたシークレットの機密性は不明です。

推奨事項

調査の過程で、私たちは数十のオープンソースリポジトリにアクセスし、高い権限を持つ GITHUB_TOKEN やその他のシークレットを外部に流出させることに成功しました。これらはすべて、非常に基本的で概念的に同一の手法によって行われており、リポジトリ所有者による特別なワークフロー制限も設定されていませんでした。

驚くべきことに、こうした CI/CD のベストプラクティスは、期待されるほどには広く採用されておらず、多くのオープンソースプロジェクトのセキュリティ強化に対して疑問が残ります。

もちろん、pull_request_target導入されたのには理由があります。ワークフローでプルリクエストをより細かく制御できるようになるからです。しかし、設定ミスのリスクが高いため、細心の注意を払って使用する必要があります。 

ここで、私たちの最初にして最も重要な推奨事項にたどり着きます。

十分に理解し、適切に保護できない限り、pull_request_target を使用しないでください。

このトリガーを使用する必要がある場合は、本ブログで指摘したような潜在的なセキュリティ脆弱性を防ぐために、ワークフローを徹底的に強化してください。

「public fork からのすべてのワークフロー実行に承認を要求する」設定を有効にしても、pull_request_target トリガーには効果がありません！

GitHub が指摘しているように：

「pull_request_target イベントによってトリガーされるワークフローは、ベースブランチのコンテキストで実行されます。ベースブランチは信頼されたものと見なされるため、これらのイベントでトリガーされたワークフローは、承認設定に関係なく常に実行されます。」

ワークフロー分割

ワークフローを非特権コンポーネントと特権コンポーネントに分割することは、GitHubの推奨事項の一つであり、初期のプルリクエスト処理における非常に効果的なセキュリティ戦略となり得ます。pull_requestイベントは、機密情報へのアクセスや書き込み権限を必要とせずにプルリクエストを処理できます。一方、workflow_runイベントによって起動される特権ワークフローは、非特権ワークフローのチェックが完了した後にのみ呼び出されます。 

この分離により、フォークされたプルリクエストから潜在的に悪意のあるコードが特権コンテキスト内で実行されることがなくなります。通常、非特権ワークフローは特権を持つワークフローと通信し、情報を渡す必要があります。これは重要なセキュリティ境界であり、次のセクションで説明するように、非特権ワークフローから送信されるデータはすべて信頼できない、潜在的に危険なものと見なす必要があります。

GITHUB_TOKEN 権限を制限する 

前の例で見たように、GIHTUB_TOKENに最小限の権限を設定すると、攻撃者がそれを使って実行できる操作が減ります。 

ワークフローで権限を設定する方法の例を次に示します。

permissions:

  contents: read

この場合、コンテンツに対して読み取り権限のみを設定するので、攻撃者はワークフローで使用されるGITHUB_TOKENを使用してリポジトリのコンテンツを改ざんしたり変更したりすることはできません。

pull_request_target は細心の注意を払って使用してください

この記事を読んでもまだ使用を決定される場合はpull_request_target、関連するリスクを十分に理解し、強力な安全性チェックを実施してください。考慮すべき緩和策の一つとして、プルリクエストに特定のラベルが割り当てられた場合にのみワークフローを実行するように設定することが挙げられます。これにより、リポジトリへの書き込み権限を持つメンテナーによる手動審査が実質的に必要になります。外部コントリビューターはラベルを割り当てることができないため、これによりプルリクエストは手動レビュー後にワークフローをトリガーすることが確実になります。

ただし、この方法は万能ではありません。競合状態が発生しやすく、ラベルが追加された後、ワークフローが開始される前に攻撃者がプルリクエストに新しいコミットをプッシュする可能性があります。そのため、ラベルベースのゲーティングは恒久的な解決策ではなく、一時的な回避策として扱うべきです。前述の強力な緩和策のいずれかを実施することを強くお勧めします。

ランタイム脅威検知にFalco Actionsを使用する

tj-actions/changed-filesの場合と同様に、CI/CDワークフローの潜在的な脅威をリアルタイムで監視するオープンソースプロジェクトであるFalco Actions をワークフローに簡単に組み込むことができます。Falcoを基盤とするこのツールは、不正なネットワーク接続やファイルアクセスといった不審なアクティビティを検知できます。

以下のエクスプロイトシナリオを使用すると、Falco Actions は上記の 3 つの発見のそれぞれで実行された悪意のある振る舞いを検出できます。

  • /proc/{pid}/mem にアクセスし、各読み取り可能なメモリ領域をスキャンして認証情報を抽出する。
  • 収集したデータを外部ドメインに送信するための接続を確立する。

Falco Actions はワークフローの完全なコンテキストを備えているため、悪意のあるアクティビティが発生したワークフロー ステップを正確に識別でき、トラブルシューティングと正確な実行ポイントの特定が容易になります。

まとめ

オープンソースプロジェクトに対する近年のソフトウェアサプライチェーン攻撃は、安全でない GitHub Actions ワークフローの悪用から始まります。これらのワークフローにはシークレットが含まれていることが多く、攻撃者がそれを外部に流出させることで、リポジトリ内での権限昇格が発生します。

特に pull_request_target は、パブリックフォークを扱う性質上、脆弱性にさらされやすいことで広く知られており、このトリガーを使用するワークフローは、関連するセキュリティリスクとともに特に慎重に取り扱う必要があります。

私たちの調査では、pull_request_target 以外にも多数の安全でない GitHub Actions ワークフローが存在することが判明しました。Sysdig TRT は現在、該当する組織や開発者と協力してそれらの問題を修正しており、今後も脆弱性の修正にあわせて調査結果や詳細情報を継続的に報告していきます。

開示タイムライン

2025年5月14日 — Sysdig TRT が MITRE にセキュリティ問題をメールで報告

2025年5月14日 — Sysdig TRT が Spotipy に GitHub Security Advisory（GHSA）を通じてセキュリティ問題を報告

2025年5月15日 — MITRE が報告されたセキュリティ問題に対する修正パッチを公開

2025年5月15日 — Spotipy が報告された問題を受領

2025年5月16日 — Sysdig TRT が Splunk にセキュリティ問題をメールで報告

2025年5月16日 — Spotipy が GitHub Security Advisory（GHSA）を通じて脆弱性を開示 — CVE-2025-47928

2025年5月21日 — Splunk が報告されたセキュリティ問題に対する修正パッチを公開。ただし、Splunk から脆弱性に関する受領の連絡は一切ありませんでした。