大規模環境における開発者のセキュリティ：CISOのための導入ガイド

ブログ

ガイド

5,000人以上のエンジニアが在籍する組織における開発者向けセキュリティの導入

執筆者

Mike Wilkes

公開日：

2026年5月6日

大規模なエンジニアリング組織は、自分たちの最大の問題は技術的なものだと信じがちだ。最新のツールの予算さえ承認されれば、すべてが解決するはずだと。最近では、お気に入りのLLMを活用した「バイブコーディング」こそが特効薬だという見方が主流となっている。しかし、大規模組織が抱える根本的な問題は、技術的な性質のものなどほとんどない。

私の経験上、これらはプロセスに起因する問題であり、その現れ方は両極端に分かれる。一方には、分析麻痺に陥り、会議やレビュー、合意形成型の設計を延々と繰り返すだけで、ほとんど成果を出せないチームがいる。もう一方には、「先を見ずに飛び込む」タイプの人々がおり、実行重視の姿勢が、内省を欠くために多くの自滅的な失敗を招いている。

組織のアクティブなコミッター数が5,000人を超える頃になると、セキュリティ変革の性質は一変します。ツールが制約要因ではなくなります。予算も制約要因ではなくなります。人材さえも制約要因ではなくなります。そこで不足し始めるのが、組織全体の足並みを揃えることです。

現実には、企業がこの規模に達する頃には、すでに機能するセキュリティ体制、明確なリスク許容度、そして一般的な人員配置比率に基づいて構築されたセキュリティ組織が整っているものです。一般的な目安として、エンジニア100人につきセキュリティ担当者が1人という割合が挙げられます。つまり、開発者が5,000人いる企業であれば、50人のセキュリティチームが、1日に数千件ものソフトウェアに関する意思決定に影響を与えようとしていることになります。問題は、セキュリティ体制が存在するかどうかではありません。問題は、それがスケールするかどうかです。

この記事では、この規模の組織内で開発者向けセキュリティプログラムを展開する過程で得られた教訓と、その成功への道筋が、多くのCISOが想定しているものとは大きく異なる理由について概説する。

なぜエンタープライズ規模での開発者向けセキュリティ導入は失敗するのか

セキュリティ対策の導入が失敗する理由は、驚くほど単純なものです。それは、文化の変革ではなく、ソフトウェアの導入のように設計されているからです。セキュリティ担当者は往々にして、適切なツールの組み合わせ（例： SAST、 SCA、コンテナスキャン、シークレット）を十分に広範囲に導入すれば、成果が向上するという前提から始めることが多い。しかし、ツールの導入は簡単な部分である。

難しいのは、エンジニアリング組織内での優先順位付けです。開発者はすでに、スプリント期間内に完了できる量を超える仕事を抱えています。バックログの優先順位付けは、製品の納期に左右されがちです。機能開発のスピードは目に見えやすく、評価の対象となります。一方、セキュリティ修正は、抽象的で外部から押し付けられたもののように映ることが多いのです。そのような環境にセキュリティプログラムが導入されると、その反応は予想通りです。セキュリティ関連のチケットが作成され、バックログに追加され、やがて静かに積み重なっていくのです。

スキャンによるカバレッジの拡大は、この現実を変えるものではありません。実際、責任の所在が明確でないまま発見事項が増えれば増えるほど、状況は悪化するばかりです。セキュリティチームは、可視性を高めることでリスクを低減していると信じがちですが、実際には管理されていないリスクを増幅させてしまうこともあります。なぜなら、問題が存在することは誰もが知っているものの、実際にその責任を引き受ける者がいないからです。

‍

5,000人以上のエンジニアを抱える組織が直面する厳しい制約

大規模なエンジニアリング組織は、小規模な企業ではめったに遭遇しない一連の構造的な制約の下で運営されています。第一に、SDLC（ソフトウェア開発ライフサイクル）の断片化が挙げられます。数千人のエンジニアを抱える企業では、ほぼ間違いなく複数の開発ライフサイクルが同時に進行しています。毎日デプロイを行うチームもあれば、四半期ごとにデプロイを行うチームもあります。また、10年前に構築されたレガシーシステムに依存しているチームもあり、そのシステムは「完全に機能しなくなり、自分の責任問題になる」ことを恐れて、誰も手を出そうとしません。第二に、技術の異種混在があります。典型的なエンタープライズ環境には、数十種類のプログラミング言語、複数のCI/CD 、いくつかのインフラストラクチャプラットフォーム、そしてクラウドネイティブとレガシーのワークフローが混在している場合があります。

