6時間で5,561リポジトリに悪性Actions注入──CIシークレット狩りの「Megalodon」が示した供給網の地殻変動です

今日の深掘りポイント

• 攻撃はGitHub Actionsのワークフローにbase64エンコードのbashを注入し、CIシークレットやクラウド認証情報、SSHキーをC2へ送信する設計です。
• 6時間で5,561リポジトリに5,718コミットという面制圧の自動化が実証され、オープンソースの信頼とCI/CDの設計原則を同時に突いています。
• 直接コード本体ではなく「ビルド・署名・デプロイの自動化層」を狙った点が本質で、依存鎖を下流にまで汚染し得ます。
• 最小権限のGITHUB_TOKENと環境ごとのシークレット分離、外部Actionsのピン留め（SHA）と承認フロー、.github/workflowsの保護が実務の急所です。
• SOC視点では「短時間・広範・ワークフロー限定改変・base64/カール経由」の4点セットで横断的検知ルールを束ねるのが現実解です。
• 政策面では、長期鍵を廃しOIDCの短命トークン化と、自己ホストRunnerのネットワーク分離・送信先許可制がベースラインになります。

はじめに

「コードが正しければ安全だ」という信念は、CI/CDの時代にはもはや十分条件ではないのだと、Megalodonは静かに、しかし強烈に告げています。数千のリポジトリに短時間で悪性ワークフローを押し込み、ビルドの裏側からシークレットを刈り取る。これは単発の汚染というより、ビルド信頼鎖を基層から揺らす「地殻変動」です。CISOやSOC、Threat Intelの皆さんに向けて、事実とインサイト、実務に落ちるアクションを整理します。

深掘り詳細

事実整理（一次報道の要点）

• 新しい自動化キャンペーン「Megalodon」が、6時間で5,561件のGitHubリポジトリに対し5,718の悪意コミットを投入したと報告されています。
• 使い捨てアカウントと偽名の著者を用い、GitHub Actionsのワークフローへbase64エンコードのbashペイロードを注入。CI環境のシークレット、クラウド認証情報、SSHキー等をC2サーバへ送信する設計です。
• 影響例として@tiledesk/tiledesk-serverが挙げられています。
• 攻撃の意図は、CI/CDパイプライン内でマルウェアを実行させ、認証情報やシークレットを大規模に盗むことにあります。
• 出典: The Hacker News

上記以外の詳細（侵入経路の特定、C2ドメイン一覧、利用トリガー種別など）は現時点の公開情報からは読み切れないため、本稿では仮説は仮説として明示します。

編集部の視点・インサイト

• 「コードではなく自動化を汚染する」成熟化
  • 従来のOSSサプライチェーン攻撃は依存パッケージやリリースアーティファクトへの混入が主流でした。今回は、ビルド・テスト・署名・デプロイを司るワークフロー層を直接ひねるアプローチです。ここは少数のYAMLと外部Actions参照、環境変数とシークレットでシステム全体を動かす“支点”。一点突破の効率が極めて高いです。
• 「短時間・広範囲」の自動化実証
  • 6時間で5千超という規模は、対象の選定・改変・コミット・実行を完全自動化していることの証左です。CI/CDの多様性にもかかわらず成立している事実は、「一般化可能な誤設定」や「共通ベストプラクティスの穴」を突いた可能性を示唆します。
• 現場示唆（メトリクスからの総合判断）
  • 脅威の新規性と実効性が同居し、発見されにくいワークフロー改変を足場にしているため、早期封じ込めが勝負どころです。対策は「権限と動的秘密の寿命を最小化」「ワークフローの変更を極端に面倒にする」ことに尽きます。すなわち最小権限のGITHUB_TOKEN、OIDCベースの短命クラウド権限、.github/workflowsの変更に専用レビューを課し、外部ActionsはSHA固定で審査済みに絞る、の4点セットが中核になります。

攻撃が成立する条件（仮説）

公開情報からは断言できないため、以下は一般化した仮説です。

• ワークフロー改変のパス
  • 何らかの形でデフォルトブランチへ直接コミットできる経路（例: 流出したPAT/SSH鍵の悪用、ブランチ保護の欠落、承認不要の自動マージ設定）を自動探索・悪用した可能性があります。
  • あるいはpull_request_target等のトリガー誤用を突き、フォークからのPRに起因してベースリポジトリ権限で任意コードが動く構図を利用した可能性もあります。
• 外部Actions・スクリプトの信頼境界
  • バージョンタグ固定やSHAピン留めが不徹底、あるいは未検証パブリッシャーのActionsを許可していた環境では、改変の可搬性が上がります。

監査・検出の難所

• 攻撃はYAML1ファイル・数行の改変で成立し得ます。レビュー負荷の低い“運用作業”に偽装されやすく、監査ログ上も「ワークフロー更新」という日常イベントに紛れます。
• ペイロードはbase64などで難読化され、CI実行ログに断片的にしか残りません。出力マスクで“見えない”一方、実害はクラウド側に出るため、GitHub側だけを眺めても異常が目立ちません。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説シナリオです（公開情報から断言できないため仮説と明示します）。

