「GitHubトークンが盗まれただけでコードベース全体が抜かれるって、どういうこと?」
「Pwn Requestって脆弱性、自社のGitHub Actionsにもありそうで心配…」
ボス、Grafana Labsがコードベースをまるごと盗まれたって本当でしゅか? 大きな話でしゅ…
うむ、5月16日にGrafana Labsが公表した。原因はGitHub Actionsの「Pwn Request」型ワークフロー欠陥で、トークン回転の漏れから侵害に至った。
本記事ではGrafana Labsのソースコード窃取事案と、原因となった「Pwn Request」型GitHub Actionsの脆弱性、自社GitHub環境で取るべき対策を解説します。
OSSベンダーに限らず、CI/CDで外部PRを処理するすべての組織が確認すべき内容です。
- 原因はGitHub Actionsのpull_request_targetイベントを使った「Pwn Request」型ミス設定
- トークン回転で多数を入れ替えたが1つの漏れから侵害に発展
- 恐喝集団CoinbaseCartelが犯行声明、Grafana Labsは身代金支払いを拒否
続きを読めば、Pwn Request型欠陥の見極め方と、トークン管理の落とし穴、現実的な恐喝対応の指針が分かります。
目次
Pwn Requestがソースコードを丸ごと盗んだ手口
GitHub Actionsには、外部コントリビューターからのPRを安全に扱う仕組みがあります。
その仕組みを誤って使うと、外部の人が本番秘密にアクセスできる状態を作ってしまいます。
pull_request_targetの設定ミスがすべての始まり
事案の発端は、新たに導入されたGitHub ActionワークフローでのPwn Request型脆弱性です。
pull_request_targetイベントは、PR作成元(外部のフォーク)が信頼できない場合でも本リポジトリの秘密にアクセスできる仕組みで、設定を誤ると外部コントリビューターにシークレットを渡してしまいます。
Grafana Labsはこの不具合を検知してGitHubワークフロートークンの多くを回転させましたが、1つだけ漏れた古いトークンが攻撃者の手に渡り、リポジトリ全体のダウンロードを許しました。
事案の主要な事実関係はこちらです。
| 項目 | 内容 |
|---|
| 公表日 | 2026年5月16日(Grafana Labs) |
| 原因 | GitHub Actionsの「Pwn Request」型ワークフロー脆弱性 |
| 影響範囲 | GitHub環境内のソースコード(公開・非公開リポジトリ) |
| 顧客本番環境 | 影響なしと発表 |
| 主張する攻撃集団 | CoinbaseCartel(ShinyHunters/Scattered Spider/LAPSUS$系統) |
検知の決め手はカナリアトークン
Grafana Labsは、社内に大量のカナリアトークン(おとり用の偽トークン)を仕込んでおり、攻撃者がそれを使った瞬間にグローバルセキュリティチームへアラートが届く設計でした。
結果として侵害発生から短時間で検知に成功し、被害範囲をGitHub環境内に封じ込められた点は評価に値します。
本番システムへの横展開を防いだのは、こうした「ハニートークン的な仕組み」と、トークン分離の運用が機能したためです。
カナリアトークンって便利でしゅね! おとりを仕込んでおくと侵害がすぐ分かるんでしゅか。
うむ、コストも低い割に効果が高い。GitHub・S3・KMSなどに撒いておくのが定石だ。
自社で取るべき対策と恐喝への向き合い方
Grafana Labsの事案は、技術的な原因も対処方針も学びの多い内容です。
同種の侵害を避けるために、現実的な手を整理しましょう。
GitHub Actions設計のレビュー観点
pull_request_targetイベントを使うワークフローは、外部コントリビューターのコードを取り込んで実行する設計になっていないかを再点検する必要があります。
該当する場合は、外部から渡されたコードを「実行せず」「内容だけ確認する」フローへ作り直すべきです。
GITHUB_TOKEN以外の長期秘密(Personal Access TokenやServiceアカウント)を使っている箇所は、最小権限の見直しと定期回転を機械的に行う仕組みに置き換えるのが安全です。
運用に組み込むべき点を整理します。
- pull_request_targetイベント利用のワークフローを全件棚卸し
- 外部コードを実行する分岐を、確認専用ジョブに置き換え
- Personal Access Tokenの最小権限化と定期ローテーションの自動化
- GitHubシークレットに混ぜたカナリアトークンを設置し、SIEMで監視
恐喝への対応方針を社内で決めておく
Grafana Labsは身代金の支払いを拒否し、「データが本当に削除される保証はなく、将来の攻撃を呼び込む契機にもなる」と公開で説明しました。
こうした姿勢は、平時から「支払わない」方針と説明責任の枠組みを合意しておかなければ、いざという時に取れません。
法務・広報・セキュリティを巻き込んだ意思決定プロトコルを事前に文書化し、定期的に演習しておく価値があります。
「払いません」って即答できる体制って、なかなか難しそうでしゅね…
うむ、判断のスピードが企業姿勢を決める。事前の合意が、当日の判断を支える。
まとめ:CI/CDも「信頼境界」の対象
Grafana Labsのケースは、OSSベンダーだから起こったというよりも、CI/CDが現代の攻撃面であることを改めて示しました。
自社で取るべき行動を整理します。
- pull_request_target利用ワークフローを点検し、Pwn Request型を排除
- GitHubトークンの最小権限化・自動ローテーションを徹底
- カナリアトークンで侵害の早期検知を仕組み化
- 恐喝対応方針を事前に文書化し、関係部門で演習
CI/CDも守るべき情報資産って意識を持たなきゃでしゅね!
うむ、コードはビジネスそのものだ。雑に扱えば失う。
詳しい情報はBleepingComputerの報道とGrafana Labsの公式声明を参照してください。