近年、クラウド活用、アジャイル開発、マイクロサービスの普及により、システム開発のスピードはかつてないレベルに達しています。開発環境は自動化が進み、リリースサイクルは週単位どころか数日というものまで現れています。サービス改善のスピードが競争優位そのものとなり、迅速な開発は企業にとって不可欠な能力になりつつあります。
このような状況において、従来のように「後工程でまとめてセキュリティチェックを行う」方式では完全に追いつけません。特に日本企業に多い外注モデルでは、テスト工程で重大な脆弱性が大量に発覚し、リリース直前にプロジェクトが危機に陥るケースも珍しくありません。
そのため、「開発プロセスを後ろから守る」のではなく、「プロセスそのものを安全にする」アプローチが必要になります。
その解として位置づけられるのが DevSecOps です。
DevSecOps は高速開発におけるセキュリティ確保のために登場したものですが、従来型の開発に対しても適用可能です。セキュリティが後工程に追いやられ、設計や製造の段階で十分に考慮されない課題は、開発が高速であるかどうかに関わらず、多くの企業・組織に存在しているのではないでしょうか。
DevSecOps は、高速開発を行う一部の企業・組織のための手法ではなく、あらゆる組織が取り入れるべき「次の当たり前」として注目すべき手法なのです。
目次
DevSecOps を理解するためには、まず DevOps の文脈を欠かすことができません。DevOps は、開発（Dev）と運用（Ops）の分断を解消し、「継続的に価値を早く届ける」ための手法です。インフラの自動化、CI/CD（Continuous Integration / Continuous Delivery）と呼ばれるコードを作り、動く形にまとめ、テストし、リリースするまでの流れを自動で進める仕組み、アジャイル開発、運用監視の統合などによって、ソフトウェア開発のスピードを大きく引き上げました。
しかし、高速化が進むほどセキュリティはボトルネックとなっていきました。
つまり DevOps が「高速化」を実現した一方で、「安全な高速化」を実現する構造までは整備されていなかったのです。そこで生まれたのが DevSecOps です。DevSecOps は DevOps の高速サイクルにセキュリティを統合し、スピードと安全性を両立させるための進化なのです。
DevSecOps というと、セキュアコーディングや SAST（静的解析：コードを解析し脆弱性を検出する）ツールなど技術的な項目を思い浮かべる方も多いと思います。確かに技術は DevSecOps を実現するうえで重要なピースですが、「思想」「技術」「人」の三軸が相互に補完することで、さらなる効果が期待できます。
Security by Design（SbD） は 、「 企画・設計段階からセキュリティを組み込む」という思想です。この SbD の取り組みの一つに設計を全社的に標準化する枠組みであるエンタープライズアーキテクチャ（EA）があります。EAによって認証、ネットワーク構造、ログ設計、バックアップやセキュリティ機能等の非機能要件を統一することで、プロジェクトごとのばらつきを減らし、セキュアな設計が自然と選ばれる環境を整備します。
Shift Left は、「できる限り上流（左側）の工程でセキュリティを確保し、修正コストと影響を最小化する」という方針です。
SbDやEA、Shift Left といった思想や方針をベースに、DevSecOpsを実装していくことで、開発全体においてセキュリティを確保する持続可能な仕組みを作り上げていくことができます。
アプリケーション、パイプライン（コードを作り、動く形にまとめ、テストし、リリースするまでの流れ）、環境構成、実行基盤、テストといったソフトウェアライフサイクルの各レイヤーに対して、セキュリティを「自動化」「 コード化」「 標準化」します。代表的な技術には以下があります。
これらの技術を、コードを記述するように自動化し、開発ライフサイクルの中に統合する手法をSecurity as Code (SaC)と呼んでいます。
DevSecOps は技術だけでは実現せず、最終的には人材が成否を決めます。
まず重要なのは、「セキュリティを理解し自分ごとにする開発者」です。SAST や SCA などのツールの指摘内容を理解しリスクを判断、自ら改善できる人材が開発チームに在籍しているとセキュリティ品質は飛躍的に向上します。欧米ではこのような人材を「セキュリティチャンピオン」と呼び、高く評価しています。
次に、「開発を理解するセキュリティ人材」です。パイプラインやIaC、クラウドの責任分界点などを理解し、現場が守れるルールや仕組みを提供する役割を担います。
これら三つの軸がそろうことで、DevSecOps の効果は単なる足し算ではなく、相乗効果として現れてきます。
日本企業では、システムの製造工程を外部パートナーに委託するケースが多く、DevSecOps の実践に特有の難しさがあります。外注先の開発体制や利用ツールは多様であり、自社のツールをそのまま押し付けることはできません。しかし一方で、外注先の現場任せにしてしまうと、セキュリティ要件が設計段階で反映されず、テスト工程で重大な脆弱性が一気に発覚する構造的問題が生じます。したがって、外注モデルでは「強制」ではなく「合意」と「受け入れ基準」の工夫によって DevSecOps を実現するアプローチが必要になります。
具体的には、契約段階でセキュリティ要件を明確化し、コーディング規約や利用してよいライブラリの基準を提示する方法があります。また、納品物には SAST の解析結果等の提出を求め、脆弱性の重大度と修正方針をセットで報告してもらうことで、テスト工程での手戻りを大きく減らせます。さらに、納品後すぐに受け入れ側で DAST を実施し、外部からの攻撃耐性を確認するなど「受け入れテストにセキュリティを組み込む」ことで、外注先の体制に依存しない防御線を構築することができます。
攻撃を受けたネットワークにOA系のシステムや端末が接続されていると、OA端末やメールやファイルサーバが使えなくなり、社内のコミュニケーションですらおぼつかない状況となります。その為、OA系システム停止時の代替策を整備しておくことが望ましいです。最近ではメールやファイルサーバ、掲示板等にSaaSを利用しているケースが増えていますので、上手く活用するといいのではないでしょうか。
実際、ある事例では、社員食堂をシステム化していたため、ネットワークの遮断と全サーバの停止によって社員食堂が使えなくなったそうです。その事例では、メニューをカレーのみとしてサービスを継続されたとのことですが、ランサムウェア攻撃の影響の大きさを実感したエピソードとして印象に残っています。
クラウドとOSS、外注モデル、高速開発、複雑化する脅威という現実の中で、従来の後付け型セキュリティは限界に達しています。DevSecOpsは、
を統合し、組織が「安全に高速で開発できる状態」を継続的に実現するためのアプローチです。
今や、開発・運用・インフラ・データ活用・AIなど、あらゆる領域が密接に関連するようになり、セキュリティは特定の専門部署だけの領域ではありません。すべての部署の一人ひとりの判断と行動の積み重ねによって、組織全体の安全が形づくられる時代です。
DevSecOps は、もはや「高度な選択肢」ではなく「次の当たり前」であり、組織の信頼性、継続的成長、サービスの競争力を支える基盤として、積極的に取り組む価値のあるテーマではないでしょうか。