前編では、米国食品医薬品局（FDA）が推進するレギュラトリーサイエンスのDevSecOpsを取り上げたが、後編では、クラウドセキュリティアライアンス(CSA)におけるDevSecOpsの取り組みを紹介する。

再帰的セキュリティの視点に立ったDevSecOpsの重要6領域

CSA DevSecOps WGは、2019年8月1日、「再帰的セキュリティを通じた情報セキュリティ管理」を公開した（https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security ）。その中で、「再帰的セキュリティ」について、組織のセキュリティのスタンスおよび配布物を保護するために必要な、セキュリティ、開発、運用の間の相互関係に基づいた、新たなセキュリティ管理手法と定義している。

その上で、DevOpsについて、集団的コラボレーションのような開発のベストプラクティスをインフラストラクチャの運用に適用させるプラクティスであり、特にクラウド環境における開発・運用チームの効率性にポジティブなインパクトを示してきたとしている。その採用を強化するためには、情報セキュリティ自体へのインパクトを考慮し、情報セキュリティ管理領域へのプラクティスの適用に目を向ける必要があるとしている。

その直後の2019年8月7日、CSA DevSecOps WGは、「DevSecOpsの6つの柱：セキュリティ、開発、運⽤の統合による再帰的セキュリティの実現」を公開している（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-of-devsecops）（日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/11/The-Six-Pillars-of-DevSecOps-Achieving-Reflexive-Security-Through-en_us-ja.pdf）

この文書では、ソフトウェアの開発と公開における複雑さを軽減し、既知の信頼できるコンポーネントとサービスのみを使⽤するようにし、開発⼿法に直接統合されたセキュリティリソース（⾃動化されたものと⼈の⼿によるものの両⽅）をソフトウェア開発チームに提供し、セキュリティが⼗分に確保され、監視された開発環境を使⽤し、最終的に、設計どおりに、設計された機能のみを備えた最終製品を提供することを目標としている。

DevOpsは、集団的コラボレーションなどの開発のベストプラクティスをインフラストラクチャ運⽤に適⽤するプラクティスであり、特にクラウド環境において、今⽇の開発および運⽤チームの効率にプラスな影響を与えることが⽰されている。CSA DevSecOps WGは、ISO/IEC 27000 ファミリー規格および前述の「再帰的セキュリティを通じた情報セキュリティ管理」を参照しながら、以下の通り、DevSecOps を実装し組織に統合するために不可⽋な、DevSecOps の6つの重点分野を定義している。

[第1の柱：集団的責任]

DevOpsにセキュリティを組み込む際の大きな課題の1つが、ソフトウェアセキュリティに関する組織のマインドセットや、アイデア、習慣、行動の変更である。セキュリティのDevOps組織への導入により、セキュリティは、他の誰かの責任としてみなすことができなくなっている。それは、誰か他の業務が完了した時のみに取組むべき補足事項と考えるべきでない。加えて、セキュリティは、ビジネス目標から切り離し、区別して見ることができない。最後に、セキュリティは、いくらか一時的なもので、進化や貢献が評価できない。

組織のセキュリティのスタンスに関して、誰もが責任を有する。CSO（クラウドセキュリティオフィサー）は、組織内の情報セキュリティに関して、リーダーおよび羊飼いの役割を果たすが、個々人は、自身のセキュリティ責任を有しており、組織のセキュリティのスタンスに対する自身の貢献を認識しなければならない。エッジのユーザーや開発者は、単に”セキュリティの認識がある”のではなく、防御の第一線にいる。これが再帰的セキュリティフレームワークの「集団的責任」に対応している。

[第2の柱：コラボレーションと統合]

