開発、運用、そしてセキュリティの各チームに一体感をもたらすDevSecOpsとは？

近年、ソフトウェア開発においてDevSecOpsが大きな注目を集めています。迅速かつ安全で信頼性の高い開発プロセスを実現するという新たなアプローチで、北米市場ではすでに50％以上のプロジェクトで採用されているというデータもあります。日本ではまだ聞きなれないかもしれませんが、導入を検討する企業は増えています。

DevSecOpsとは何か

DevSecOpsを知るために、まずはDevOpsを理解しておく必要があります。DevOpsは、開発（Development）と運用（Operations）を担うチームが相互に連携を深め、高品質かつスピード感の高いソフトウェア開発・運用を行うという「コンセプト」です。

ソリューションではなく、コンセプトであることに着目してください。かつて、開発チームと運用チームは分断されていました。開発チームは少しでも早くソフトウェアを開発したいと考え、一方の運用チームは安定的な運用ができることを重視します。そのため、どちらのチームも、ゴールはビジネスに貢献することであるものの、一種の対立関係にありました。

DevOpsでは、この関係を改め、開発段階から運用チームも関わり、理想的な運用をできるソフトウェアを両チームが協力して開発します。その過程で「失敗を責めてはいけない」、「相手を非難してはいけない」という考えもDevOpsに含まれています。両チームが険悪な関係である、というほどの企業は少ないかもしれませんが、DevOpsが社内に根付き、両チームが良好な関係であるほど、生産性もクオリティも向上します。

DevOpsから派生したコンセプトはいくつかあります。DevSecOpsはそのひとつで、セキュリティ（Sec：Security）がここに加わっています。つまり、高品質でスピード感が高く、かつセキュアなソフトウェア開発・運用を実現しようという考え方で、協力するのは開発チーム、運用チーム、およびセキュリティチームの3者になります。

アジャイル開発との親和性が高いこともDevSecOpsの特徴です。アジャイル開発では短期間で次々とソフトウェアをリリースし続けるため、変化への対応力が問われます。DevSecOpsは、3者が協力する文化を作り上げ、セキュリティを意識した迅速な開発を可能にしてくれます。ウォーターフォール開発にDevSecOpsを適用することも可能です。ウォーターフォール開発では、柔軟な変更対応は重視していませんが、開発の早い段階からセキュリティを組み込むDevSecOpsの考え方は有用です。

DevSecOpsを可能にするツールと自動化

DevSecOpsでよく間違えられていることのひとつに、「DevOpsにセキュリティが加わるために手間が余計にかかり、開発期間が延びる」というものがあります。これは、大きな誤解だと言えます。

プロセス面において考えると、開発の早い段階からソフトウェアのリスクを把握できるメリットがあります。従来のやり方では、セキュリティチームがシステムを監査している間に開発チームがソースコードを書き換えていたり、運用チームが手順書を作成する最終段階に入ってからセキュリティチームが脆弱性を発見したりすることがありました。こうした場合、手戻りが発生して各チームがそれまでにかけてきた工数が無駄になってしまいます。

DevSecOpsでは一連のプロセスの中でセキュリティチェックを入れるタイミングが定義されているため、全体として手戻りを最小限に留め、その結果として開発期間を短縮することが期待できます。

とはいえ、何度もセキュリティ監査をすることは必要ですし、もどかしさを感じる場面もあるかもしれません。そうした場合には、ツールの活用を検討しましょう。DevOpsにせよDevSecOpsにせよ、コンセプトではあるのですが、それを実現するツール群があり、それらがプロセスの短縮を支援してくれます。

DevSecOpsでは大きく計画、構築、テスト、デプロイ、運用、モニタリングという6つのフェーズを一連のソフトウェア開発プロセスとして扱います。それぞれのフェーズに個別のツールを適用することもできますし、6つすべてに対応する機能を備えたスイート製品もあります。

なお、前者を採用すると、望みどおりの機能を備えたツールを組み合わせたDevSecOps環境を実現できる反面、複数のツール群を組み合わせてプロセスを回すことに苦労するリスクがあります。後者では、その逆にツールに神経を使わずに済む反面、機能面で譲歩する部分が出てくることもある、という状況になりますから、ツール選定ではプロジェクトのニーズに合うやり方を選択すると良いでしょう。

多くのDevSecOps事例でプロジェクト期間短縮に役立っていると言われているのがCI/CD（Continuous Integration：継続的インテグレーション/ Continuous Delivery：継続的デリバリー）パイプラインの自動化です。DevOpsにおけるCI/CDパイプラインでは、セキュリティテストは開発の後工程で行われることがほとんどでした。DevSecOpsになると、パイプラインの各フェーズでセキュリティテストを組み込むことになり、セキュリティリスクを開発の早い段階で発見し、修正できるようになります。

うまくツールを使えば、多様なセキュリティテストをサポートできます。静的なソースコード分析だけでなく、実際にプログラムを稼働させて実行する動的テストも可能。ソフトウェアに組み込まれたOSSコンポーネントやそれが呼び出すライブラリを先の先までたどって脆弱性データベースとマッチングするコンポジション分析なども実行できます。そして、ツールの設定にセキュリティチームがかかわることで、自動化済みの部分にセキュリティチームがかける手間を最小化することも期待できます。

DevSecOpsとSplunk

Splunkは、DevSecOpsを導入しようとしている企業に対して、セキュリティリスクを可視化することで貢献しています。Splunkのユーザー企業がDevSecOpsを採用すると、セキュリティチームが関与するプロセスがより高速になると言えるでしょう。

例えば、CI/CDツールのデータに加え各種セキュリティテストツールからのデータをSplunkに取り込むことでDevSecOpsパイプライン全体の状況の可視性を得られ、品質やボトルネックの把握がより容易になります。

また、Splunkはポストモーテム（インシデントが発生した際に実施する事後検証）の際に詳細な情報を提供できます。ポストモーテムでは、開発、運用、セキュリティの各チームから、インシデントに対応したメンバーが集合し、「対応の適切／不適切だったポイント」、「次回以降に改善すべきポイント」、「対応プロセスで起きた失敗と、それを繰り返さないためにやるべきこと」などについて振り返ります。

Splunkは、システムのログデータをそのまま使って何が起きたのかを可視化します。Splunkでインシデントの内容を赤裸々にとらえられるようになることは、DevSecOpsをより良いものにするために、極めて重要な価値を提供できると言えるでしょう。