DevSecOpsとは何か?

これまで、アプリケーションとインフラストラクチャのセキュリティを確保するには、アプリケーションを開発する開発者、アプリケーションをデプロイして管理するIT運用エンジニア、サイバーセキュリティの専門家である情報セキュリティ・アナリストなど、さまざまなタイプの利害関係者が協力する必要がありました。企業は、これらすべての関係者をまとめ、関係者間の効率的なコラボレーションを実現するために、ますますDevSecOpsに注目するようになっています。

様々なタイプのエンジニアがセキュリティを最適化するために使用できる共通の目標、方法論、およびツールを確立することで、DevSecOps は、チームがより少ない労力でより優れたセキュリティ成果を達成するのを支援します。

DevSecOpsの意味、仕組み、DevSecOpsを実現するベストプラクティスについて深く掘り下げていきます。

DevSecOpsとは何か?

DevSecOps は、ソフトウェアデリバリライフサイクルで役割を果たすすべてのステイクホルダーの連帯責任でセキュリティ対策を行う戦略です。
DevSecOpsの中心にある目標は、セキュリティが「サイロ」に放置されたり後回しにされたりするのではなく、ソフトウェアデリバリの各段階に確実に統合されるようにすることです。実際には、セキュリティの評価と最適化は、コーディングプロセス（ソフトウェアデリバリの最初の段階）から始まり、テスト、ステージング、デプロイメント、および管理の各プロセスを通じて継続されることを意味します。

DevSecOpsDevSecOpsとDevOpsの比較

DevSecOpsは、DevOpsの中核にある原則に基づいています。DevOpsは、アプリケーションの品質を低下させたり、ユーザーエクスペリエンスを損なったりする可能性のあるミスコミュニケーションや遅延を回避するために、開発サイクルのすべての段階において、開発者とIT運用エンジニアがソフトウェアデリバリの全体的なオーナーシップを持つことを奨励しています。DevOpsはまた、ソフトウェアの計画、コーディング、構築、テスト、デプロイメント、および管理のプロセスを継続的な「無限ループ」に変えることを目指しています。

しかし、DevOps単体ではセキュリティには及びません。2000年代後半にDevOpsの哲学が登場したとき、それは開発とIT運用の統合だけに焦点を当てていました。

DevSecOpsは、DevOpsにセキュリティを追加することで発展させたものです。DevSecOpsを採用する企業は、開発者とIT運用チームだけでなく、セキュリティ専門家間のコラボレーションを最適化するよう努めています。そして最終的には、開発、運用、セキュリティの間の障壁を取り払い、知識を広めることで、これらの領域が1つの専門知識を共有する領域に融合することを目指しています。

DevSecOpsのユースケース

DevSecOps は、規模や業種を問わず、ソフトウェアに依存するほぼすべてのビジネスにメリットをもたらします。たとえば、さまざまな業種における DevSecOps の一般的なユースケースを以下に示します：

• ヘルスケア： ヘルスケア・ビジネスは、厳格なコンプライアンスとデータ・プライバシー要件の対象となります。ソフトウェアデリバリライフサイクル全体でセキュリティを優先することで、DevSecOps は医療機関がこれらの要件を満たし、データプライバシーを危険にさらすリスクを特定するのに役立ちます。
• 金融：金融サービス企業もまた、厳しいコンプライアンス要件に直面しています。また、多くの企業がレガシーと最新のソフトウェアリソースを複雑に組み合わせて利用しています。DevSecOpsは、多くの銀行や保険会社が依然として依存しているメインフレームから、よりモダンなワークロードをホストするために使用しているクラウドネイティブなKubernetesクラスタまで、金融業界の企業がIT資産のすべてのコンポーネントにわたってセキュリティを最適化するのに役立ちます。
• 小売業： 競争の激しい小売業界では、一流の顧客体験の提供を実現することが最も重要です。また、顧客 ID や決済情報などの機密データを保護することも重要です。DevSecOps は、小売企業が高度にセキュアなアプリケーションを構築してデプロイできるようにするため、この両面で役立ちます。同時に、DevSecOps は、セキュリティを最初からアプリケーションに統合するのではなく、構築後にアプリケーションに「ボルトオン」する場合に発生しがちな、アプリケーションのパフォーマンスや信頼性の問題のリスクも最小限に抑えます。セキュリティを後から追加しようとすると、ユーザーエクスペリエンスに影響を与える問題が発生する可能性が高くなります。