開発、運⽤、セキュリティの各分野において、ソフトウェア業界には膨⼤なスキル（知識）と⼈材（リソース）のギャップが存在する。セキュリティの導⼊に関して組織全体が協⼒しなければ、成功は限られたものになる。セキュリティは、対⽴ではなく協⼒によってのみ達成できる。すべての機能チームのメンバーが潜在的な異常を報告できるようにするためには、セキュリティを意識した協⼒的な⽂化が必要です。⼈的要因はしばしば最も弱いリンクであり、実際に、セキュリティインシデントのほとんどは、単純なヒューマンエラーによって引き起こされることを覚える必要がある。これが「再帰的セキュリティ」のフレームワークの「協⼒と統合する」に対応している。

[第3の柱：実践的な実装]

DevSecOpsでは、ポイントソリューションが数多く提供されている。組織は、ソフトウェアライフサイクルの中でアプリケーションセキュリティを実装するために、さまざまなツールやソリューションを選択できる。ソフトウェアライフサイクルは、構造、プロセス、全体的な成熟度においてそれぞれ異なるため、DevSecOpsを実装するための万能なツールは存在しない。
組織はしばしば、導⼊が難しく、運⽤が困難で、結局は真のセキュリティリスクの軽減に役⽴つ、実⽤的な洞察を提供しないツールやポイントソリューションの調達に終始する。

組織は、ソフトウェアのライフサイクル、組織⾃⾝のセキュリティのニーズ、そして求める将来の状態を総合的に捉え、⾼度な統合性を提供するプラットフォームソリューションを選択する必要がある。デジタル社会における安全、プライバシー、および信頼を確保するために、アプリケーション開発に焦点を当てたフレームワークにとらわれない「デジタルセキュリティとプライバシーモデル」を使⽤することで、組織はDevOpsにおけるセキュリティに実⽤的な⽅法でアプローチできる。このモデルは、すべての利害関係者（開発、運⽤、セキュリティ）を、セキュリティが、アプリケーションとアプリケーションを⽣み出すソフトウェアライフサイクルに組み込まれる形で組み込まれるという、現状では満た
されていないニーズを満たすものである。これが、「再帰的セキュリティ」の枠組みにおける「実践的な実装」に対応している。

[第4の柱：コンプライアンスと開発の橋渡し]

リスクに関連した要求事項を、時間の経過に従って容易に評価できるセキュリティ要求事項に変換することは難しい。セキュリティチームがリスクベースの⼿法をサポートするために要件を作成するとしても、コンプライアンス要件はDevOpsや製品要件にうまく変換されていない。逆に、技術的なコントロールが実装されていても、セキュリティ要件が満たされているという証拠を得ることは容易でない。

ソフトウェア開発のパラダイムとプラクティスの急速な進化を考えると、コンプライアンスとアジャイルソフトウェア開発はもはや同じ⽴場に置くことができない。規制・コンプライアンス部⾨は、その各プロセスの実⾏を実際に監査することよりも、プロセスが存在することを証明することに関⼼がある。⼀⽅で、ほとんどのDevOpsチームは、証明はコードの中にあり、プロセスの⽂書化の中にはないと考えている。

コンプライアンスと開発の間のこのギャップに対処する鍵は、適⽤可能なコントロールを特定し、それを適切なソフトウェア対策に変換し、ソフトウェアライフサイクル内の変曲点を特定し、そこでこれらのコントロールを⾃動化して測定することにより、リスク軽減の質を向上させ、その結果、コンプライアンスを改善することである。これが、「再帰的セキュリティ」の枠組みにおける「整列と橋渡し」に対応する。

[第5の柱：⾃動化]

最⼩限のコストで迅速にセキュアな配備を実現するためのソフトウェア開発⼿法を妨げている課題のいくつかは、⼿作業による⾏き当たりばったりのコーディング、テスト、デプロイ、およびパッチの適⽤である。

⾃動化された品質チェックがなければ、⼿作業によるコーディングは容易に、⼿直しが必要なパフォーマンスの低い、セキュアでないソフトウェアになる。さらに、⼿作業やタイミングの悪いテストでは、デプロイ前に脆弱性が特定される可能性を低くする。⼿作業によるデプロイとパッチの適⽤は、セキュアでないソフトウェアを本番環境にリリースする可能性がある。

