DevSecOpsとは？ソフトウェアの開発・運用・セキュリティ対策をONE TEAMで

DevSecOpsとは、ソフトウェア開発運用プロセスであるDevOpsに、セキュアソフトウェア開発ライフサイクル（Secure Software Development Lifecycle; Secure SDLC）の概念を導入したソフトウェアの開発運用プロセスです。

一般に、DevSecOpsのプロセスは図 1のような八の字型のプロセスループで表現されますが、この図が示すように、ソフトウェアの開発サイクルと運用サイクルが一体となってライフサイクルを形成し、そのライフサイクル全般に渡ってセキュアなソフトウェアの開発運用に関する活動が実施されます。

DevSecOps（デブ・セック・オプス）という呼称は、もともと、開発（Dev）と運用（Ops）を統合したDevOpsに、さらにセキュリティ（Sec）も統合するという経緯でつくられました。当初は、DevOpsSec、SecDevOpsなど、Secの位置が最後についたり、最初につく呼び方（設計や実装の工程からセキュリティを考慮すべきという「シフト・レフト」の考え方を意識した呼び方）がありましたが、現在は、開発と運用の両方にまたがって全方位的にセキュリティ対策を実施するという意図から、DevSecOpsという、DevとOpsにSecが挟まれた呼び方が定着しています。因みに、顧客満足度向上のためのビジネス戦略（Biz）の機能もDevSecOpsに加えるべきとの考えからBizDevSecOps（ビズ・デブ・セック・オプス）といった呼び方も登場し、どんどん長い名前になってきています。 

DevSecOpsそのものの解説に入る前に、まず、DevSecOpsが生まれた背景でもある、ソフトウェア開発プロセスの歴史を簡単に振り返ってみましょう。 

1980年代に生まれたウォーターフォール型の開発プロセスモデルは、上流から下流に流れる「水流（Waterfall）」のようなプロセスです（図 2）。現在でも要件定義や設計の工程を「上流工程」、テストやリリースの工程を「下流工程」と呼ぶことがありますが、これらの用語はウォーターフォール型開発の概念から生まれたものです。 

この開発手法では、「要件定義・設計」、「実装」、「テスト」などの開発フェーズはそれぞれ専門チームに分業化されており、設計チームが入念に実施した要件定義と設計に基づいて実装チームがコーディングし、実装チームが作成したソフトウェアをテストチームがテストするという形で、上流から下流に向けて開発が進められていきます（基本的に後戻りはありません）。そして、サービス提供を伴うソフトウェアであれば、リリース後、「運用チーム」に引き渡され、ITサービスマネジメントに基づくサービス運用がおこなわれます。 

このウォーターフォール型開発は、分業型のソフトウェア開発体制が定着している企業では、現在でも採用されていますが、各フェーズ間での調整や次工程への引き渡しのための文書作成にコストや時間を要するため、リリースサイクルが数ヶ月におよんでしまい、変化の激しい顧客ニーズに対応した仕様の変更や追加が迅速におこなえないデメリットがあります。 

上記で述べたようなウォーターフォール型の開発モデルがもつデメリットを改善するため、少人数のチームで、計画、設計、実装、テスト、リリースのサイクルを短期間で回し、段階的に機能拡張しながら本番環境にデプロイしていくアジャイル開発を採用するケースが増えていきました。（図 3） 

この方式により、リリースサイクルは数週間単位と短くなり、変化の激しい顧客ニーズに対応した仕様の変更や追加に柔軟に対応できるようになりましたが、依然として開発チームと運用チームは分業化されていたため、頻繁な仕様変更や機能追加が発生すると、その都度、運用オペレーションの変更が運用チームに強いられるという新たな問題が生じることになりました。 

アジャイル開発における、開発チーム（Dev）と運用チーム（Ops）間での調整コストを排除するため、開発と運用の機能をONE TEAM化し、さらには、インテグレーション（テストを含む）を自動化する「継続的インテグレーション」（Continuous Integration：CI）、デリバリーを自動化する「継続的デリバリー（Continuous Delivery：CD）」により、高速なソフトウェア開発を可能にする開発手法が、2007年～2008年頃に生まれました。これがDevOpsです。（図 4） 

この進化を後押しした要因としてソフトウェアアーキテクチャの進化がありました。旧来のサーバー・クライアント型や三層モデルに代表されるモノリシックアーキテクチャに代わり、コンテナやマイクロサービスなどのモダンアーキテクチャが登場したことにより、開発期間が大幅に短縮され、デプロイメントも小さな単位でおこなえるようになり、リリースサイクルは、数時間～数日にまで短縮させることが可能になりました。 