• シナリオA（PRトリガー誤用）

  • 初期アクセス: Supply Chain Compromise（T1195）/ Valid Accounts（T1078, 仮）経由ではなく、pull_request_target等の誤用を突く
  • 実行: Command and Scripting Interpreter: Bash（T1059.004）
  • 難読化: Obfuscated/Compressed Files and Information（T1027）、Deobfuscate/Decode（T1140）
  • 資格情報の取得: Credentials in Files/Environment（T1552, T1552.001/004）
  • 収集: Data from Local System（T1005）、Discovery（T1082）
  • C2/流出: Application Layer Protocol: Web（T1071.001）、Exfiltration Over C2 Channel（T1041）
  • 影響: CIコンテキストの権限でクラウドSTSトークンを発行し、下流のアーティファクトやインフラに横展開

• シナリオB（流出トークンで直コミット）

  • 初期アクセス: Valid Accounts（T1078）
  • 防御回避: Modify Trusted Developer Tools（T1553, 仮, ワークフロー改変）
  • 実行/収集/流出はシナリオAと同等
  • 影響: デフォルトブランチのCIを確実に起動できるため、秘匿情報の即時収集と任意の外部送信が可能

• シナリオC（自己ホストRunnerでの踏み台）

  • 実行基盤が社内ネットに近接する自己ホストRunnerだった場合、ローカル資格情報・内部メタデータサービス経由の追加権限取得と横移動（Lateral Movement: Remote Services T1021, 仮）が発生し得ます。

ビジネス影響としては、以下が現実的です。

• クラウド認証情報の悪用によるデータ抽出、暗号資産マイニング、ストレージ改ざん、CIアーティファクトの汚染です。
• 署名鍵やリリースパイプラインに触れられた場合、正当性の看板を掲げた悪性リリース（信頼失墜コストが最大）に波及します。
• オープンソースに依存する社内プロジェクトは、見えないところで「汚染された成果物」を取り込む二次被害の懸念が続きます。

セキュリティ担当者のアクション

• 即日（48時間以内）にやるべきこと

  • CI実行ログと監査ログで「直近7日間の.github/workflowsへの変更」「base64 -d | bash / curl|bash / wget -O- | sh などの実行」を横断検索します。
  • 組織/リポジトリ設定で以下を強制します。
    • GITHUB_TOKENのデフォルト権限をreadにし、必要ジョブのみ最小昇格（permissions: contents: read など）にします。
    • 外部ActionsはAllowlist＋SHAピン留め（タグではなくcommit SHA）に限定します。
    • .github/workflows配下に対し、CODEOWNERSで専用レビュアを要求し、2名以上の承認を必須化します。
    • フォークからのワークフロー実行は原則無効。pull_request_targetの使用は明示的な承認ゲートとします。
  • 秘密情報の隔離と短命化
    • クラウド資格情報は長期鍵を廃止し、GitHub OIDCによるフェデレーション（最小権限ロール、短TTL、aud/sub制約）へ移行します。
    • 組織／環境スコープのシークレットを分離し、不要なリポジトリからは参照権限を外します。
  • 侵害の前提で回転
    • CIで参照されるPAT/SSH鍵/クラウドロールのキーを強制ローテーションします。必要に応じC2宛先のブロックを即時適用します。

• 今週中にやるべきこと（設計の是正）

  • リポジトリルール／ブランチ保護
    • デフォルトブランチへの直接プッシュ禁止、ステータスチェック必須、強制署名コミット（Sigstore/gitsignやGPG）を有効化します。
  • Runnerの強化
    • 自己ホストRunnerはエフェメラル化し、ネットワークはアウトバウンド許可リスト方式にします。C2や未知宛先への送信をデフォルト拒否します。
  • 監視と検知
    • 組織横断で「短時間に多数のリポジトリへワークフローのみを変更する不審アカウント」「新規作成アカウントの初回プッシュ」「国/ASNの異常」を組み合わせた相関ルールを用意します。
    • レポジトリアラートとして「on: pull_request_targetの定義/変更」「外部Actions参照の追加/更新」「permissions: write/all 設定の追加」をフックにします。
  • 教育と運用
    • 開発者向けに「CIでやってはいけないコマンド列」（curl|bash, wget|sh, base64 -d | bash 等）を明文化し、レビューのチェックリストに落とし込みます。

• 四半期スパンでの構造的改善

  • サプライチェーン体制
    • SLSA/Provenanceの採用、Sigstore/cosignでのアーティファクト署名と検証、OSSF Scorecardでの継続評価をパイプラインに組み込みます。
  • 秘密管理のゼロトラスト化
    • 環境ごとのシークレット分離、リリース環境は手動承認とハードウェア保護鍵に限定、ログ出力のマスキング徹底を標準化します。
  • ベンダー・地政学リスク
    • 重要OSSのミラーリングと検証、フェイルクローズの依存戦略を策定し、地政学イベント時の代替手段（社内キャッシュ/レジストリ）を整備します。

最後に。Megalodonは、攻撃者が「最小努力で最大権限を奪う場所」を正確に突いてきた事件です。私たちの対抗軸も同じく、最小の設計変更で最大のリスクを落とすことにあります。権限を絞り、寿命を縮め、変更にレビューを重ねる。この“退屈な改善”の積み重ねが、面で押してくる攻撃の速度を確実に鈍らせます。今日の一手が、明日の大事故を静かに無かったことにします。

参考情報

• The Hacker News: Megalodon GitHub Attack Targets 5,561 Repositories with Malicious Commits in 6 Hours https://thehackernews.com/2026/05/megalodon-github-attack-targets-5561.html