⾃動化されたセキュリティ対策は、⼿作業によるプロセスを減らし、効率を⾼め、⼿戻りを減らすことができるため、プロセス効率の中核となる。ソフトウェアの品質は、テスト／フィードバックの徹底性、適時性、および頻度を改善することによって向上できる。⾃動化できるプロセスは⾃動化し、⾃動化できないプロセスは可能な限り⾃動化するか、廃⽌を検討すべきである。⾃動化されたセキュリティチェックは、ビルドの遅延や失敗といった新たな課題を引き起こす可能性があるが、これらは通常、ワークフローの改善や半⾃動化アプローチで対処できる。ソフトウェア開発には、「同じことを3回やったら、そろそろプログラミングの時期だ」という格⾔があり、これは、再帰的セキュリティに正⾯から当てはまる。これが、再帰的セキュリティの枠組みにおける「⾃動化」に対応する。

[第6の柱：測定、監視、報告および⾏動]

「測定できない（あるいは測定しない）ものは管理できない」という格⾔は、DevSecOpsの実装と保守によく当てはまる。⼀般的なDevSecOpsイニシアチブは、スコープと複雑さにもよるが、実装に数ヶ⽉から数年を要する。実⾏可能なメトリクスがなければ、進捗を評価することはできず、失敗をタイムリーに発⾒することもできない。

DevSecOps環境で監視すべき最も重要なメトリクスには、デプロイメントの頻度、脆弱性パッチの適⽤時間、⾃動的にテストされるコードの割合、アプリケーションごとの⾃動テストがある。DevSecOpsを成功させるためには、ソフトウェア開発中だけでなく、デリバリー後の結果も、適切な⼈々によって適切なタイミングで（継続的に）測定、監視、報告、および対処される必要がある。これが、再帰的セキュリティのフレームワークの枠組みにおける「測定と改善」に対応する。

その後、CSA DevSecOps WGは、以下の通り、個々の6領域に関する成果物を公開している。

・「DevSecOpsの6つの柱：集団的責任」（2020年2月21日公開）
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility）
・「DevSecOpsの6つの柱：コラボレーションと統合」（2024年2月20日公開）
（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-collaboration-integration）
・「DevSecOpsの6つの柱：実践的な実装」（2022年12月14日公開）
（原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-pragmatic-implementation）
・「DevSecOpsの6つの柱：コンプライアンスと開発の橋渡し」（2022年2月8日公開）
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development）
・「DevSecOpsの6つの柱：⾃動化」(2020年7月6日公開)
（原版：https://cloudsecurityalliance.org/artifacts/devsecops-automation）
（日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/04/DevSecOps-Automatio-ja.pdf）
・「DevSecOpsの6つの柱：測定、監視、報告および⾏動」
（原版：https://cloudsecurityalliance.org/artifacts/the-six-pillars-of-devsecops-measure-monitor-report-and-action）

アプリケーションセキュリティを起点とするOWASP DevSecOpsガイドライン

他方、医療機器サイバーセキュリティやIoTセキュリティの領域において、CSAと連携してきたOWASPは、アプリケーションセキュリティの観点から、「OWASP DevSecOpsガイドライン」を作成・公表している（https://owasp.org/www-project-devsecops-guideline/）。

このガイドラインは、セキュアなパイプラインを実装し、ベストプラクティスを利用して、このような方法で利用可能なツールを導入する方法について説明している。また、このプロジェクトは、開発プロセスにおけるシフトレフトのセキュリティ文化の促進を支援するものである。重要な目標は、”できるだけ早くセキュリティ課題（バイ・デザインやアプリケーション脆弱性）を検知する”ことである。

そして、DevSecOpsの目的・意図は。必要な安全性を犠牲にすることなく、最大のコンテキストレベルを保持する人々に対して、スピードと拡張性のあるセキュリティの意思決定を安全に提供するという目標を持った”誰もがセキュリティに責任がある”というマインドセットの上に構築されている。