しかし、これほど高速に開発サイクルが回せるようになると、これまで社内のセキュリティチームや外部ベンダーに依頼していたソフトウェア開発におけるセキュリティ対策を、DevOpsの全サイクルに渡って実施することがむずかしくなってきました。 

そこで、いよいよ、DevSecOpsの登場となるわけです。 

前章ではDevSecOpsが誕生するまでのソフトウェア開発プロセスの進化について簡単に述べました。ここでは、DevSecOpsの特徴を、チームとプロセスという2つの側面から解説したいと思います。 

DevOpsにおいて、お客様への価値提供という共通の目標のもと、開発と運用を担当するメンバーが協力しあうのと同様、DevSecOpsにおいても、開発と運用のすべての活動に渡り、全員参加型のセキュリティ対策を実践することが求められます。つまり、DevSecOpsのチーム内では、要件定義と設計を担当するメンバー、実装担当者、テスト担当者、品質保証担当者、リリース担当者、サービス運用者、セキュリティエンジニアなどが、それぞれの担当業務に垣根を作らず、セキュリティ上の安全性の達成という共通目標とセキュリティレベルの維持に関する責任共有という高い意識のもと、ONE TEAMとなって緊密に協力しあうことが重要となります。 

また、上記のようなセキュリティを求心力とした緊密な共同作業を実現するためには、DevSecOpsのチーム内にセキュア開発運用を推進するリーダーが必要となります。そこで、「セキュリティチャンピオン（Security Champion）」と呼ばれる、以下のような役割を担う人を設置することが必要となります（※1）。なお、通常、このセキュリティチャンピオンはセキュリティエンジニアが担当することが望ましいですが、開発や運用を担当するメンバーのなかから、セキュリティに関する知見やスキルをもったメンバーが担当することもあります。 

※1：詳しくは、セキュリティチャンピオンのアサインと活動内容についてまとめたOWASP Security Champions playbook[1] を参考にすることをお勧めします。

DevSecOpsのプロセスは、計画／コーディング／ビルド／テスト／リリース／デプロイ／運用／監視という8つのフェーズで構成されますが、セキュアソフトウェア開発ライフサイクルの観点から、これらのフェーズで実施すべきセキュリティ施策を列挙すると表 1のようになります。ただし、ここに列挙するすべての施策を実施する必要があるということではなく、達成しようとするセキュリティレベル、実現しようとする自動化のレベル、アプリケーションの性質などに基づいて選択して実施します。 

なお、表 1の「ツール」列で丸印が付いている施策は、ツールによる自動実行が可能な施策を表しています。 

上記の表1に記載したセキュリティ施策のうち、主要なものについて表2に解説します。

表 2 主なセキュリティ施策の説明

※2： 脅威モデリングの実施方法の詳細については、参考文献[2] を参照してください。

DevSecOpsのプロセスは、図 1に示したような８の字型のループで表されますが、この過程をもう少し細かく見ていくと、図 5に示すような、ビルド、インテグレーション（テストを含む）、デリバリー、デプロイメントが、階層的なループプロセスを形成しています（ビルドされた複数のソフトウェアがインテグレーションされ、インテグレーションされた複数のアーティファクトがテスト環境やステージング環境にデリバリーされ、デリバリーされたアーティファクトの集合体が本番環境にデプロイメントされます）。これらの一連のプロセスのうち、継続的インテグレーション（CI: Continuous Integration）と継続的デリバリー（CD: Continuous Delivery）の部分は「CI/CDパイプライン」と呼ばれ、自動化ツール（CI/CDパイプラインツール）を用いて高速化されます。 

そして、DevSecOpsでは、このCI/CDパイプラインに前述の表 1の「継続的なビルド・インテグレーション・テスト」、「継続的なデリバリー・デプロイ」のカテゴリに列挙したようなセキュリティ施策をCI/CDパイプラインに組み込んで自動化することで、高速でセキュリティ上安全なソフトウェア開発が可能となります。 

なお、CI/CDパイプラインの部分でセキュリティ対策を実施するだけでは、セキュリティ上の安全性を確保することはできません。このため、設計や実装の過程に「セキュアな設計とアーキテクチャ」や「セキュアコーディング」のカテゴリで列挙したセキュリティ施策を組み込む（※3）と共に、ITサービス運用に「ランタイムの防御と監視」のカテゴリで列挙したセキュリティ施策を組み込むことがDevSecOpsのプロセスを回す上で必要となります。 