ある環境では見事に機能するセキュリティツールも、別の環境では導入がほぼ不可能である場合があります。第三に、一元的な強制力が限定的であり、組織のアプリケーションやクラウドの攻撃対象領域を網羅的に把握できる単一のシステムが存在しないのです。

たとえCISOが形式上はCIOやCTOの直属であったとしても、セキュリティチームが製品開発チームのバックログの優先順位を決定することはほとんどありません。影響を与えることはあっても、決定権は持っていないのです。このことが根本的な対立を生んでいます。

そして、最も危険なセキュリティ上の問題は、多くの場合、アーキテクチャの変更、依存関係のアップグレード、あるいは大規模なリファクタリングを必要とするものです。これらは、2週間のスプリント計画にすっきりと収まらないため、エンジニアが本能的に避けてしまうような作業なのです。

見積もりポイントが13ポイントを超えると見込まれるタスクは、往々にして無期限に先送りされがちです。これらは、チケットの体裁を装ったプロジェクトに他なりません。その結果、セキュリティ関連の作業がバックログとして積み上がり続けています。誰もが頭ではその重要性を理解しているものの、優先順位をつけるべきだという責任感や動機付けを誰も感じていないのです。

‍

第一の目標は「所有」であり、「報道」ではない

セキュリティ責任者が犯しがちな最も一般的な過ちの一つは、ツールの適用範囲が広がれば進歩につながると考えがちだということだ。すべてのリポジトリでスキャナーを実行すれば、見栄えの良いダッシュボードが生成されるかもしれないが、責任の所在が明確でなければ、そうしたダッシュボードは単なるリスク一覧に過ぎなくなる。真の進歩は、別の問いから始まる。

何が誰の責任で、誰が直すのか？

拡張性のあるセキュリティプログラムは、まずエンジニアリング組織内の「影響力のある人物」を特定することから始まります。それは、形式的なマネージャーでも、組織図上のアーキテクトでもありません。実際にエンジニアリングの在り方を形作っている開発者たちのことです。大規模なエンジニアリング組織には、必ずこうした人物が存在します。彼らは組織の文化を体現するエンジニアや開発者であり、他のメンバーがアーキテクチャに関する決定を下す前に相談する相手です。驚くほど効果的なアプローチの一つが、「トレーナー育成モデル」です：

組織全体で高く評価されている優秀な開発者を10名選定する
セキュア開発の実践について徹底的に指導する
100人のエンジニアリング・チャンピオンを育成させる
これらのチャンピオンは、それぞれ50人の開発者からなる自身のチームに影響を与えています

数週間のうちに、セキュリティチームが全員に直接トレーニングを行う必要なく、セキュリティ対策が数千人のエンジニアに広まります。大規模な環境では、同僚からの信頼を通じて影響力が広がっていきます。

CISOがパイロットチームを選定する方法（そして、なぜ多くのパイロットプロジェクトが誤った方向へ導くのか）

多くの企業のセキュリティプログラムは、パイロット事業から始まります。理論上は理にかなっています。しかし、パイロット事業の選定方法によっては、結果が誤った方向へ導かれてしまうことがよくあります。

セキュリティ責任者は、多くの場合、次の2種類のチームのいずれかを選択します：

最も経験豊富なエンジニアリングチーム
参加に最も意欲的なチーム

どちらも人為的に良好な結果を生み出してしまう。高パフォーマンスなチームは、すでに堅実なエンジニアリングの基盤を築いている。依存関係の更新は常に最新であり、CI/CD 最新鋭で、アーキテクチャも積極的にメンテナンスされている。こうした環境にセキュリティツールを導入すれば、確かに素晴らしい指標が得られるが、同時に「展開がスムーズにスケールする」という危険な錯覚も生み出してしまう。現実が露呈するのは、展開がレガシーサービスや人員不足のチーム、あるいは何年も実質的な更新が行われていないシステムに及んだ時である。

より優れたパイロット選定手法は、意図的に代表的な複雑さを組み込むものである：

従来のサービス
現代的なクラウドネイティブチーム
急成長中の製品グループ
動きの遅い内部プラットフォーム

