DevSecOps の概要

DevSecOps とは

DevSecOps とは、セキュリティの手法を DevOps ソフトウェアデリバリーモデルに統合することをいいます。その基盤は、プロセスとツールを通じて、開発者と運用者が安全なソフトウェアを提供する責任を共有する文化です。

高機能なレベルにおける DevSecOps モデルとは、ソフトウェア開発ライフサイクルのできるだけ早い段階でセキュリティ目標を統合することと定義されます。セキュリティは「全員の責任」であるとはいえ、DevOps チームは開発と運用の交差点というユニークな立場にあり、セキュリティを幅広く、かつ深く適用する権限を与えられています。

DevOps と DevSecOps の違いは何ですか？

DevOps と DevSecOps の違いは、簡単に言えば、責任を共有する文化があるかどうかです。DevOps は 10 年以上にわたって多くのことが語られ、書物で言及されてきた概念であり、DevOps には多くの定義があります。DevOps の本質は、開発と運用の責任を共有して連携する組織的な枠組みです。

DevOps vs. DevSecOps の比較

高機能なソフトウェアエンジニアリングチームの間で共有される共通のプラクティスを緩やかに集めたものが、エンジニアリング文化とプロセスの現代的なステートメント、つまり、DevOps へと変化を遂げました。開発と運用の責任を共有する組織は繰り返しがよりすばやくでき、その結果、大きな成功を収めることができます。DevSecOps はこの考え方を発展させ、セキュリティ目標を全体の目標構造の一部として体系化したものです。DevSecOps は、別個のアイデアや概念としてではなく、DevOps の自然な継続と考えるべきです。DevOps プラクティスの実践に成功しているチームは、DevSecOps を革命的なステップではなく、進化的なステップと考えています。

コードから本番環境へと、シームレスで持続可能なフローで移行し、ビジネス価値を生み出す環境の構築を目指していることに多くの人が同意するはずです。この新しいモデルのツールと方法論によりペースが速くなった一方でボトルネックも発生しました。従来型のセキュリティ対策のフィードバックサイクルが遅く、ペースの速い DevOps プラクティスを阻害していたのです。その結果、セキュリティ対策は多くの場合、本番稼働後または外部チームに委託してプロセスの途中で挿入され、全体的な遅延を引き起こしていました。

DevOps と DevSecOps の違いとして、DevSecOps は責任を共有する DevOps 文化を発展させ、セキュリティ対策を含めたものであると説明できます。セキュリティの問題を特定し、可能なら解決するように設計されたアクティビティは、製品のリリース後ではなく、アプリケーション開発のライフサイクルの早い段階で挿入されます。これは、開発チームがソフトウェア開発ライフサイクル (SDLC) 内の多数のセキュリティタスクを単独で実行できるようにすることで実現します。

このアプローチにより、本番稼動時までに脆弱性を最小限に抑え、セキュリティ上の欠陥の修正にかかるコストを削減できます。また、拡張性が高まるとともに、DevOps の目標に向けてセキュリティチームと協力するカルチャーが確立されます。DevSecOps は、要件の段階からデリバリープロセスのすべての段階にセキュリティを組み込み、セキュリティ自動化の計画を確立することを目的としています。

DevSecOps の重要性

DevSecOps の実践が重要な理由

デジタルトランスフォーメーションは、ほぼすべての企業にとって必須の要件となっています。具体的には、ソフトウェアの増大、クラウドテクノロジー、DevOps の方法論の、重要な 3 つの取り組みが含まれます。

ソフトウェアの増大は、組織のリスクの多くがデジタルに移行し、技術的負債のレベル、ひいてはアプリケーションのセキュリティレベルを上げ、デジタルアセットの保護がますます難しくなることを意味します。

クラウドにより最新テクノロジーを活用できる一方で、さまざまなリスクが生まれ、すばやい変化が生じ、一般に幅広くアクセスできるようになるため、セキュリティの境界線の概念がなくなったり再定義されたりします。加えて、IT とインフラのリスクの多くがクラウドに移行するとともに、その他のリスクは純粋にソフトウェアで定義されるため、多くのリスクが軽減される一方で、権限とアクセス管理の重要性が増します。

