DevSecOpsのためのベストプラクティス トップ10

DevSecOps：エンジニアリングチームがSDLCを通じてセキュリティスキャンを実行し、エンドユーザーに届く前に脆弱性を発見して修正する方法論。DevSecOpsのベストプラクティスを学びましょう。
 

ソフトウェア開発チームは、高速性を維持しながら、本番サービスにおけるソフトウェア脆弱性の数を最小限に抑えるという課題を抱えています。

なぜDevSecOpsが重要なのか？

従来のアプリケーション・セキュリティのアプローチでは、ソフトウェア提供の急速なペースについていけないため、企業はDevOpsのコンセプトを実装したセキュリティ手法を使用し始めています。このアプローチにより、開発チームは、開発者優先のセキュリティとガバナンスを組み込んだ高速なソフトウェア・デリバリーを実現することができます。

DevSecOpsのフレームワークは素晴らしい結果をもたらしますが、ほとんどのIT分野と同様に、避けるべき落とし穴があります。DevSecOpsのベストプラクティスを理解し、実施することが、これらの落とし穴を回避する鍵となります。

DevOpsセキュリティ入門

DevSecOpsの方法論とは？

DevSecOps は、ソフトウェアデリバリライフサイクル（SDLC）のすべてのフェーズに調和したセキュリティの自動化を追加する哲学と実践である。ほとんどのITプロフェッショナルは、DevOpsフレームワークの無限ループ図に精通しています。ループの各フェーズを、その実際の実装に対応させることができます。

• ビルド → 継続的インテグレーション(CIパイプライン)
• テスト → 継続的インテグレーション、継続的デリバリー、継続的デプロイメントの一環
• リリース → 継続的デリバリー (CI/CD)
• デプロイ → 継続的デプロイメント（CDパイプライン、フィーチャーフラグ管理）
• 操作する → 継続的デプロイメントと本番運用

DevOpsセキュリティ（別名：シフトレフトセキュリティ）はテストフェーズだけのものだと思うかもしれませんが、DevSecOpsのベストプラクティスは共有の責任であり、最高の結果を得るためにはすべてのフェーズにまたがる必要があります。

DevSecOpsの中核は、エンジニアリングチームがソフトウェアのデリバリーライフサイクルを通じてセキュリティスキャンを実行し、エンドユーザーに届く前に脆弱性を発見して修正する方法論です。それでは、DevOpsセキュリティのベストプラクティスについて説明します。

DevSecOpsセキュリティのベストプラクティス

開発者とセキュリティのコラボレーションを強化 

DevOpsの理念がエンジニアリングチームとオペレーションチームの垣根を取り払うことを促進するように、DevSecOpsの理念はエンジニアリングチームとセキュリティチームの垣根を取り払うことを促進します。

セキュリティテストの文化を促進する 

DevOpsと同様に、DevSecOpsを成功させるためには、企業文化の変革が必要です。企業文化の変化には、2つの方法があります。

1. トップダウンによる強制的な変更 - 通常、幹部社員が必要な変更を組織全体に伝えます。
2. ボトムアップによる有機的な変化 - チームを超えたセキュリティのコラボレーションは、小規模なものから始まり、成功の口コミが広がるにつれて他のチームへと拡大していきます。

どちらのアプローチも導入は容易ではありませんが、セキュリティ問題がエンドユーザーに到達する前に特定し、解決することに注力する文化を醸成するには、どちらも効果的です。各組織は、どのアプローチが最も効果的であるかを判断する必要があり、多くの組織では、両方の戦術を統合して実施しようとしている。

すべてのセキュリティスキャンを自動化

DevOpsチームは、CI/CDパイプラインに関連するあらゆるものを自動化するアプローチを採用しています。同じ原則が、DevSecOps のプラクティスを用いて安全なアプリケーションを作成する場合にも当てはまります。安全なアプリケーション配信のワークフローにおけるすべてのステップを注意深く調査することは、自動化できるものを決定するのに役立ちます。次に、重要性と必要な労力に基づいて、優先順位をつけたリストを作成することができます。意味のあるものはすべて自動化されるまで、リストを下げていきます。

