このブログでは、DevSecOpsの意味と、開発チームのセキュリティのベストプラクティスについて説明しました。いくつかのの質問をいただいたので、ショートQ＆Aを設けました。DevSecOpsが開発者にとって重要である理由と、開発者ワークフローへの適用方法についてわかりやすく説明します。

過去に「DevSecOps」という用語を耳にしたことはありますが、このブログのおかげで理解できました。おさらいになりますが、DevSecOpsとはどういうものか、簡潔に説明してもらえますか？

DevSecOpsとは、DevOpsチームによるセキュリティに対する考え方のシフトを表します。セキュリティチームがアプリケーションのセキュリティの責任を一手に引き受けたり、コードを記述した後にすべてのセキュリティ要件を検証したりするのではなく、DevSecOpsではアプリケーションライフサイクルに関与するすべての関係者がアプリケーションのセキュリティに対する責任を担うという考え方です。

責任を分かち合うということですね。名前だけ見るとDevOpsに関係ありそうですが、もしそうであれば、DevOpsとDevSecOpsの違いは何でしょうか？略語をもう1つ作る必要はあるのでしょうか？

近年、DevOpsへの移行に伴って見られた業界における考え方のシフトも、DevSecOpsへの移行を推進する要素となっています。そこには類似点が見られます。DevOpsでは、インフラストラクチャを管理していないユーザーも含む全員が、機能停止の責任を担います。一方、DevSecOpsでは、ソフトウェアを作成していないユーザーも含む全員が、脆弱性の責任を担います。

DevOpsが生まれたのは、ビジネスにおいて機能が停止してしまうケースを抑える必要があったからです。全員が機能停止を防ぐためのツールを持っており、全員がその責任を担うのであれば、機能停止の頻度は少なくなるはずです。明確なビジネスニーズもないまま、ビジネスプロセスを正常に変換させることは非常に困難です。DevOpsは機能停止を減らすことを目標として掲げていますが、それと同じように、DevSecOpsの目標は、データ損失などのセキュリティの問題を削減することです。また、CIAトライアド(機密性、完全性、可用性)を考慮すると、機能停止を減らすためのDevOpsの取り組みでは、可用性に直接的に対処していることがわかります。そのため、これらのコンセプトが組み合わされているのも驚くべきことではありません。ありがちな略語や業界用語のように聞こえるかもしれませんが、“DevSecOps”という名前を付けることで、ソフトウェア構築に関する大きな会話の中にセキュリティを組み込む(そして保持する)ことができます。

では、それを実践した場合、DevSecOpsの手法とはどのようなものになるでしょうか？よく耳にする“シフトレフト”というフレーズにはどのように関係してくるでしょうか。

DevSecOpsとは、考え方のシフトを意味します。あいにく、DevSecOpsのプラクティスには標準的なものはありません。セキュリティプラクティスをソフトウェアライフサイクルの中にうまく組み込むことで、変化をもたらすことが重要です。

実際には、チームが開発を手がけているものに責任をもってもらうには、プロセスを開発ライフサイクルの早期に“シフトレフト”して、しかるべきところでミーティングを開催します。セキュリティを開発期間の最終関門とするのではなく、早い段階に前倒しして、アプリケーションのセキュリティに対するフィードバックを早め(開発時、ビルド時、テスト時)に提供することを意味します。このフィードバックを状況にあわせて提供すると、開発チームが流れから逸脱することなく問題に対処しやすくなり、問題を早めにつぶすことができるようになります。

DevSecOpsが、特定の手法ではなく考え方の変化であるとしたら、それを取り込む方法は多岐にわたるという意味でもあります。それはどのような問題を解決していると思いますか？DevSecOpsに移行することで、開発者にはどのようなメリットがあるでしょうか。

