こんにちは、北海道から freee red team*1に参加している yu です。
北海道は春らしい暖かい日が続き、雪も溶け、私は冬に家の前で落としたスマートリングをようやく見つけることができました。北国での冬の落とし物は往々にして春を待たなければならないことがあります。
さて、そんなことよりも今日は2022年に始まった freee Security Champions*2 のこれまでの歴史と、今なお進化し続けるこの制度についてご紹介します。
Security Champions Program の開始（2022年）
2022 年に私が freee へ入社した頃、当時の PSIRT（Product Security Incident Response Team）は急速に拡大する Agile な開発組織の中でどのように Shift Left*3 するのか少ないリソースの中で腐心していました。
そうした中で PSIRT の先人たちが組織に働きかけ続け、それに呼応するエンジニアが現れ始めていた中、入社間もない自分がラフに制度設計して「Security Champions やりたい人は手を挙げて！」というなり多くのエンジニアが手を挙げてくれました。この辺りの話は Software Design 2024年8月号にも寄稿しています。
先述の通り当時の PSIRT はリソースの少なさから仲間探しに奔走しており、その中で開発チームと PSIRT の橋渡しをしてくれるエンジニアとして Security Champions Bronze Rank を制定しました。
Bronze ということにはその上位に Silver と Gold があるはずですが、そうした制度設計を待たずにこの制度は走り出しました。大いなる見切り発車です。
Silver Rank 制定（2024年）
立候補した Champions たちは私たちの期待に応えて様々なコミュニケーションを提供してくれる一方で、「明確に何をすれば良いのかわからないぞ」という当然の不安に身を寄せ合って集まったのが freee 販売というプロダクトに関わった Champions たちでした。
そうして集まった彼らは私たち PSIRT が行っていた SDR（Security Design Review、設計プロセスにおけるセキュリティレビュー）を PSIRT よりも先に自分たちで行うという活動を自発的に始めました。そして、チームの開発事情に明るい Champions がセキュリティ観点で Review を行った Design Doc は私たち PSIRT の SDR の認知負荷や判断コストを大きく下げ、SDR の高速化が進みました。
これに味を占めた私は、「有効な SDR を10件行った Champions を Silver Rank とし、Silver Rank Champions が行う Review は PSIRT の Review と同等のものと見做す！」ということにしました。発足からここまでに1年以上経っており、やりっぱなしで放置していた自分の怠慢をよそに Champions 制度を Champions 自身が拡張した結果、適切な目標が見つかった格好です。その後 Silver Rank Champions は徐々に増え、Security Champions のレビュー欄は freee の Design Doc のテンプレートに埋め込まれました。
それからも freee という組織は拡大を続け、セキュリティチームが開発プロセスの中に挟まることがボトルネックになりかねない状況が続く一方、freee の Security Champions は増え続け、SDR を自発的に行い、セキュアで品質の高い開発サイクルの高速化に貢献し続けました。
そのうち Champions の間で脅威分析の代表的な手法の STRIDE が流行るなど、私の想像を超えるムーブメントが静かに進行していきました。
AI エージェント時代の Security Champions（2025年〜）
2025年には AI エージェント元年を迎え、これまでとは異なるレベルの開発スピードの変化がありました。
脆弱性診断全般を担当していた私たち red team も強い危機感を覚え、年始から AI エージェントによる自動診断機能の開発を行い、同年6月にはこの機能を用いて「開発者自身で脆弱性診断を行い」、「red team と一緒に検出された指摘事項をトリアージする」というフローを開始することでこの変化に対応しました。
これによって脆弱性診断における大きな高速化を実現した一方で、2025年の下半期はさらに開発スピードが早まり、LLM の診断結果に対する人間のレビューがボトルネック化してきました。
そんな中、そうした影響を感じないプロダクトが一つだけありました。
そのプロダクトチームは、脆弱性診断のスケジュールが余裕を持って組まれ、開発者自身が適切にトリアージし、そもそも LLM に指摘される脆弱性の数が段違いに少なかったです。もちろん、このチームも Coding Agent を上手に使いこなしていたし、開発スピードも他のプロダクトと遜色ありません。
それが前述の freee 販売のチームでした。Security Champions 創設期から関連するチームの Champions たちが連携してバーチャルチームとして活動を続け、メンバーがマネージャーになったり異動したりしたら後継者をアサインするなど、一つのチームとして Champions 同士が連携し、活動の幅を広げ、サステナブルな改善を繰り返してきました。Dependabot Alert の数も段違いに少ないです。
LLM によるレビュー品質や、レビューを必要としないガードレール設計の必要性が議論される昨今、これは全く異なるベクトルの驚くべき結果だと思い、思わず塩漬けしていた Gold Rank Security Champions の要件を固めました。
それは「事業部においてセキュリティ文化を醸成できたチームの中で、その功績に最も貢献した人」です。
販売チームの Champions たちにそれぞれ推薦文を書いてもらったところ、創設期から中心的な役割を担い、また、セキュリティ改善のための機能実装などを行ってきたエンジニアが満場一致で freee 初の Gold Rank Champion に選ばれました。自分が Security Champions の制度設計に悩んでいた頃に壁打ちをしてもらっていたエンジニアでもあり、個人的にも「やっぱりこの人か」と納得感のある任命でした。
freee Security Champions のこれから
さて、そうしたセキュリティ文化が醸成したチームにおいては、セキュリティ面においてもっと攻めた施策を行なっても応えてくれるはずです（いつも無茶振りしてごめんね）。
red team では兼ねてより LLM による脆弱性診断を GitHub の PR や Milestone 単位でスケジュール実行できる機能開発を続けてきましたが、それを実運用化すると従来よりも遥かな開発サイクルの高速化が達成できる一方、これまでと異なる統制フローが必要になり、red team によるトリアージが行き届かなくなる懸念がありました。
Gold Rank Security Champions が所属するセキュリティ文化が醸成されたチームでは、そんな心配をしなくても良いかもしれません。この機能を使いこなしてくれるはずですし、判断に困ることがあれば気兼ねなく相談してくれる信頼がお互いにあるはずです。こうして、freee のセキュアな開発サイクルはより一層の高速化を実現していくことができそうです。
おわりに
Coding Agent が一般的になった現代において、「エンジニア」という定義は揺らぎ始めています。もちろん、誰でもコードを書けるということ自体はとても素晴らしいことだと思っています。
それでも、品質保証やセキュリティに関わる私のようなエンジニアにとって、本当に信頼できる「エンジニア」という概念は今もまだ全く変わっていません。
そして、そうしたエンジニアに追いつこうと Gold Rank を目指す Security Champions たちがより積極的に動き始めていることも freee の中で観測しています。
今後はエンジニアリング以外の領域にも、このムーブメントを広げていきたいと考えています。
*1:所属する組織に対して擬似的なサイバー攻撃を行う愉快なチームです。
*2:Security Champions とは OWASP Security Culture で定義されたプログラムですが、freee ではこれを独自に再定義し、ボトムアップ型のムーブメントにしています。
*3:ソフトウェア開発ライフサイクルにおいてテストやセキュリティ対策を企画や設計、実装フェーズなどのより早期に実施するアプローチ
