平成の組織体制では、令和のセキュリティ運用に耐えられない
はじめに
DevSecOpsが当たり前になった令和のシステム運用では、開発部署とセキュリティ専門部署の関係を見直す必要があるのだ。
かつては、開発部署がシステムを作り、セキュリティ専門部署が後から確認する体制でも、ある程度は回っていた。リリース頻度は今ほど高くなかった。インフラ変更も限定的だった。セキュリティ確認も、開発工程の終盤や本番移行前にまとめて実施する形が多かった。
しかし、現在のシステム開発と運用は大きく変わっている。クラウド設定は日々変わる。OSSライブラリは継続的に更新される。CI/CDにより、変更は短いサイクルで本番環境へ届く。AIによってコードや設定の生成速度も上がっているのだ。
GitLabの2024年調査では、67%の回答者がソフトウェア開発ライフサイクルはほぼ、または完全に自動化されていると回答している。また、67%の開発者が、自分たちの扱うコードの4分の1以上はOSSライブラリ由来だと回答している。これは、開発現場の速度と依存関係の複雑さが、すでに従来型の管理方法を超えつつあることを示している。1
この環境では、セキュリティを最後にまとめて確認する発想そのものが古くなっているのだ。
平成型の組織体制とは何か
ここでいう平成型の組織体制とは、開発部署がセキュリティを自分たちの責任として扱わず、セキュリティ専門部署が後から確認し、指摘し、場合によっては修正方針まで面倒を見る体制である。
この体制では、開発部署は「セキュリティは専門部署が見るもの」と考える。設計上のリスクも、脆弱性診断の結果も、クラウド設定の問題も、最終的にはセキュリティ専門部署が判断するものになる。
一方で、セキュリティ専門部署は、レビュー、診断、例外判断、脆弱性対応、監査対応、教育、ルール整備、経営報告まで抱えることになる。この状態は、一見すると手厚い。しかし、実態としては危ういのだ。
- 開発部署にセキュリティ判断の力が育たない
- セキュリティ専門部署に案件が集中する
- レビュー待ちが増える
- 例外判断が滞留する
- 脆弱性対応が後手に回る
その結果、開発速度もセキュリティ品質も落ちる。
DevSecOpsはセキュリティ部署が頑張ることではない
DevSecOpsとは、単にSAST、SCA、SBOM、IaCスキャンなどのツールを導入することではない。DevSecOpsの本質は、セキュリティを開発と運用の流れに組み込むことにあるのだ。
NISTのSecure Software Development Framework（SSDF）も、セキュア開発のプラクティスを個別の特別工程として扱うのではなく、各組織のSDLCへ統合することを推奨している。2
OWASP SAMMも、ソフトウェアセキュリティを「Governance」「Design」「Implementation」「Verification」「Operations」の5つの機能に分けて整理している。これは、セキュリティが診断工程だけの話ではなく、組織運営、設計、実装、検証、運用の全体に関わる活動であることを示している。3
つまり、DevSecOps時代のセキュリティは、専門部署だけで完結しない。システムを作る人たちが、自分たちの設計、コード、依存関係、クラウド設定、運用手順に含まれるリスクを理解し、日々の判断に組み込む必要があるのだ。
開発部署に求められるのは専門家になることではない
ここで誤解してはいけない。開発部署がセキュリティ専門部署と同じ知識を持つ必要はない。全ての脆弱性に精通する必要もない。高度な攻撃手法を自力で分析できる必要もない。
しかし、自分たちが作るシステムのリスクを説明できない状態は問題である。たとえば、次のことを開発部署が整理できない状態は危ういのだ。
- この機能では、どの情報資産を扱うのか
- どの入力値が信頼できないのか
- 認証、認可、ログ、暗号化はどの設計になっているのか
- 利用しているOSSやコンテナイメージに既知脆弱性はあるのか
- 脆弱性が見つかった場合、どの範囲に影響するのか
- 修正できない場合、暫定対策と期限は何か
- 例外を認める場合、誰がどのリスクを受け入れるのか
これらを全てセキュリティ専門部署が整理しているなら、その組織は自走できていない。セキュリティ専門部署が判断材料を作り、開発部署がそれを待つ。この関係が固定化すると、セキュリティは開発の外側に置かれ続ける。
その状態では、DevSecOpsは形だけになるのだ。
セキュリティ専門部署の役割も変わる
令和型の組織では、セキュリティ専門部署の役割も変わる。全ての案件の面倒を見ることが役割ではない。全社で使える基準を作ること、安全な設計パターンを整備すること、判断に迷う場面で助言すること、重要なリスクに対して独立した視点で確認すること、現場が自走できるように仕組みを作ることが役割になるのだ。
The Institute of Internal AuditorsのThree Lines Modelでも、リスク管理の責任は事業や業務の実行に近い側にあり、専門部署は支援、監視、牽制、専門的助言を提供する役割として整理されている。4
金融庁の主要行等向け監督指針でも、オペレーションの実行部門、リスク管理部門、内部監査部門などの役割を用いて、十分な牽制機能を発揮する態勢の整備が求められている。5
セキュリティ専門部署が現場の作業を抱え込みすぎると、この牽制機能は弱くなる。本来は、現場が自分たちでリスクを整理し、専門部署がそれを確認し、必要に応じて指摘する形が望ましい。
専門部署が設計の穴を探し、修正案を書き、例外理由まで整える状態は、親切ではある。しかし、それが常態化すると、組織全体のセキュリティ能力は育たないのだ。
令和のセキュリティは仕組みで支える必要がある
開発部署に「セキュリティを意識してください」と言うだけでは変わらない。チェックリストを配るだけでも足りない。年1回の研修だけでも足りない。本番移行前のレビューだけでも足りない。
必要なのは、日々の開発フローの中にセキュリティを組み込むことなのだ。たとえば、次のような仕組みが必要になる。
- CI/CDにSASTやSCAを組み込む
- 危険度の高い検出だけをブロック条件にする
- 低リスクの検出はバックログ化して管理する
- 標準のアプリケーションテンプレートを用意する
- 認証、認可、ログ、暗号化の標準部品を用意する
- クラウド設定をIaCで管理する
- IaCスキャンで危険な設定を検出する
- SBOMで利用コンポーネントを把握する
- コンテナイメージやベースイメージの更新ルールを決める
- 例外には理由、期限、責任者を設定する
OpenSSFのSLSAは、ソフトウェア成果物の来歴、ビルド、改ざん耐性などを段階的に高めるためのガイドラインである。これは、現代のセキュリティがアプリケーションコードだけでなく、ビルド環境、依存関係、成果物の信頼性まで含むことを示している。6
このような領域まで考えると、セキュリティ専門部署が後から全てを確認する方式は現実的ではない。開発と運用の中に、最初からセキュリティの仕組みを入れる必要があるのだ。
平成型のままではセキュリティ部署が詰まる
平成型の組織では、セキュリティ専門部署が常に詰まる。
- 新規案件のレビューが来る
- クラウド設定の相談が来る
- 脆弱性診断の結果確認が来る
- WAFの例外申請が来る
- OSS脆弱性の影響調査が来る
- 監査対応の証跡確認が来る
- インシデント時の暫定対策相談が来る
これらを少人数の専門部署で受け続ければ、処理能力にはすぐ限界が来る。しかも、セキュリティの仕事は増え続けているのだ。
クラウド、SaaS、API、コンテナ、Kubernetes、OSS、SBOM、AI、サプライチェーン、ゼロトラスト、データ保護、プライバシー、規制対応。対象は広がる一方である。
金融庁と日本銀行のサイバーセキュリティセルフアセスメントでも、サイバー攻撃の高まりを背景に、サイバーセキュリティ管理態勢の整備と実効性確保が経営上の重要課題とされている。7
つまり、セキュリティは一部の専門部署だけが頑張ればよいテーマではなくなっている。経営、開発、運用、インフラ、監査、調達、法務、委託先管理まで含めた組織能力の問題になっているのだ。
必要なのは責任の押し付けではなく責任の再設計である
DevSecOpsを進めるときにありがちな失敗がある。それは、セキュリティ専門部署の仕事を開発部署へ丸投げすることである。
「これからはDevSecOpsなので、開発側で見てください」
これではうまくいかない。開発部署には、判断できる材料が必要である。使いやすい基準が必要である。自動化された検査が必要である。安全なテンプレートが必要である。迷ったときに相談できる窓口が必要である。例外を処理する明確なルールが必要なのだ。
一方で、開発部署も「専門部署が見てくれるからよい」という姿勢から脱却する必要がある。
- 自分たちが作るもののリスクを、自分たちで説明する
- 検出された脆弱性の影響を、自分たちで一次評価する
- 修正しない場合は、理由と期限を明確にする
- 例外を積み上げた結果、どのリスクが残るのかを把握する
この関係に変わらなければ、DevSecOpsは単なるスローガンで終わるのだ。
令和型の組織に必要な状態
令和型の組織に必要なのは、セキュリティ部署が全てを確認する体制ではない。
開発部署が、日々の開発と運用の中でセキュリティを扱える状態である。セキュリティ専門部署が、全社の基準、仕組み、教育、助言、監視を通じてそれを支える状態である。重要なリスクについては、専門部署が独立した視点で確認できる状態である。
この状態を作るには、次の転換が必要なのだ。
| 平成型 | 令和型 |
|---|---|
| セキュリティは後から確認する | セキュリティは作る過程に組み込む |
| 専門部署が全件を見る | 開発部署が一次的に判断する |
| レビュー依頼を待つ | CI/CDや標準テンプレートで常時支える |
| 例外判断が属人的 | 例外の理由、期限、責任者を管理する |
| 脆弱性対応が都度判断 | 重要度、影響範囲、期限をルール化する |
| 教育は年1回 | 開発フローの中で学べる形にする |
| セキュリティ部署が火消しする | セキュリティ部署は仕組みを改善する |
この転換は、単なる組織論ではない。セキュリティ対策の速度を上げるための現実的な方法である。
結論
平成型の組織では、セキュリティは「後から見てもらうもの」だった。令和型の組織では、セキュリティは「作る過程に最初から含めるもの」である。
DevSecOpsとは、セキュリティ専門部署の仕事を開発部署へ丸投げすることではない。開発部署が自分たちのリスクを扱えるようにし、セキュリティ専門部署がそれを支える仕組みを作ることなのだ。
開発速度は上がっている。クラウド環境は変化し続けている。OSSとサプライチェーンのリスクは増えている。AIによって、コードと設定の生成速度もさらに上がる。
この状況で、セキュリティ専門部署が後追いで全てを見る体制には限界がある。必要なのは、専門部署の努力量を増やすことではない。組織全体でセキュリティを扱えるように、責任、仕組み、判断基準を再設計することである。
平成の組織体制では、令和のセキュリティ運用に耐えられない。この前提に立てるかどうかが、これからのセキュリティ成熟度を分けるのだ。