サイボウズのセキュリティチャンピオンが目指す世界 - Cybozu Inside Out

こんにちは、PSIRTの大塚です。サイボウズでは、セキュリティチャンピオンという施策を始めました。本ブログでは、セキュリティチャンピオンが目指す世界と現時点での体制、効果を紹介します。

PSIRTとは

今回の内容は、前提としてPSIRTの役割が重要になるため、あらためて簡単に紹介します。詳細は「Cy-PSIRTが行っている製品開発におけるセキュリティ支援についての紹介」をご覧ください。

PSIRTはProduct Security Incident Response Teamの略で、その名のとおり「プロダクトセキュリティ」を担当し、サイボウズが開発するプロダクトのセキュリティ品質向上を目指すチームです。Purposeは次の2つです。

ユーザーに「安全にサイボウズ製品を使える」と言ってもらえる状態をつくる
開発チームに「セキュリティ品質に自信を持ってリリースできる」と言ってもらえる状態をつくる

セキュリティを高めれば高めるほど上記2つは達成できるかもしれません。しかし、それでリリースが遅れたらどうでしょうか。またユーザーにとって使いにくいプロダクトになったらどうでしょうか。これらのPurposeを達成するやり方はたくさんありますが、最終的なユーザーへの価値を最大化させるのがプロダクトセキュリティの重要な考え方だと思っています。今回紹介するセキュリティチャンピオンはこれらのPurposeをユーザーへの価値を最大化させながら達成するための取り組みです。

セキュリティチャンピオンとは

セキュリティチャンピオンは、一連の「仕組み」の名前であり、同時にその仕組みに参画し、実際に活動する「メンバー」を指します。

サイボウズでは、セキュリティチャンピオンを「開発チームにおけるセキュリティの連携窓口」かつ「開発チーム視点で必要なセキュリティ活動を、PSIRTや他チームと連携しながら推進する」メンバーと定義しています。

「これまで開発チームとPSIRTは連携していなかったのか？」というと、そうではありません。セキュリティチャンピオン自体は新しい活動ではなく、これまでの取り組みを整理し、連携経路を明確化することでPSIRTや他チームの支援を受けやすくするための仕組み化です。核となる要素は次の2点です。

開発チーム視点で
PSIRTのようなセキュリティ専門の視点だけで、真に開発チームに沿ったやり方を設計・運用し続けるのは非効率です。セキュリティを優先し過ぎれば生産性の低下やボトルネックが起こりえますし、何もしなければリスクが高まります。「セキュリティとスピードはトレードオフ」という言葉を耳にすることがあります。すべてがそうではないにしても、一部はそのような構造を持つとは思います。重要なのはここで「だから仕方ない」ではなく、もう一歩踏み込んで「最適なトレードオフ*1」を見極めることです。
そのためには、開発チームの文脈（実際の開発の中での困りごと、ボトルネック、リリースサイクル、開発チームの理想や期待するセキュリティ水準など）が不可欠です。今までこれらの情報をPSIRTでもキャッチアップしてきましたが、今後より一層加速する開発スピードや開発体制の変化に追随し、複数プロダクトに関して実施し続けるのには限界があり、非効率です。そこで、これらを継続的に取り込み、最適なバランスを更新していくキーマンとしてセキュリティチャンピオンが必要になります。
他チームと連携しながら
セキュリティの相談は技術論だけでなく、開発事情の前提を含むことが多く、PSIRT単独で即答できないケースもあります。開発チーム → PSIRT → 調査や他チームへ確認 → 返信という伝言ゲームは時間がかかり、技術的な前提の抜け漏れも起こりがちです。各開発チームのセキュリティチャンピオン同士が直接つながり、失敗例も含む実例に基づいて知見を共有できれば、解決は速くなり、文脈に合った意思決定がしやすくなります。PSIRTはプラクティス等の知見の提供で支援し、実例 × プラクティスの両輪で効率的な課題解決を目指します。

この「開発チーム視点」と「他チームと連携」が従来のPSIRT中心の取り組みに加わることで、セキュリティが足かせにならない土台をつくれると考えています。

具体的にセキュリティチャンピオンがやることはシンプルで、「PSIRTと適切な頻度で連携し、課題を共有する」と「他チームと知見を共有する」の2点です。「それだけ？」と思うかもしれませんが、それだけで十分であり、これらがとても重要です。