※3：設計工程からセキュリティ施策を実施する概念は「セキュリティ・バイ・デザイン」、「シフト・レフト」などと呼ばれます。

前節ではDevSecOpsで実施すべきセキュリティ対策について概説しましたが、これらの施策を実践するDevSecOpsの導入ステップについて述べたいと思います。DevSecOpsの導入ステップに定石のようなものはないので、ここでは、ウォーターフォール型開発、もしくはアジャイル開発を実践している組織が、もしDevSecOpsの導入を進めるとしたら、という仮定でモデルケースを考えてみたいと思います。 

例えば、もし、あなたがDevSecOps体制を構築せよと命ぜられたとしましょう。そのとき、最も優先すべきことは何でしょうか？ セキュリティ自動化ツールを導入して開発チームに展開することでしょうか？それとも、ソフトウェア開発運用プロセスのルールを策定して周知することでしょうか？ 

前述したように、DevSecOpsを実践する上で最も重要なことは、さまざまなスキルをもった開発運用メンバー全員が、セキュリティ上の安全性達成に関する目標と責任を共有し、ONE TEAMとなって活動できるようになることです。優先すべきことは、セキュリティ自動化ツールを導入展開することでも、ソフトウェア開発運用プロセスのルールを策定して遵守させることでもありません。このため、以下の表 3に示すように、パイロットプロジェクトでスモールスタートし、組織、人的スキル、ルール、技術の側面から段階的にステップアップしていく方法が望ましいと考えられます。 

DevSecOpsによるソフトウェア開発運用のプロセスが回り始めたら、そのサイクルのパフォーマンスを定常的に測定・モニタリングし、定期的に成熟度を測定して改善サイクルを回していくことがステップアップのために欠かせません。ここでは、これらパフォーマンスを測定するためのKPIと、成熟度評価モデルについて紹介したいと思います。 

DevSecOpsのパフォーマンスを測定する指標としては、表 4のようなKPIが考えられます。なお、DevSecOpsはDevOpsのプロセスにセキュリティの要素を組み込んでいるため、これらの指標のなかには、DevSecOps特有のものだけではなく、もともとDevOpsのパフォーマンス指標として使われるものも含まれています。 

DevSecOpsの成熟度を測る指標として、OWASP DSOMM（DevSecOps Maturity Model）[3] があります。DSOMMでは、表 5に示すような指標を用いて、それぞれ4段階でDevSecOpsに基づくソフトウェア開発運用の成熟度を評価します。なお、DSOMMのサイトでは、ウェブ上で各評価項目についての実施有無をチェックしていくと、成熟度を図 6に示すようなレーダーチャートで可視化する機能が提供されています。 

本コラムでは、DevSecOpsについて、ソフトウェア開発プロセスの発展の歴史、DevSecOpsの概要、導入プロセス、パフォーマンスと成熟度を評価する指標について説明してきました。ソフトウェア開発の現場では、セキュリティに知見のある人が少ない、開発コストの増加や開発期間の遅延につながる、などの理由からセキュアソフトウェア開発の実施は敬遠されがちですが、段階的にDevSecOpsに移行していくことにより、サイバーセキュリティ上の安全性を確保しながら、変化する顧客ニーズに迅速に対応した価値提供が可能となります。しかしながら、DevSecOpsは一朝一夕で実現することはむずかしいため、DevSecOpsの導入を進める場合は、できるだけ早くスモールスタートし、段階的に組織のなかに定着させていくことが重要であると考えます。 

DevSecOpsについてさらに詳しく知りたい場合は、Cloud Security Allianceによる「DevSecOpsの6つの柱」に関する一連の文書[4] や、米国国防総省（DoD）による「Enterprise DevSecOps」に関する一連の文書[5] を読まれることをお勧めします。 

[1]OWASP Security Champions playbook 
https://github.com/c0rdis/security-champions-playbook 

[2]SHIFT 「攻撃者の視点から設計上の弱点を洗い出す脅威モデリング」 知の再配分白書 Vol.3 
https://service.shiftinc.jp/resources/8102/

[3]OWASP DevSecOps Maturity Model (DSOMM) 
https://owasp.org/www-project-devsecops-maturity-model/ 

[4]Cloud Security Alliance, DevSecOps Working Group Publications 
https://cloudsecurityalliance.org/research/artifacts/?term=devsecops 

[5]DoD, DevSecOps Publications 
https://public.cyber.mil/devsecops/