自動化されたセキュリティスキャナのガバナンスの導入

ガバナンスは、最近、すべての企業で重要なテーマとなっています。規制当局によって義務付けられたコンプライアンス・イニシアチブは、企業に対してセキュリティ対策の追跡と文書化を要求しています。適切なツールを使用することで、企業はポリシーをコードとして実装し（Open Policy Agentがその一例）、承認されたソフトウェアセキュリティスキャナーの使用を強制し、文書化することができます。これにより、スキャンツールの使用を標準化し、コンプライアンス監査に迅速かつ容易に合格できるようになるという利点があります。

開発プロセスへのセキュリティガードレールの追加

標準化されたソフトウェアセキュリティスキャンツールの使用を要求し、強制するだけでは十分ではありません。スキャナの出力から情報を得ることができるセキュリティゲートやガードレールを提供することも重要である。ここでも、コードとしてのポリシーは、リアルタイムのスキャニングツールの出力を使用して CI/CD パイプラインのワークフローを制御するために使用することができます。

DevSecOpsをビッグデータの問題として扱う

DevOpsの動きは、新しいツールの普及を招き、大量のデータを生み出しました。同様に、DevSecOpsの動きは、膨大な量のデータ出力を伴うより多くのツールを必要としています。本番アプリケーションのセキュリティ脆弱性を低減し、ビジネスリスクを最小化するためには、ツーリング出力の分析が重要です。正規化、重複排除、圧縮、相関関係などのビッグデータ技術を使用して、結合されたスキャナ結果のセットを迅速かつ効率的に分析する必要があります。

エンジニアリングチームの負担を軽減 

DevSecOps の定義は、「アプリケーション・セキュリティの左遷」というぐらいに単純なものです。これは単純化しすぎですが、DevSecOpsはより多くの作業負荷をエンジニアリングチーム、より具体的には開発者にシフトするという事実を浮き彫りにしています。このことを念頭に置いて、DevSecOpsのプラクティスの採用は、エンジニアリング・チームに過度の負担をかけないようにすることが肝要です。

CI/CD パイプラインに複数のセキュリティスキャナを追加した場合の「ビッグデータ」結果につ いては、すでに説明した。適切なツールを提供しなければ、開発者は、どの脆弱性を修正すべきか、修正の優先度を決定するためのデータ分析を手作業で行い、関連するすべてのワークフロー（Jira チケットの作成、例外の追跡など）を実行する必要がある。エンジニアチームのこの負担を軽減しなければ、DevSecOpsの導入は著しく困難です。当然ながら、次の質問は、"どのようにしてエンジニアリングチームのこの負担を減らすか？"です。その答えは、ツールとワークフローの適切な組み合わせを使用することです。適切なツールを選択するためのガイダンスとして、当社のDevSecOpsチェックリストをご覧ください。

チケットの作成と追跡を自動化 

検出されたすべての脆弱性には、関連する Jira チケットが必要です。エンジニアリングチームとITセキュリティチームの効率化のために、これらのチケットは自動的に作成されるべきです。検出された脆弱性が誤検出の場合でも、監査目的のためにチケットは必要です。適切なツールは、これらのJiraチケットを作成し、脆弱性が検出されたアプリケーションサービスと関連付けることができます。脆弱性が修正されたとき（そして修正が確認されたとき）、チケットは自動的に更新され、閉じられるはずです。

必要に応じてツールをアップデート 

これまで述べてきたほぼすべてのベストプラクティスは、自動化や分析を支援するツールを必要とします。従来のITセキュリティツールは、最新のDevOpsプラクティスやクラウドネイティブテクノロジーを念頭に置いて設計されたものではありませんでした。企業は、DevSecOps プログラムを成功させるために、必要なツールを再評価する必要があります。

多くの企業が、構築か購入かの決断に頭を悩ませています。刻々と変化する状況に対応するために複雑なツールを構築することは、一般的にほとんどの企業にとって維持することが現実的ではありません。したがって、組織のニーズに合ったツールを評価する際に、当社のDevSecOpsチェックリストが参考になることがあります。