最後に、DevOps により、ソフトウェアの開発、配信方法が変化し、コードの記述から顧客価値の実現、マーケットにおける学習や適応までのサイクルを加速化できます。権限を与えられたチームは、継続的に開発してこれまで以上にすばやくソフトウェアを出荷し、テクノロジーや導入の判断を自律的に、仲介者なしで下すことができます。チームがますます自給自足型となり、コードの記述と実行を担うようになるにつれ、開発の足を引っ張る従来型の緩慢なフィードバックループは不可能になっています。

組織の他の部分が進化するにつれて、セキュリティチームに対する要求も増大し、そこにボトルネックが発生しがちです。クラウド以前の遅いペースの時代に合わせて設計された従来型のアプリケーションセキュリティのツールや方針で運営しているセキュリティチームは、高品質なアプリケーションの提供にあたってクリティカルパスになっています。深刻な人材不足が生じているセキュリティチームはボトルネックとなり、開発のペースに追いついていません。その結果、開発チームはセキュリティが確保されていないアプリケーションをリリースする一方で、セキュリティチームは燃え尽き、消極的になり、成長の足かせになることになります。

このような課題に対処するために、人々は方針を変え始め、DevSecOps が誕生しました。DevSecOps のカルチャーは、セキュリティを DevOps の中に取り込み、開発チームのペースでセキュリティを確保できるようにするとともに、開発者とセキュリティチームの間の連携を強化します。このカルチャーでは、セキュリティチームが開発者のためのサポート組織として専門知識とツールを提供し、開発者の自律性を高めながらビジネスに必要なレベルの監視を提供できます。

DevSecOps モデルの 6 つの利点

1. すばやいリリース: セキュリティがパイプラインに統合されることで、ソフトウェアのリリース速度が向上します。バグはデプロイメントの前に特定されて修正されるため、開発者は機能のリリースに集中できます。

2. セキュリティ態勢の改善:セキュリティは設計段階から必要な機能です。共有責任モデルにより、開発、デプロイメント、本番環境のワークロードの保護に至るまで、セキュリティが緊密に統合されます。

3. コスト削減:脆弱性とバグをデプロイメントの前に特定することで、リスクと運用コストを飛躍的に削減できます。

4. DevOps の価値の向上:DevOps にセキュリティプラクティスを統合することで、責任を共有するカルチャーが創出され、全体的なセキュリティ態勢が改善されます。Snyk/Puppet 2020 DevSecOps Insights Report では、成熟したDevSecOps 組織でこのような状況が見られていることが報告されています。

5. セキュリティ統合とペースの改善:開発後にセキュリティ対策を導入する必要がないため、安全なソフトウェアを提供するためのコストと時間を削減できます。

6. ビジネス全体の成功に貢献:開発したソフトウェアのセキュリティに対する信頼が高まり、新しいテクノロジーの導入につれて増収し、事業の拡大が可能になります。

DevSecOps の採用: CI/CD パイプラインへのセキュリティの統合

現代の DevOps 組織のほとんどは、CI/CD パイプラインの形式で、継続的インテグレーションと継続的デプロイ/デリバリーシステムを何らかの形で組み合わせています。このパイプラインは、自動化された様々なセキュリティテストや検証を行うための優れた基盤となり、人の手による労力を必要としません。

DevSecOps の採用: CI/CD パイプラインへのセキュリティの統合

アプリケーションの開発の早い段階でセキュリティ目標を統合するには、最初のコードが書かれる前に始める必要があります。システム、アプリケーション、または個々のユーザーストーリーについての最初のコンセプト段階でセキュリティを統合することで、効果的な脅威モデリングを開始できます。静的解析、リンター、ポリシーエンジンは、開発者がコードをチェックインする際にいつでも実行でき、問題を簡単に解決してから、変更をアップロードできます。