ここからわかるとおり、セキュリティチャンピオンに一律の役割、タスクは設定していません。当初は「脆弱性トリアージ」や「インシデント対応」などの具体的な役割も想定しました。しかし、プロダクトごとに性質、開発チームの状況や注力するものが異なる中で、一律の役割を先に決めると使いにくく、かえって最適なトレードオフから遠ざかります。そこで一律の要件は最小限に抑え、まずは連携と課題共有に集中。状況が見えた段階で、PSIRTと開発チームでアクションを決め、実施します。ルールも体制も固定化せず、変化に合わせて更新していく前提です。

セキュリティチャンピオンのこれまで目指す世界

本取り組みは2025年1月に構想を開始し、3月に2チームでテスト運用を始めました。初期は、PSIRTがOWASPなどのドキュメントをもとに、セキュア開発に必要な活動を調査し、まとめた「プラクティスリスト」とそれに紐づく「学習コンテンツ」を起点に、各チームに取り組むプラクティスを選んでもらう形式でしたが、参加ハードルが上がるうえ、本質から外れる懸念があり、方針転換。前述のとおり、まずは「PSIRTと適切な頻度で連携し、課題を共有する」に役割を絞りました。

最初の2チームでは、リリースプロセスの改善や、自動診断ツールを活用した早期の脆弱性検知などをテーマに、PSIRTが伴走しながら進めました。その後、参加チームは拡大し、現在は8チームがこの枠組みで動いています。チームによっては数カ月に1度の定例のみという形もあり、状況に応じて無理のない始め方を選べています。

知見共有の取り組みとしては、セキュリティチャンピオン同士が集まる「チャンピオン会」を定期的に開催。まずは同期的な場で交流を増やし、将来的には非同期でも課題共有・解決が進む状態を目指します。加えて、活動の可視化と参加促進を狙った社内イベント「チャンピオン・カーニバル（仮）」も企画し、セキュリティチャンピオン以外のメンバーにもその活動の価値を伝えられる機会をつくります。

セキュリティチャンピオンは 2025年11月中に本運用開始予定です。テスト運用は「仕組みがスケールするか」の測定を主目的としていたため、本運用といっても進め方が大きく変わるわけではありません。枠組みの価値を広げ、より多くのチームで「そのチームにとっての最適なセキュリティ体制」を実現していきます。

セキュリティチャンピオンの具体的なこれまでの活動

テスト運用中に各チームで実施した取り組みの例です。

脆弱性診断フローの最適化
過去に定めたフローが現在の開発スピードに合わず、ボトルネックになりつつあったため、実情に合わせてアップデートし、負荷の平準化や前倒しを図りました。
自動診断ツールの導入・検証
従来のPSIRTによる脆弱性診断だけでなく、開発チーム内での自動診断を併用し、早期に脆弱性を検知する仕組みを検討・試行しました。
再発防止の仕組みづくり
過去に発生した脆弱性を繰り返さないためのアクションを検討しました。
セキュアコーディングガイドラインの整備
実際に開発チームが利用している言語やフレームワークでのNG例を踏まえ、実装時に迷いにくい形でガイドラインを作成しました。
脆弱性トリアージ基準の横展開
サイボウズでは開発チームごとに脆弱性トリアージ基準を持っています。立ち上げて日が経たない開発チームでも他の開発チームのトリアージ基準を参考に自チームに合ったトリアージ基準を作成しています。

より詳細な取り組みは、kintone開発チームのセキュリティチャンピオンがブログにしています。ぜひご覧ください。 kintoneセキュリティチャンピオンをはじめました

その他の良い変化

それぞれの活動以外にもうれしい変化がありました。

セキュリティ学習の推進
PSIRTが推奨するセキュリティ学習プラットフォームや資格学習、PSIRT作成の教材を活用した自発的な学びが増えました。
セキュリティチャンピオン間の知見共有
想定より早い段階から、セキュリティチャンピオン同士の連携が自然発生しています。
セキュリティイベントへの参加促進
セキュリティチャンピオンが明確になったことで、PSIRTからセキュリティイベント情報をスムーズに展開し、参加につなげやすくなりました。