ワークフローへの投資 

新しい脆弱性が検出された場合はどうなりますか？セキュリティ免除の申請と追跡はどのような手順で行われるのですか？セキュリティの適用除外について、他のチームにどのように通知するか？これらのプロセスやワークフローの中には、組織内にすでに存在するものもあれば、新たに作成する必要があるものもある。既存のものであれ新たに作成するものであれ、これらのワークフローはすべて、組織全体でセキュリ ティ対策の規模を拡大するために自動化する必要がある。

アプリのライフサイクル全体を考慮する 

すでにDevSecOpsを採用しているのであれば、成果物が本番環境に到達した後にセキュリティスキャンを実行するだけでは十分でないことを理解しているはずです。セキュリティスキャンは、アプリケーションサービスの全ライフサイクルにわたって実施する必要があります。

• CIパイプライン
• ソフトウェア構成分析（SCA） - アプリケーション・サービスを構築するために使用されるオープンソース・ソフトウェアやサードパーティ・コンポーネントの脆弱性を特定します。
  SCAツールの例。Black Duck SCA、Snyk、WhiteSource SCA。
• 静的アプリケーションセキュリティテスト(SAST) - アプリケーションのソースコードまたはバイトコードに対して静的コード解析を行います。
  SASTツールの例。Brakeman、SonarQube、ShiftLeft。
• CDパイプラインと生産オペレーション
• IaC（Infrastructure as Code）テスト - インフラセキュリティのサブセットである、Software-Defined Compute、Network、Storageの脆弱性評価。
  IaCテストツールの例。Checkov、TFLint、Terrafirma。
• ダイナミック・アプリケーション・セキュリティ・テスト（DAST） - は、アプリケーションを実行時に解析し、脆弱性があるかどうかを判断します。
  DASTツールの例。MicroFocus Fortify、OWASP ZAP、HCL AppScan。
• インタラクティブ・アプリケーション・セキュリティ・テスト（IAST） - は、SASTとDASTの要素を組み合わせたもので、通常はJVMやCLRの中で使用されます。
  IASTツールの例。Checkmarx IAST, HCL AppScan Enterprise, Synopsys Seeker.
• コンテナセキュリティテスト - アプリケーションコンテナやKubernetes構成のセキュリティ分析。
  コンテナテストツールの例。Qualys、Docker Bench for Security、Aqua Container Securityなど。
• ファズテスト - 実行中のアプリケーションに意図的に悪い情報を送り込み、セキュリティの脆弱性の状態を判断する。
  ファズテストツールの例 Beyond Security beSTORM、Synopsys Fuzzing Test Suite、Google OSS-Fuzzなど。
• APIテスト - セキュリティ上の問題を特定するために、APIエンドポイントに特化したテストを実施します。
  APIテストツールの例。Apigee、Katalon Studio、Astra。

おわりに セキュリティツールとプロセスを更新して、変化のスピードに対応する

DevSecOpsは、単に開発者にセキュリティテストを実行させるだけではありません。開発者優先の考え方でセキュリティを自動化し、情報セキュリティを少数のセキュリティ専門家チームの枠を超えて拡大し、エンドユーザーまで到達するセキュリティリスクを低減することなのです。大きな課題は、ソフトウェアの提供速度を落とさずに、これらすべてを達成することです。

今日、アプリケーション内で使用されるクラウドネイティブテクノロジーやオープンソースコンポーネントの急増に伴い、セキュリティツールやプロセスは、変化の速度に対応するために更新される必要があります。従来のセキュリティツールやプロセスは、現代の環境では目的に適合していません。

Harness Security Testing Orchestration（STO）は、本記事で取り上げたベストプラクティスの実装を支援します。STOは、ソフトウェアデリバリライフサイクル全体にわたってセキュリティスキャンをシームレスに統合し、ポリシーアズコードガバナンスを提供し、DevSecOpsプログラムの成功に必要なビッグデータ分析を実行することができます。DevSecOpsの実践を採用する準備はできていますか？カバーすべき主要な機能をまとめたチェックリストをダウンロードしてください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。