総合的なソフトウェアコンポジション解析を実施することで、オープンソースの依存関係に互換性のあるライセンスが含まれており、脆弱性がないことを確認できます。その結果、開発者はアプリケーションセキュリティに責任を持ち、記述したコードの相対的セキュリティについてのフィードバックをただちに入手できます。

コードのチェックインとビルドが完了したら、セキュリティ統合テストを開始できます。隔離されたコンテナのサンドボックスでコードを実行することで、ネットワークコール、入力検証、認証などの自動テストが可能になります。これらのテストにより、すばやいフィードバックが生成され、識別された問題をすばやく反復してトリアージを実行し、ストリーム全体の中断を最小限に抑えることができます。原因不明のネットワーク呼び出しやサニタイズされていない入力が発生した場合などは、テストが失敗し、パイプラインから関連するチームへのレポートや通知という形で、実用的なフィードバックが生成されます。

デプロイメントアーティファクトが最初の統合テストに合格すると、次の段階の統合テストに進みます。今度は、最終的な本番環境の限定的なコピーである、さらに広いサンドボックスにデプロイされます。この段階では、目的は異なりますが、セキュリティ統合テストをさらに実行できます。

ここでは、適正なログ記録やアクセス制御などをテストできます。アプリケーションで、セキュリティやパフォーマンスの関連指標が正しく記録されているでしょうか。アクセスは適切なサブセットに限定（あるいは完全に防止）されているでしょうか。テストに合格しなかった場合は、関連するチームにアクションアイテムが送られます。

最後に、アプリケーションが本番環境に移行します。ただし、DevSecOps の本格的な作業が続きます。自動化されたパッチ適用と設定管理により、本番環境では常に最新かつ最も安全なバージョンのソフトウェア依存関係が実行されるようになります。環境全体を頻繁に解体して再構築し、パイプラインに沿って一連のテストを常に実行できる、イミュータブルインフラストラクチャの運用が理想的です。

DevSecOps CI/CD パイプラインを利用することで、面倒な事務処理やゲートキーピングを追加することなく、各段階でセキュリティ目標を統合でき、ビジネス価値をすばやく実現できます。

DevSecOps カルチャーの促進

では、どうしたら「DevOps」を「DevSecOps」に進化できるのでしょうか。一連のセキュリティ KPI について、DevOps チームに伝えて終わりで済めば簡単ですが、DevOps チームはすでに多忙な状態です。そこで、すばやく反復できる、協力的なカルチャーを共有する必要があるのです。

セキュリティ目標を早期に統合することを目指したとしても、できるだけ苦痛を伴わないように実施する必要があります。開発のバリューストリームにセキュリティチームとセキュリティ目標を統合する負担は、開発者に負わせるべきではありません。新たなステップを追加しても、顧客に機能を届けるまでの時間が長くなるだけです。セキュリティチームは機敏に行動し、事業の中断を最小限に抑えてセキュリティ対策を実施する現実的なアプローチを取る必要があります。

計画プロセス、特にインフラに関連するプロセスの中で、セキュリティエンジニアは話し合いに参加し、不十分で安全でない選択に反対する権限を持つ一方、代替案を提示できるだけの知識を持っていなければなりません。多くの場合、多忙なセキュリティチームは単に反対するにとどまり、代替案を考えることは DevOps チームに丸投げしてしまいます。これもまた、セキュリティチームに適切なレベルのリソースを用意する必要があることを示しています。

セキュリティと DevOps が早い段階から緊密に連携することで、セキュリティ目標がインフラ構造にしっかりと織り込まれるようになります。本番環境に導入される機能やアプリケーションは、セキュリティ、開発、運用の各担当者が包括的かつ効果的に連携した結果となります。セキュリティチームは後になって開発チームに追加機能の開発や監査を依頼する必要はありません。開発の最初の段階から、これらの要素が組み込まれているからです。

DevSecOps を実践するように進化した組織においては、新機能や機能の改善で顧客満足度を高め、すばやい反復を実行できているだけでなく、適切なレベルのセキュリティを確保し、優れたエクスペリエンスを提供していることでしょう。