DevSecOpsの採用は確かにこれらの分野に限定されるものではありませんが、これらの業界は、DevSecOpsが様々なコンテキストやユースケースにおいて、いかに価値あるセキュリティ上のメリットをもたらすことができるかを示す代表的な例です。

DevSecOpsの利点

どの業種であっても、DevSecOps はセキュリティの成果を向上させる中核的なメリットを提供します：

• プロアクティブなセキュリティ： DevSecOps は、セキュリティ問題の先取りを容易にします。また、セキュリティ・チームだけでなく、開発者や IT エンジニアも、セキュリティ・リスクを防止する最善の方法についてそれぞれの視点を発揮できるようになります。
• セキュリティに対する共同責任： DevSecOps では、セキュリティの成功と失敗の両方の責任を、すべての利害関係者がまとめて共有します。文化的な観点からは、侵害が発生したときに開発者、IT エンジニア、セキュリティチームが互いに指をさしたり、実際には自分たちだけで達成したわけではないセキュリティの成果を自分の手柄にしたりするよりも、その方が健全です。
• アプリケーションデリバリの合理化： 企業が DevSecOps を使用してアプリケーションのデリバリに最初からセキュリティを組み込むと、セキュリティツールや プロセスによってアプリケーションのデリバリが遅くなるリスクが低減します。DevSecOps によって、例えば、アプリケーションがデプロイされる直前まで気付かなかったセキュリティ上の欠陥を検出するために、セキュリティ・アナリストが開発者にアプリケーション・コードの書き換えを要求することが防げます。DevSecOpsでは、この種の問題に早期に対処することができ、より信頼性が高く一貫性のあるアプリケーションデリバリサイクルにつながります。
• 反復可能なセキュリティプロセス： 各種の利害関係者がセキュリティにアプローチするための体系的な方法を提供することによって、DevSecOps は、セキュリティプロセスを反復可能で信頼できるものにするのに役立ちます。別の言い方をすれば、DevSecOpsにより、 セキュリティをアドホックで個々のケースに対応するオペレーションから、ビジネスのあらゆる部分のアプリケーションデリバリサイクルに適用可能な体系的な一連のプロセスに転換します。
• SBOM の可視化： DevSecOpsは、セキュリティ・プロセス内の複数のステイクホルダーが効果的に連携できるようにすることで、企業がソフトウェア部品表（Software Bills of Materials、SBOM)、ソフトウェアデリバリプロセスのすべての段階で、ソフトウェアを作成するために必要なすべてのコンポーネントとリソースを文書化したもの、の作成を支援します。

DevSecOpsの仕組み

DevSecOpsは、厳格なプラクティスやツールのセットではありません。その代わりに、企業がセキュリティにアプローチする方法を統制する概念または哲学です。チームがDevSecOpsを実行に移す方法は、サポート対象となるアプリケーションやインフラの種類、直面する特定の種類のリスクやコンプライアンス要件などの要因によって異なります。そのため、「DevSecOpsはどのように機能するのか？」に対する普遍的な答えはありません。

• DevSecOps の目標設定： まず、DevSecOps を採用する理由と、それによって具体的に何を得たいのかを明確にします。例えば、セキュリティ問題によって引き起こされるソフトウェアデリバリの遅延を減らすことなのか、あるいは、侵害の総件数を減らすことなのか？DevSecOps のゴールはビジネスによって異なるため、DevSecOps を開始するためには、貴社のゴールを確立する必要があります。
• DevSecOps フレームワークの作成： DevSecOps フレームワークは、DevSecOps へのアプローチを管理する具体的な手順とルールを定義します。例えば、DevSecOps フレームワークは、Infrastructure as Code（IaC）テンプレート内のセキュリティギャップを回避するために、Infrastructure as Code（IaC）テンプレートの構成に関するポリシーを確立するかもしれません。あるいは、アプリケーションをデプロイする前に、どの自動化されたセキュリティテストに合格する必要があるかを定義するかもしれません。
• DevSecOps プロセスの立ち上げ： DevSecOps のフレームワークができたら、特定のチームメンバーに特定の DevSecOps プロセスを担当させることで、実行に移すことができます。
• DevSecOps の測定: DevSecOps イニシアチブを開始したら、イニシアチブの成功を継続的に測定することがベストプラクティスです。メトリクスを収集して、DevSecOps の目標をどの程度達成しているかを判断し、DevSecOps の有効性の経時的な変化を測定します。

セキュリティツール

