記事のサマリー（TL;DR）
- freee レッドチームが LLM（フロンティアモデル）で攻撃コードを全量生成し、GitHub CI/CD → AWS 環境を標的にした障害訓練を2025年に実施
- 多層防御（SSO+MFA・シークレットスキャン・SIEM・AWS Network Firewall 等）を敷いていても、LLM を使えば複雑な CI/CD フローの解析は「難しくない」と実証
- 訓練後に GitHub PAT 廃止・Immutable Releases 導入など具体的なセキュリティ改善プロジェクトが始動
開発者環境を標的にするサプライチェーン攻撃が激化する中で、国内 SaaS 企業が学べること
OSS サプライチェーン攻撃は 2024〜2025 年にかけて急速に拡大しており、攻撃者は明確に開発者端末・CI/CD パイプラインを狙うようになっています。freee の訓練が示した最大の教訓は「多層防御を敷いていても確実に安全ではない」という点です。これは freee に限った話ではなく、GitHub を活用して SaaS を開発・運用する国内企業全般に当てはまります。
特に、kintone や Salesforce などの業務 SaaS と外部システムをつなぐ連携開発の現場では、複数リポジトリ・複数 CI/CD パイプラインが絡み合い、攻撃経路の可視化が難しくなりがちです。freee が採用した「blue team が SIEM を AI Agent + MCP で接続してログ解析を高速化する」という構成は、ログ量が多い大規模環境での障害対応に直接応用できる設計思想です。また、今回の訓練で攻撃シナリオと攻撃コードをすべて LLM で生成できたという事実は、「LLM を持つ攻撃者は複雑なシステム構成をすぐに解析できる」という前提でセキュリティ設計を見直す必要性を示しています。
詳細
freee の多層防御の現状
OSS サプライチェーン攻撃が激化する以前から、freee は開発者環境および GitHub に対して複数のセキュリティ対策を講じてきました。基本方針は「不正な認証情報の混入・漏洩は起こり得る」という前提に立ち、単一の防御が破られても別レイヤで検出・遮断できる独立した仕組みを多層的に配置するというものです。
具体的な施策は以下の通りです。
- アイデンティティ管理: GitHub アカウントに対して SSO（シングルサインオン）＋ MFA（多要素認証）を強制適用
- シークレットスキャン: pre-commit・pre-push・リポジトリ日次スキャン・公開後検知まで、認証情報や個人情報の混入を多段階で自動検知・遮断
- ブランチ保護と第三者レビューの強制: 組織共通のブランチ保護ルールを適用し、プロダクト関連コードのマージには第三者のレビューと承認を必須化
- SIEM によるログ集約と解析: 開発環境・GitHub の操作ログ・監査ログを SIEM（セキュリティ情報イベント管理基盤）に集約し、異常な挙動を常時監視
- 不正通信の検知と遮断: AWS Network Firewall によるアクティブ脅威防御を有効化し、不正と疑われるトラフィックを常時検知・遮断
さらに、攻撃激化を受けて 2025 年に入ってからも以下の施策を追加しています。
- Cooldown 設定などパッケージ管理のベストプラクティスを策定し、開発者端末へ配布
- 想定外の経路から GitHub PAT（Personal Access Token）が利用された際の即時検知・無効化
今回の障害訓練の目的と攻撃チームの結成
組織の急速な拡大により全社規模での障害訓練の実施が難しくなっていた中、「スコープを絞ってでも自分たちでやろう」という動機でエンジニア組織を対象にした大規模障害訓練が企画されました。2025 年 3 月に始動し、OSS パッケージに混入した悪意のあるマルウェアにエンジニア端末が感染したというシナリオを起点に、多層防御を突破して攻撃者が得られる最大限の利益を検証するものです。
攻撃チームには、SRE チームのマネージャー gussan 氏と同分野の専門家 Shunsuke Suzuki 氏、Security Champion として活動する wataru 氏などが参加。カスタマーサポート・プロダクト・インフラ有識者・インシデント対応の鬼殺隊なども加わり、最終的に 12 名の体制で攻撃チームを組織しました。
LLM を活用した攻撃シナリオの設計
攻撃シナリオは、2025 年に活動が確認されている攻撃アクター「TeamPCP」のテクニックを参考に設計されました。初期侵入には現在流行している一般的な開発者向けサプライチェーン攻撃手法を採用し、侵入後に攻撃者が得た情報を LLM で解析した結果として到達できる範囲でシナリオを組み立てています。
演習中に「攻撃者が freee の複雑な CI/CD フローを理解できるのか？」という疑問の声が上がりましたが、最新のフロンティアモデルを使えばそれは難しくない、というのが freee レッドチームの結論です。実際、今回の演習シナリオと攻撃用プログラムはすべて LLM で生成しており、SRE や開発チームの有識者によるレビューを経て細部を追加・調整しました。
演習当日の攻防
14 時に攻撃を開始。初期侵入から探索、メインシナリオを実行するプログラムの起動へと進みました。
エンジニア以外の自発的な参加
演習では広報・リスク管理チーム・関係省庁連携チームの参加を想定していませんでしたが、これらのメンバーが自発的に参加し、ユーザーへの連絡対応・リスク判断などを進めました。大規模障害においてこうした部門の連携経験は実際には得られにくく、今回の訓練は貴重な機会となりました。
エンジニアの対応速度
レッドチームの予想を超え、メインシナリオによる侵害から わずか 5 分後 に通常とは異なるフローで作成された不審なプルリクエストがエンジニアに発見されました。何が起きているかの概要は早期に看破されましたが、根本原因への到達は時間がかかりました。その間、レッドチームはサブシナリオによる追撃で影響範囲を順次拡大していきます。障害対応ブリッジからは「またなんか起きたの…」という声が上がったと言います。
なお、Slack Webhook を通じて犯行声明文を送信し、攻撃者がコミュニケーションを求めてくるというサブシナリオも用意されていましたが、セキュリティチームにスルーされました。
blue team（セキュリティチーム）の解析
攻撃者は攻撃と同時に痕跡を可能な限り削除したため、blue team の解析は難航しました。blue team は SIEM を AI Agent + MCP で接続してログ解析を高速化する構成を取っていましたが、今回は削除されたログをエージェントが延々と探し続けるという挙動に悩まされました。最終的に攻撃の全容解明に貢献したのもこのエージェントでしたが、以下の点がポストモーテムで課題として挙がりました。
- LLM をより活用してログ調査の並列度を上げる
- 調査時のプロンプトや skills の改善
- 調査すべき IoC（侵害指標）の優先順位付け
演習完了と、その後の改善活動
複数の障害報が起票され、調査班が事件の核心に迫りはじめたところでタイムアップ。参加者全員が集まり、攻撃チームの紹介・シナリオの全容・訓練を通して伝えたかった 3 点が共有されました。
- 開発者が攻撃者に狙われており、自衛が必要な状況が続いていること
- 多層防御を敷いていても確実に安全ではなく、中長期的に取り組むべき課題がまだ残っていること
- 障害訓練そのものの重要性（実際に経験しないと伝わらないこと）
アンケートでは「自分のチームでも障害訓練をしたい」という声が多数寄せられました。
訓練後、今回の攻撃経路を完全に塞ぐためのプロジェクトが立ち上がり、Shunsuke Suzuki 氏がこれまで発信してきた知見も改善に活用されています。具体的な GitHub セキュリティ改善の内容は以下の通りです。
- ghtkn: ローカル開発用に GitHub Access Token をセキュアに生成し、PAT（Personal Access Token）からの脱却を図る
- ghir: 過去の GitHub Releases も Immutable にする
SRE を中心に他チームの有識者も集まり、大きなプロジェクトとしてセキュリティ改善が動き出したこと自体が、今回の演習がもたらした組織的な成果の一つだとレッドチームは評価しています。