大まかにいうと、DevSecOpsは、アプリケーションセキュリティ対策においてセキュリティチームにかかっている過度な負担を解消します。アプリケーションセキュリティの担当者が不足しているのは、何も個々の組織に限ったことではなく、業界全体に当てはまることなのです。セキュリティチームだけでは、すべてのセキュリティの問題に対処できるほどの規模はなく、これからもそれだけの規模を確保できることはないでしょう。知識やツールを拡散することで、開発者も一般的なセキュリティ問題に対処できるようになり、セキュリティのエキスパートは一番必要とされているところに注力できるようになります。

とはいえ、特定の技術的な問題に、DevSecOpsで完全に対処できるわけではありません。もちろん、目指しているのはセキュリティの問題を減らすことですが、それでも完全にセキュリティ保護されているものはありません。DevSecOpsは、アプリケーションのセキュリティを完璧にすることに注力するよりも、リソースを効果的に活用してセキュリティ要件に対応し、問題が実際に発生したときに迅速に対応する俊敏性をもたらすことにフォーカスしています。問題をすばやく修正できれば、さらには問題を防ぐことができれば、DevSecOpsのメリットを享受しているも同然です。

DevSecOpsが重要なのはなぜですか？

DevSecOpsによって、セキュリティが特別なもののように思われるかもしれませんが、実際にはどの機能も、開発プロセスのすべての段階において密接に統合するべきなのです。DevSecOpsは業界で盛り上がりを見せていますが(そして規模は小さいものの、その導入も注目を集めています)、そこから学べることが1つあるとすれば、アプリケーションセキュリティに対する現在の取り組みは拡張性がないためうまくいかない、ということを認識したことです。セキュリティの問題に十分に対処するリソースにギャップがあることを理解し、より効果的なアプリケーションセキュリティを実現するために責任の一部を分散できることを提案しているのです。

そのとおりだと思います。では、自社のチームにDevSecOpsを導入するにはどうすればよいでしょうか。

先ほど申し上げたとおり、DevSecOpsのプラクティスには、広く取り入れられている標準的なものはありません。このトピックは、DevOpsほど幅広く研究されていません。開発チームがセキュリティの問題に対応できるよう、セキュリティ制御とフィードバックを開発ライフサイクルの早い段階(開発時、ビルド時、テスト時)に“シフトレフト”する必要があります。これにはさまざまな制御が考えられます。たとえば、独自のコードの制御やサードパーティコードの制御なども該当します。また、開始点がどこであるかにもよります。

DevSecOpsの第一歩は、どこから踏み出せばよいでしょうか。

• 異なるCI/CDパイプラインを使用しているチームがあれば、セキュリティへの取り組みとして最善なのは複数のツールを集約し、コードリリースの方法を明確にすることです。これによって、少なくとも実稼働環境にリリースするものは何か、すでに配備されている制御はどのようなものであるかが把握しやすくなります。
• チームに共通のパイプラインがある場合は、一部の制御をシフトレフトすることも検討しましょう。ツールチェーンの統合に向けたステップは、どれも重要です。侵入テストから静的分析ツールへの移行、あるいは実稼働環境で起票されるJIRAチケットから統合開発環境(IDE)で明らかになったアラートへの移行などです。だからといって、下流ツールを完全に置換できるわけではなく、そうするべきではありません。そうではなく、問題を早い段階で検出し、対応しやすくなるということです。
• 開発ライフサイクルがかなり進んでいる場合には、開発者の負担を軽減し、セキュリティを強化するために他にできることはないか考えてみましょう。たとえば、構成の検証を自動化したり、パッチの適用とメンテナンスが済んだライブラリを提供するなどの方法があります。

DevSecOpsの詳細を聞かせていただき、ありがとうございます。やるべきことがまだまだあるようですね。チームがこの取り組みを始めるにあたって役立つリソースはありますか？

おすすめの資料をご紹介します。

• BSidesSF 2020でのClint Gibler氏のプレゼンテーション「How to 10x Your Company’s Security, Without a Series D」
• DevSecConコミュニティとリソース(過去のトークなど)。
• orgのDevSecOpsに関するわかりやすいまとめ
• Googleの『Building Secure and Reliable Systems』ブック