各組織のDevSecOpsの道のりは一様ではないため、すべてのビジネスが必要とする普遍的なDevSecOpsツールのセットは存在しません。しかし、一般的に、多くのDevSecOpsイニシアチブは、以下のDevSecOpsツールのコアカテゴリから恩恵を受けるでしょう：

• Static application security testing (SAST): SAST solutions help to identify flaws and vulnerabilities in application source code and binaries by scanning and assessing the contents of an application. SAST is most useful in the earlier stages of software delivery to catch risks before an application moves toward deployment.
• 静的アプリケーションセキュリティ解析(SAST):　アプリケーション内部をスキャンして評価することで、アプリケーションのソースコードとバイナリの欠陥と脆弱性を特定するのに役立ちます。SASTは、ソフトウェア配布の初期段階で最も有用であり、アプリケーションのデプロイ前にリスクを捕捉します。
• ソフトウェアコンポジション解析 (SCA): SCAツールは、使用するオープンソースパッケージやモジュールなどのサードパーティソフトウェアのコンポーネントを特定するのに役立ちます。DevSecOpsにとって、SCAはサードパーティの依存関係が他のアプリケーションに統合される前に安全であることを保証するための重要なタイプのツールです。
• 動的アプリケーションセキュリティテスト (DAST): DAST ツールは、稼働中のアプリケーションに対してセキュリティテストを実行し、静的バージョンのアプリケーションをレビューする際にチームが見逃していた可能性のある脆弱性や弱点を検出します。
• I対話型アプリケーション・セキュリティ・テスト（IAST）： IAST は、SAST と DAST の両方の要素を組み合わせた、セキュリティツールの新しいカテゴリーです。 実行中のアプリケーションにおけるコードを分析し、脆弱性を発見するソフトウェア開発手法です。一般に、IAST ツールは、リスクを特定するために、動的なセキュリティテストを使用します（これは、DAST に似ています）が、同時に、リスクを引き起こすソースコードまで遡って追跡することも試みます（これは、SAST に似ています）。

特定のタイプの環境をサポートする DevSecOps チームは、追加のツールを導入したいと思うかもしれません。例えば、クラウドワークロードの場合、クラウドセキュリティポスチャ管理（CSPM）ツールは、クラウド環境にセキュリティリスクをもたらす可能性のある設定ミスを検出するのに便利です。同様に、Kubernetes 上にデプロイされたワークロードの場合、DevSecOps チームは、過剰な特権を持つコンテナなど、Kubernetes アーキテクチャに特有のリスクを検出できるセキュリティツールを活用する必要があります。

DevSecOpsのベストプラクティス

具体的にどの DevSecOps ツールや方法論を使用するかにかかわらず、以下のようなベストプラクティスは、チームが DevSecOps を最大限に活用するのに役立ちます：

• 自動化、自動化、自動化： 自動化は、DevSecOps の厳密な要件ではありません。しかし、DevSecOps プロセスを自動化すればするほど、複数の利害関係者がセキュリティに関して効率的に協力しやすくなります。
• リリースサイクルを管理しやすい状態に保つこと： 変更が多すぎるアプリケーションのリリース・サイクルは、セキュアで分析すべきコードが増えるため、DevSecOps を難しくします。一般的に、DevSecOps は、リリース・サイクルが短く甘いままであれば、よりスムーズで効果的です。
• DevSecOps をサプライチェーンに適用しましょう： セキュリティ・リスクをもたらす可能性があるのは、社内で開発されたアプリケーションだけではありません。アプリケーションに統合したり、IT 環境にスタンドアロンでデプロイしたりするサードパーティのコードも、セキュリティ問題の原因となる可能性があります。そのため、社内で作成したコードだけでなく、「サプライ・チェーン」にある外部のソフトウェア・リソースに対しても、同じように厳格な DevSecOps プロセスを適用することがベスト・プラクティスです。
• 自社の環境に合わせた DevSecOps： 前述のとおり、DevSecOps のツールと方法論は、サポートするワークロードによって大きく異なります。DevSecOps を一般的なプラクティスとして扱うのではなく、特定のニーズに合わせて調整するようにしてください。

結論

DevSecOps のプラクティスは多岐にわたりますが、いずれも、セキュリティを効果的かつ効率的に確保するというコアな目標をサポートしています。DevSecOpsはソフトウェアのリリース・サイクルがかつてないほど速く進み、企業が直面するセキュリティ脅威の数が絶えず増加している世界では、非常に重要な利点となります。企業がどのようにアプローチするかにかかわらず、DevSecOpsを採用することは、より良いセキュリティ成果を得るための重要なステップなのです。