このガイドラインは、以下のような構成になっている。

• 0 – イントロダクション
  • 0-a – 概要
  • 0-b – 脅威モデリング
• 1 – コミット前
  • 1-a – 秘密管理
  • 1-b – コードの検査（Linting）
• 2 – 脆弱性スキャン
  • 2-a – 静的（Static）アプリケーションテスト
  • 2-b – 動的（Dynamic）アプリケーションテスト
  • 2-c – インタラクティブな（Interactive）アプリケーションテスト
  • 2-d – ソフトウェア構成分析
  • 2-e – インフラストラクチャ脆弱性スキャン
  • 2-f – コンテナ脆弱性スキャン
  • 2-g – プライバシー
• 3 – コンプライアンス監査

OWASPでは、基礎的パイプラインにおいて、以下のようなステップで実装することを考えている。

• 潜在的な資格情報の漏えいを見つけるためのgitスキャン
• SAST（静的アプリケーションセキュリティテスト）
• SCA（ソフトウェア構成分析）
• IAST（インタラクティブなアプリケーションセキュリティテスト）
• DAST（動的アプリケーションセキュリティテスト）
• IaCスキャンニング（構成ミスを見つけるためのTerraform,、HelmChartコードのスキャン）
• インフラストラクチャスキャンニング
• コンプライアンスチェック

サプライチェーンセキュリティの視点に立った米国NISTの取り組み

さらに、ソフトウェアのサプライチェーンセキュリティの視点から、DevSecOpsの標準化に取り組んでいるのが、米国立標準技術研究所（NIST）である。NIST傘下の国家サイバーセキュリティセンター・オブ・エクセレンス（NCCoE）は、2022年11月9日、「ソフトウェアサプライチェーンとDevOpsセキュリティプラクティス：DevSecOpsに対するリスクベースのアプローチ」を公開している（https://www.nist.gov/news-events/news/2022/11/software-supply-chain-and-devops-security-practices-implementing-risk-based）。

この文書は、国家サイバーセキュリティセンター・オブ・エクセレンス（NCCoE）のプロジェクトについて記述したものであり、DevSecOpsプラクティス向けに適用されたリスクベースのアプローチや推奨事項の開発および文書化に焦点を当てている。このプロジェクトでは、「DevSecOps」について、セキュリティチームが構築したセキュリティプラクティスを、既存のパイプライン（例．継続的統合／継続的デリバリー[CI/CD]）や、開発者が利用し、運用チームが管理する既存のツールチェーンに統合することとしている。NISTのアプローチは、セキュアソフトウェア開発フレームワーク（SSDF）やNISTサイバーセキュリティフレームワークで利用したものと同じである。本プロジェクトは、クラウドネイティブな方法におけるソフトウェアデリバリーの速度や容量を維持し、自動化ツールの利点を活かすことを実現するのに役立てるものだとしている。また、本プロジェクトは、NIST SSDFからのプラクティスやタスクを、DevSecOpsアプローチの一部として実装できる方法を決定するものだとしている。

NISTのこの文書は、以下のような構成になっている。

• 1 エグゼクティブサマリー
  • 目的
  • スコープ
  • 想定／課題
  • 背景
• 2 シナリオ
  • シナリオ 1：フリー／オープンソースソフトウェア（FOSS）開発
  • シナリオ 2：クローズドソース・ソフトウェア開発
• 3 ハイレベルアーキテクチャ
  • コンポーネントリスク
  • 望ましいソフトウェアのケーパビリティ
• 4 関連する標準規格およびガイダンス
  • セキュリティコントロールマップ
  • 附表A 参考文献
  • 附表B 頭字語と略語

なお、CSAと連携しているMITREや国防総省なども、DevSecOpsに関する文書やガイダンス類を作成しており、参考になる。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司