パイロット事業の目的は、問題点を早期に発見することです。

大規模な展開に適した4段階の導入モデル

成功している開発者向けセキュリティプログラムは、一貫した導入パターンに従う傾向があります。意図的にそうしていることはめったにありませんが、経験豊富なCISOは、最終的には同じモデルに落ち着くことになります。

フェーズ1：監視のみ（取り締まりなし）

第1フェーズでは、可観測性に重点を置きます。セキュリティツールはリポジトリやインフラストラクチャ全体で稼働しますが、ビルドやデプロイをブロックすることはありません。検出された問題は可視化され、分類・分析されます。この段階は、セキュリティチームが以下の重要な疑問に答えるのに役立ちます：

どの脆弱性が最も頻繁に発生しますか？
どのチームが迅速に対応してくれるでしょうか？
どのような種類の修正が最も抵抗を生むのでしょうか？

これを学びの機会と捉えてください。

‍

フェーズ2：開発者からのフィードバックループ

次に、開発者の関与が重要です。調査結果は、エンジニアが実際にアクションを起こせる形で提示されます。誤検知は徹底的に排除され、ドキュメントは改善され、修正事例が共有されます。この段階では、内発的動機付けも導入されます。開発者はトップダウン式の強制にはあまり良い反応を示しませんが、問題解決の課題には積極的に取り組むものです。一部の組織では、是正作業をゲーミフィケーション化し、スプリントごとに解決したセキュリティ課題の数に基づいてチーム間で競わせることで成功を収めています。エンジニアが自発的に課題の修正に取り掛かり始めたとき、そのプログラムが機能し始めていることがわかります。

フェーズ3：ガードレールとポリシー

開発者がシステムを信頼して初めて、強制メカニズムが登場します。これらは通常、ガードレールという形をとります。例としては、次のようなものがあります：

新しい依存関係における重大な脆弱性を修正
リポジトリへの「シークレット
ベースイメージに対する最小パッチレベルの適用

重点は、過去の過ちを罰することではなく、新たなリスクを未然に防ぐことに置かれている。「何を」行うかだけでなく、「なぜ」行うのかという視点も併せて持つ必要がある。そうしなければ、脆弱性や設定ミスを対象とした「モグラたたき」の高度化・加速版をただ繰り返しているだけになってしまうからだ。

‍

フェーズ4：経営陣の責任

最終段階では、リーダーシップの可視化が導入されます。エンジニアリングリーダーシップのダッシュボードには、以下の指標が表示されます：

是正までの時間
頻繁に見られる脆弱性
セキュリティの未処理案件の推移

この段階に至ると、セキュリティはエンジニアリングのパフォーマンスに関する議論の一部となる。そして、その時点で、文化的な変革がはっきりと実感できるものとなり、定着していくのである。

導入初期に導入すべきでないもの（およびその理由）

セキュリティ対策の導入を頓挫させる最も早い方法は、時期尚早な適用です。初期段階でよく見られる失敗には、次のようなものがあります：

ブロッキング脆弱性に基づいて行われる
パッチ適用期限の全社的な義務化
グローバルな重大度ポリシーの適用

こうした措置は断固としたもののように感じられますが、しばしば逆効果を招きます。エンジニアが、自分たちが求めてもいないツールによってデプロイが突然ブロックされると、すぐに回避策を見つけ出します。スキャナーを無効にしたり、パイプラインを分岐させたり、アラートを無視したりするのです。その結果、セキュリティは悪化し、エンジニアリングチームとセキュリティチームの関係も損なわれてしまいます。強制よりも先に、受け入れがなければなりません。制御よりも先に、信頼がなければなりません。

実際の普及を示す指標

セキュリティダッシュボードは、往々にして重要でない数値に焦点を当てがちです。脆弱性の件数、完了したスキャン、あるいは分析されたリポジトリの数は可視化には役立ちますが、行動の変化についてはほとんど何も語ってくれません。

より有意義な指標としては、次のようなものがあります：

