「DevSecOps」、その言葉は2012年にGartner社が提唱し始めたと言われています。日本では2016年頃から各企業が注目し始め、NRIセキュアでも、筆者が現在所属しているDevSecOps事業部の設立やDevSecOpsに関連したテーマを取り上げた多くのブログを執筆してきました。
しかしながら、セキュリティコンサルタントとしてお客様の支援をしていると、日本企業においてはDevSecOpsが広く実践されているとは言い難い状況にあると思います。IPAが国内企業を対象に調査したデータ（ソフトウェア開発分析データ集2022）でも、「97.2%のプロジェクトがウォータフォール開発（従来通りの開発手法）を採用している」とあります。
これはなぜでしょうか？本ブログでは国内におけるDevSecOpsの普及に関して考察しつつ、その停滞を打破するためのアプローチを紹介をしていきます。
DevSecOpsの再定義
DevSecOpsの普及状況について考察する前に、まずはDevSecOpsという用語について再度整理しておきましょう。
DevSecOpsは「DevOpsにセキュリティを組み込んだもの」という説明がされていることが多いと思います。DevOpsとは一般的に開発と運用が一体となった体制・文化を指しますが、このDevOpsという言葉自体Twitterのタグから生まれたものとも言われており、決まった形は存在していません。
Gartner社が提唱する「DevOps：適切な導入に向けた8つのステップ」においても「自社のDevOpsを定義する」というステップが含まれています。つまりDevOpsは各組織に適した様々な形があり、各企業共通の決まった定義は存在していないのです。本ブログでの定義も「NRIセキュアが考えるDevSecOps」とご理解ください。
さて、DevOpsにはCALMSと呼ばれるフレームワークがあります。これはDevOpsを実践するにあたって重要な要素の頭文字で構成されたものであり、それぞれの説明は以下のとおりです。
CALMSモデル
|
カテゴリ |
説明/備考 |
|
Culture（文化） |
|
|
Automation（自動化） |
|
|
Lean（無駄がない） |
|
|
Measurement（計測） |
|
|
Sharing（共有） |
|
このフレームワークを念頭に置くと、以下の1・2・3がDevOpsといえるのではないかと考えています。
- 開発・運用といったチーム間の隔てがない体制・文化において
- アジャイル開発（利用者のニーズ変化に柔軟に対応できる開発）を行い
- 各種プロセスが自動化された状態
このDevOpsの考え方に沿いつつ、開発のスピード感を損なわずに、（例えば自動化された）セキュリティ対策を導入・考慮した状態を（NRIセキュアが考える）DevSecOpsと定義します。
本ブログにおけるDevOpsの定義
本ブログの定義に基づいたDevSecOpsを実践すれば、開発スピードは向上し、サービスリリースを頻繁にすることができるようになり、利用者のニーズの変化にも柔軟に対応可能になります。さらに、セキュリティ対策も半自動化して（人手によるコストも減らしつつ）実施できることになります。
ここまで聞くとDevSecOpsを企業が実践することによるメリットは多く、すべての企業がすぐにでもDevSecOpsを実践・導入することが正しいように思えます。しかし、冒頭で述べた通り、国内企業のプロジェクトにおけるアジャイル開発の採用率は決して高くなく、本ブログで定義したDevSecOpsを実践しているプロジェクトは少ないというのが現状です。
では、なぜそのような変化が国内では見られないのでしょうか。それを考察するために従来開発（ウォータフォール開発を採用し、運用と開発の体制が分離した従来の開発モデルを便宜的にこのように呼称します）からDevSecOpsを実践するまでの変化の過程を探ってみます。
開発プロセスの変化
先ほど定義したDevSecOpsは従来の開発モデルから「Agility（開発速度）」と「Security」を向上させた状態であるといえます。従来の開発から、よりAgilityを向上させるための取り組みが、DevOpsです。これには、運用チームと開発チームの融合や、アジャイル開発の採用が含まれます。
一方で、従来の開発体制や開発手法を維持しつつも、Securityを向上させるための取り組みもあります。これには、ガイドラインの導入や設計レビューの導入など、シフトレフトの考え方を採用した方法があります。これを「セキュア開発」と呼びます。
そして、これら二つの取り組み、つまりDevOpsとセキュア開発が、DevSecOpsに至るまでの過程として存在しています。ただし、実際には、どちらか一方に特化して変遷するわけではありません。むしろ、AgilityとSecurityの両方を向上させることで、DevSecOpsを目指していくと考えられます。
上記を踏まえてDevSecOpsへの変化の過程を図示すると、従来開発からDevSecOpsに至る流れは以下のように表現できます。
DevSecOpsへの変化の過程
Securityの向上（横軸）については、近年のセキュリティ対策の重要性への認識向上からどの企業も意識的に取り組んでいらっしゃいます。一方で、先述したIPAの調査結果を踏まえると「Agilityの向上にむけた取り組みが進んでいない」という状況だと思います。
さらに深堀りしていくと、「ウォータフォール開発を引き続き採用しつつも、CI/CDでSAST（ソースコードの静的解析）を自動的に実施する」といった取り組みを実施しているお客様は多く、実際にこれまで様々なお客様を支援してきました。つまり、Agility向上のために必要な「体制・文化を変える」という点にハードルがあるのではないでしょうか。
日本でDevSecOpsが進まない理由
日本において、アジャイル開発を行うための文化・体制が作られにくいのはなぜでしょうか。これは外部委託を主とした日本の開発体制が一因になっていると考えます。
DevSecOpsを実践するためには開発担当・運用担当・事業担当・セキュリティ担当が一体となり、活動する必要があります。しかし、開発を外部に委託することが多い日本の開発モデルではそれぞれの担当者が所属する組織がそもそも異なっているため、そのような体制を構築することが難しくなります。
開発ベンダの立場としては委託元と事前に合意したシステムを低コストで作りたいと考え、柔軟な要件の変更をできれば受け入れたくないという思いがあるでしょう。日本ではアジャイル開発の採用が進まないのに対して、海外企業において「アジャイル開発/DevOpsが当たり前」となっている企業が多数あるのは、開発を内製化している企業が多いというような背景からではないでしょうか。また、同じ組織であってもサービス提供のスピードを上げてエンドユーザに素早く価値を提供したい事業担当に対して、障害ゼロをKPIとしている運用担当では、目標が相反するものとなっています。
このような各担当の思いを統一するためには経営層のDevOpsを実践しようという強い方針が必要ですが、Agility向上によるデメリットを受け入れる（失敗を許容する）文化が日本においては醸成されづらい状況にあると感じています。
ある事業会社のステークホルダ毎のアジャイルへのモチベーション
DevSecOpsを推進するためのNRIセキュアのアプローチ
前章までに述べたDevSecOps導入の障壁を解消するために、NRIセキュアではお客様のDevSecOps導入を支援する様々なサービスを提供しています。また、NRIセキュアだけではなく、野村総合研究所（NRI）のasleadやbit Labsといったアジャイル開発を支援する各部隊と連携して、DevSecOps支援チームとして活動します。
NRIグループでDevSecOps支援チームを組成
DevSecOps支援チームとしては主に以下2つの支援をしています。
DevSecOpsについてなにかお困り事があれば、弊社までお声がけいただけますと幸いです。
- 開発ベンダとなるNRIの各事業部を支援することでお客様がDevSecOpsの恩恵を受けられるようにする
- お客様の開発体制に入り込み、DevSecOpsを実践するための体制や環境構築をご支援
おすすめの関連ブログ
参考）https://www.gartner.com/smarterwithgartner/8-steps-to-get-devops-right