是正率：開発者は実際に指摘事項を解決しているのか？是正率の上昇は、通常、関与度の高まりを示している。
修正までの時間：重大度の高い問題はどれくらいの速さで修正されるのか？健全な開発者セキュリティ文化が根付いている組織では、重大な修正が数週間ではなく、数日以内に完了することが多い。
繰り返し見られる傾向：同じ脆弱性が繰り返し発生しているか？もしそうなら、問題は修正策そのものではない。開発者の教育やアーキテクチャの設計にある。
関与の低下を示す兆候：障害発生の最も早期かつ重要な前兆としては、開発者がシステムを放置したり、修正やコードコミットへのリンクなしにチケットを閉じたりすること、アラート疲れ、および是正措置の実施が急激に減少することなどが挙げられます。

‍

セキュリティプログラムの導入がうまくいかない場合

綿密に計画された導入でも、予期せぬ問題に直面することがあります。経験豊富なセキュリティ責任者は、こうした兆候を早期に察知します：

未解決案件の増加ペースが、解決ペースを上回っている
エンジニアによるスキャンツールの回避
セキュリティ推進派の影響力が低下している

このような状況になると、つい規制を強化したくなるものですが、それはほとんどの場合、誤った対応です。その代わりに、優れたCISOは一旦立ち止まり、次の3つの問いを自問します：

一度に多くの問題を取り上げすぎているのでしょうか？
開発者には、明確な是正措置の指針が示されているか？
本当に重要な脆弱性を優先的に扱っているだろうか？

この最後の質問は、大規模なセキュリティプログラムにおける最も重要な原則の一つへとつながります：

ここにはパレートの法則が当てはまります：多くの環境において、脆弱性の約20％が、組織が直面する実際のリスクの80％を占めています。こうした影響の大きい問題に焦点を当てたセキュリティ対策は、開発者の負担を最小限に抑えつつ、リスクを劇的に低減します。一方、すべてを同時に修正しようとする取り組みは、その重みに耐えきれず破綻してしまいます。

SDLCへのセキュリティ思考の組み込み

長期的な開発者向けセキュリティプログラムは、最終的には上流工程へと移行します。組織は、脆弱性に事後対応するのではなく、設計や開発の段階でそれらを未然に防ぐようになります。

この変革において最も効果的な手法の一つが、脅威モデリングです。多くの開発者は、スキャナーが問題を検知して初めてセキュリティの問題に直面します。彼らはルールを覚えるだけで、その根拠までは理解していません。脅威モデリングは、こうした状況を根本から変えるものです。

これにより、開発者は以下の点を理解しやすくなります：

セッションストレージの選択が重要な理由
認証パターンがどのように攻撃対象領域を生み出すか
なぜOWASP Top 10の問題が繰り返し発生するのか

エンジニアが「なぜ」を理解すれば、セキュリティ対策を一つの外部からの要求として捉えることはなくなり、そうした問題を根本から回避するシステムの設計を始めるようになります。経験豊富なエンジニアと若手開発者をペアで組ませることで、この学習プロセスはさらに加速します。ベテラン開発者は、ドキュメント作成の徹底、自動テスト、安全なインフラ構成といった習慣を自然と後輩に伝授します。セキュリティは、単にコードをスキャンすることではなく、エンジニアがコードを書く際の考え方にこそ本質があるものとなるのです。

大規模な成功を左右する唯一のルール

数多くの開発者向けセキュリティプログラムの成否を見てきたが、その結果を左右する原則は常に一つだ。それは、セキュリティは開発者の認知的負荷を増大させるのではなく、軽減しなければならないということである。

セキュリティツールが過剰なノイズ発生させると、エンジニアは関心を失います。修正手順が不明確だと、エンジニアは修正を先延ばしにします。信頼が築かれる前に強制的な措置が取られると、エンジニアは制御を回避します。しかし、セキュリティツールが：

是正措置を要する指摘事項
有意義なリスクを優先する
既存のワークフローに組み込む

開発者たちはいつものように対応し、問題を解決する。

そして、十分な数の人がその問題を解決し始めると、驚くべきことが起こります。セキュリティが習慣となるのです。

そして、5,000人のコミッターを抱える組織においては、習慣こそが最終的に会社全体のセキュリティ体制を左右するのです。

‍

これらの教訓は、次のような現代の開発者向けセキュリティプラットフォームの設計思想に多大な影響を与えました Aikidoのような現代の開発者向けセキュリティプラットフォームの設計思想に多大な影響を与えました。これは、開発者の認知的負荷を最小限に抑えつつ、重要なリスクを可視化するように構築されたシステムです。

最終更新日:

2026年5月7日

共有: