世界のDevSecOps現状レポート 2023年

中抜き

シノプシスの2023についてDevSecOps現状調査報告

2023年初頭にシノプシスサイバーセキュリティリサーチセンター（CyRC）は、国際的な市場調査コンサルタント会社であるCensuswideと共同で、セキュリティ担当のITプロフェッショナル1,000人を対象に調査を実施した。回答者には、開発者、AppSecの専門家、DevOpsのエンジニア、CISO、インテクが含まれる、サイバーセキュリティおよびアプリケーション/ソフトウェア
米国、英国、フランス、フィンランド、ドイツ、中国、シンガポール、日本から、開発分野でさまざまな役割を担う専門家がインタビューに答えている。
業種や企業規模に関係なく、すべての回答者が調査に参加することができた。この調査を開発する上での課題の1つは、「DevSecOps」という用語が複数の分野を包含しており、その多くが独自の役割を担っていることでした。この調査では、「直接」コードを書く開発者と、ソフトウェア・セキュリティに携わるCISOレベルの人の両方を含む、さまざまな専門的背景を持つ人々を対象にしたいと考えた。

DevOpsとDevSecOpsについて

開発の加速、継続的デリバリー、パイプラインの回復力、スケーラビリティ、エンドツーエンドの透明性は、DevOpsを実現するための重要な原則である。これらの基準を満たすには、開発、セキュリティ、運用が協調して取り組む必要がある。

DevSecOpsは、DevOps手法の拡張であり、複数のチームにセキュリティ文化を浸透させ、DevOps環境において早期に一貫してセキュリティに対処し、常にセキュリティプラクティスをソフトウェア開発に統合するように設計されている。
ライフサイクルどうきデータリンクせいぎょ)やCIパイプラインを活用することで、DevSecOpsはセキュリティを単独のフェーズから開発ライフサイクルの一部へと変革することを目指している。

DevSecOpsは、ソフトウェア開発に携わる組織全体で人気を博しており、SANS State of DevSecOps Survey 2023によると、DevSecOpsは重要なビジネスプラクティスとリスク管理へのアプローチになっている。しかし、これまでは、セキュリティをプロセスに組み込もうとすると、セキュリティチームと開発チームがしばしば意見が対立してきた。

この練習は、従来のアプリケーションのセキュリティテスト（AST）ツールをソフトウェア開発ライフサイクル（SDLC）に組み込む。開発者はしばしば、ASTツールは複雑すぎる、習得が難しい、性能が低い、多くの「ノイズ」を発生させて「摩擦」⸺を生じさせる、つまり、ソフトウェア開発プロセスにおいて開発者が簡単かつ迅速にコードを構築することを妨げるものである、と不満を漏らす。つまり、ソフトウェア開発プロセスにおいて、開発者が簡単かつ迅速にコードを構築することを妨げるものである。回答者の大多数は、使用しているASTツールに全般的な不満を表明している。

自動化のメリット

DevOps の核となる原則は、SDLC のあらゆる段階で手動プロセスを自動化することである。自動化は、継続的インテグレーションや継続的デプロイメントによって開発とコードの配信を加速するために、どのような組織にとっても不可欠な前提条件である。
DevSecOps を成功させるには、統合と自動化、そして標準とポリシーのガイダンスが必要である。これによって、セキュリティチームは、セキュリティの利益が守られているという確信を得ることができ、一方、DevOps チームは、パイプラインの中断が起こらないという確信を持ちながら、作業を続けることができる。手動のテストとは異なり、自動化されたセキュリティテストは迅速かつ一貫して実行できるため、開発者は納品スケジュールや生産性に影響を与えることなく、開発プロセスの早い段階で問題を特定できる。

• 一貫性
  自動化されたテストによって、すべてのビルドとデプロイメントで一貫したセキュリ ティチェックが確実に実行される。手作業によるテストでは、テストプロセスとカバレッジに一貫性がなくなる可能性がある。
• スケーラビリティ
  ソフトウェアが複雑になればなるほど、手動テストは非現実的になる。自動化されたテストは、さまざまなコンポーネントにまたがる多数のテストを可能にするため、簡単に拡張できる。
• 継続的インテグレーションと継続的デプロイメント（CI/CD）
  自動テストは、迅速かつ頻繁なコード変更が発生するCI/CDパイプラインにおいて非常に重要である。自動化されたテストは、変更を素早く検証し、バグのあるコードが本番環境に入るのを防ぐことができる。
• 継続的改善
  自動化されたテストは、開発チームとセキュリティチームが長期にわたってセキュリティ対策を改善するのに役立つデータと洞察を提供し、脆弱性のパターンを体系的に分析して対処することを可能にする。
• きろく
  自動化されたテストでは、テストプロセス全体が文書化されるため、セキュリティ対策やコンプライアンス要件の追跡や監査が容易になる。
• ヒューマンエラーの削減
  手作業によるテストは、疲労や過失によるエラーが発生しやすい。自動テストは事前に定義されたスクリプトに従うため、ヒューマンエラーのリスクを減らすことができる。
• 時間とコストの節約
  開発プロセスの後半や生産中に安全上の問題を特定して修正するのは、時間とコストがかかる。自動テストは、このようなコストを最小限に抑えます。
• 開発者エクスペリエンスの向上
  自動化されたアプリケーション・セキュリティ・テストによって、開発者は、セキュリティの知識とスキルの学習と向上に貢献するセキュリティ問題への積極的で全体的なアプローチを取ることができるようになり、それによって開発者の経験値が向上し、最終的には開発プロセス全体を通じてソフトウェアのセキュリティと効率が改善される。

DevSecOpsにおけるASOC/ASPMの利用拡大

本レポートでは、DevSecOps の成熟度が異なる段階にある組織について、その特徴や採用しているセキュリティツール／プラクティスなどを調査する。調査結果に基づき、ソフトウェアセキュリティ成熟度のさらなる向上を支援するための指針となる推奨事項を提供する。
興味深いことに、この調査結果では、アプリケーション・セキュリティ・オーケストレーションと相関（ASOC）（現在では一般的にアプリケーション・セキュリティ状況管理（ASPM）と呼ばれている）の利用が普及していることが示されている。ガートナー社によると、ASPMは、複数の開発ツールやセキュリティ・ツールを使用している組織にとって優先事項であるべきだという。

ASPM ツールは、複数のソースからデータを取得し、それを相関・分析することで、解釈、分類、修復を容易にする。
ASPM はまた、セキュリティ・ツールの管理およびオーケストレーション・レイヤーとして機能し、セキュリティ・ポリシーの制御と実施をサポートする。ASPM はアプリケーション・セキュリティの結果を統合的に表示するため、アプリケーションやシステム全体のセキュリティとリスクの状態を完全に把握することができる。
これらの1,000人の回答者のほとんどが、使用しているASTツールに全般的に不満を持っており、ビジネスニーズに基づいて修正に優先順位をつけたり（35%）、問題を解決するためにデータをマージ／関連付けることができない（29%）と不満を述べていることを考えると、ASOC/ASPMの利用が急速に増加しているのも納得がいく。ASPMの利用が急速な成長傾向を示していることは理にかなっている。

シノプシスの「State of DevSecOps Survey 2023」の主な調査結果

DevOpsチームの大半はDevSecOpsをある程度採用しており、回答者の合計911 TP3Tは、DevSecOps活動を実施するための特定のセキュリティ対策をソフトウェア開発パイプラインに組み込んでいると回答した。DevSecOps手法の採用は、今やソフトウェア開発の一部になっていると言っていいだろう。
291 TP3Tの回答者は、開発、セキュリティ、運用のメンバーで構成される機能横断的なDevSecOpsチーム（コラボレーションチーム）があり、それがセキュリティプログラムの成功の重要な要因であると回答した。成熟したセキュリティプログラムを持つ組織では、セキュリティに重点を置き、開発者／ソフトウェアエンジニア、および／または、QAやテストと協働する人々が、セキュリティテストの最前線にいる可能性が高い。

効果的なDevSecOpsの実装には多くの障壁がある。

回答者の33%以上が、主要な障害として警備訓練の不足を挙げた。次いで、警備要員の不足（31%）、開発／運営における透明性の欠如（31%）、優先順位の変化（30%）と続いた。

回答者の 3 分の 1 以上が、ビルド／デプロイメントのワークフローに自動セキュリ ティテストを組み込むことがセキュリティ対策の成功に不可欠であると回答した。開発、運用、セキュリティの各チーム間のコミュニケーションを改善する。

SDLC の後半で重大な脆弱性に対処することは、利益を大きく損なう可能性がある。

回答者の80%以上が、2022年から2023年にかけて、配備されたソフトウェアの重大な脆弱性／セキュリティ問題が何らかの形で仕事の進捗に影響を与えたと回答した。
回答者の 28% が、導入済みアプリケーションの主要なセキュリティリスク/脆弱性のパッチ適用に最長 3 週間かかると回答し、さらに 20% が最長 1 カ月かかると回答した。
この数字は、脆弱性がかつてないほど速く悪用されていることを考えると、特に問題である。最近の調査によると、全脆弱性の半数以上が公開から1週間以内に悪用されている。

回答者の 70% 以上が 表 1 は、セキュリティホールやその他の欠陥のためにコードをスキャンするために一般的に使用されてきた自動化されたスキャ ン手段の種類を示しています。「ツール／プロセスの有用性」のカテゴリでは、「SDLC の要求事項発掘フェーズにおけるセキュリティ要 件の明確化」と「BSIMM や SAMM のようなモデルによるソフトウェアセキュリティプランの正式な評価」が第 1 位でした。これに僅差で「SDLC の要件発見フェーズにおけるセキュリティ要件の明確化」と「BSIMM や SAMM のようなモデルによるソフトウエアセキュリティプランの正式な評価」が続いた。

ほぼすべての回答者が、ASTツールは自社のビジネスニーズに適合していないことに同意した。

1,000人の回答者のほとんどが、ASTツールの主な課題として、ビジネスニーズに基づいた修正の優先順位付けができない（35%）、問題解決に役立つデータのマージ／関連付けができない（29%）など、ASTツールの幅広い問題を挙げている。
52%セキュリティ専門家は、DevSecOpsイベントでAIと積極的に協力し始めたが、4分の3以上がAIの使用に懸念を抱いている。
この調査結果は、セキュリティチームがAI、機械学習、自然言語処理、ニューラルネットワークを積極的に活用していることを示唆している。しかし、AIによるコーディング・アドバイスのような生成的なAIツールの利用が増えたことで、AIが生成したコードをめぐるさまざまな知的財産権、著作権、ライセンスの問題が生じ、場合によっては訴訟にまで発展している。

2023年DevSecOpsの現状調査

DevSecOpsの展開

回答者 1,000 人のうち 3 分の 1 以上が、自社のセキュリティ対策が成熟度レベル 3 に達していると感じている。この成熟度レベル 3 では、セキュリティ対策プロセスが文書化され、反復可能で、組織全体で標準化されている。さらに 251 TP3T の回答者が、自社のセキュリティプログラムが成熟度レベル 4 に達していると感じている。
911人のTP3T回答者が、ソフトウェア開発パイプラインに何らかのDevSecOps活動を適用していると回答しており、DevSecOpsの採用はDevOpsの一部として定着しているようだ。

貴組織の現在のソフトウエアセキュリティプロジェクト・プログラムは、どの程度の成熟度にあると考えますか。

セキュリティの実践は、より高い成熟度を意味する。

図に示すDevSecOpsの成熟度を示すもう1つの指標は、回答者が継続的な監視と評価（30%）から自動テスト（28%）に至るまで、幅広いセキュリティ対策を採用していることを示している。
358 人の回答者（35.1%）からベストプラクティスとして引用されたセキュリティリスク管理は、ソフトウェアアプリケーションに関連する潜在的なセキュリティリスクを特定し、評価し、緩和するために、開発プロセスの各段階でセキュリティの考慮事項を統合することを含みます。SDLC の枠組みの下では、全体的なセキュリティリスク管理は、以下の活動を対象としています。

• 要求事項分析。SDLC の早い段階でセキュリティ要求事項と制約事項を特定し、セキュリティ目標を定義する。
• 設計する。セキュリティの原則をシステムアーキテクチャと設計に組み込み、一般的な脆弱性に対する適切な保護手段を備えたアプリケーションを設計できるようにする。
• 開発。セキュアコーディングを実践し、セキュリティ問題に対処するコーディング標準を遵守する。静的アプリケーション・セキュリティ・テスト（SAST）やソフトウェア構成分析（SCA）などの統合セキュリティ・テスト・ツールを使用して、コードを書いたり、オープンソースやサードパーティのコードを導入したりするときに脆弱性を把握する。
• テストアプリケーションの脆弱性を特定するために、SAST、DAST（Dynamic Application Security Testing）、SCA、侵入テストなど、さまざまな種類のセキュリティテストを実施する。
• デプロイメント。アプリケーションを実行する環境を安全に設定する。アクセス制御、ネットワークセキュリティ、適切な認証と承認の仕組みを実装する。
• 監視と評価本番環境のアプリケーションを継続的に監視し、セキュリティイベントと異常を検出する。ロギングと監視のソリューションを導入して、以下を検出する。
• TP3Tの回答者301人は、これが組織で採用されている主要なセキュリティ対策であると回答した。
• 対応と修復セキュリティ・インシデントを迅速かつ効率的に処理するためのインシデント対応計画を策定する。テスト段階で検出された問題を修正する。
• 透明性とセキュリティ。明確な規範、基準、戦略を確立し、セキュリティリスクとリスク許容度を報告する。
• トレーニング開発チームに対して、セキュアコーディングの実践、一般的な脆弱性、セキュリティのベストプラクティスに関するトレーニングを提供し、開発者がセキュリティ問題に積極的に対処できるようにする。残念ながら、34% の回答者は、「開発者／エンジニアに対する不十分／非効果的なセキュリ ティトレーニング」を、組織における効果的な DevSecOps 実装の主な障壁の 1 つとして挙げている。
• 継続的な改善。SDLCにおける安全プロセスと実践を定期的に見直し、改善する。

あなたの組織では、どのようなセキュリティ対策を行っていますか？(該当するものすべてにチェックを入れてください）

セキュリティ・プランの評価

TP3Tの回答者701人近くが、ソフトウェアセキュリティアーキテクチャ成熟度モデル（BSIMM）のようなアセスメントツールで自社のセキュリティプログラムを評価することは有用であると回答し、3分の1以上がそのようなアセスメントを「非常に有用である」と評価した。
また、BSIMM のようなツールは、データに基づく客観的な分析を提供し、それに基づいてリソース、時間、予算、優先順位に関する意思決定を行うことができる。また、BSIMM のようなツールは、データ駆動型の客観的な分析を提供し、それに基づいてリソース、時間、予算、優先順位に関する意思決定を行うことができる。セキュリティプログラムを開始したばかりの場合でも、変化するビジネスニーズやセキュリティニーズに対応するために既存のプログラムを適応させる場合でも、自社のソフトウェアセキュリティプログラムを他と比較することは、戦略の指針となる。
ソフトウエアセキュリティプログラムの責任者である場合、または開発を始めたばかりの場合、同業者の AppSec トレンドを理解することで、セキュリティの取り組みを戦略的に改善することができる。技術的な観点からセキュリティプログラムを管理している場合は、BSIMM 評価や SAMM（Software Assurance Maturity Model：ソフトウェア保証成熟度モデル）評価から得た情報を利用して、セキュリティチャンピオン（Security Champions）プログラムの開発など、人材やプロセスの戦術的な改善を行うことができる。

実際、BSIMM の報告書によると、多くのソフトウエア・セキュリティ・チームが最初に行うことの 1 つは、ソフトウエア・セキュリティの推進者でありながらソフトウエア・セキュリティ・チームとは直接関 係のない人物を特定することである。これらの人物は「ソフトウ ェア・セキュリティ・アドボケイト」と総称され、ソフトウエアセキュリティの取り組みを支援し、推進することができる。331 TP3T の回答者は、ソフトウエアセキュリティプログラムの成功の重要な要因の一つとして、セキュリ ティ擁護者プログラムの開発を挙げた。

BSIMMやSAMMのようなモデルによるソフトウェアセキュリティの形式的評価の有効性。

DevSecOps成功のためのクロスファンクショナルチームの重要性

29%の回答者は、機能横断的なDevSecOpsチーム（開発、セキュリティ、運用の各担当者による共同チーム）がセキュリティプログラムの成功の鍵であると指摘している（付録Q16参照）。セキュリティ専門家は、開発者／ソフトウェアエンジニア、および／または、QAチームやテストチーム（正式なDevSecOpsチームの一部であるかどうかは問わない）と協力して、セキュリティテストの最初の防衛線となり、組織がより成熟したセキュリティプログラムを構築するのを支援することができる。
セキュリティチームによる配備前後のテストという単一のパイプラインは、過去のものとなった。今日のソフトウエア開発環境では、セキュリティテストは、品質保証チーム、開発チーム、運用チームを含むエンジニアリングチーム全体の責任であり、ほとんどのチームがソフトウエア開発ライフサイクルのさまざまな段階でソフトウエアにセキュリティを組み込んでいる。
TP3Tの回答者のうち331人が、自分の組織はセキュリティテストを実施するために外部のコンサルタントにも依頼していると回答した。ここでのベストプラクティスは、定期的なセキュリティ監査を実施することである。このようなテストを実施するために第三者監査人や侵入テスト実施者を雇うことは、組織全体のセキュリティ態勢を客観的に把握する上で非常に貴重である。

あなたの組織では、誰がセキュリティテストの責任者ですか。(該当するものをすべてチェックしてください。）

最適な結果を得るための手動テストと自動テストの組み合わせ

調査結果によると、回答者の大多数は、手動と自動のセキュリティテストを組み合わせることで、ビジネスクリティカルなアプリケーションのセキュリティを評価するためのより包括的なアプローチが提供されると考えている。自動化されたテストは、一貫性、拡張性、時間とコストの節約のために重要であるが、人間が関与することで、複雑で微妙なセキュリ ティ問題を特定するために不可欠な洞察力と適応性の層を追加することができる。例えば、「ブラックボックス」テスト（すなわち、アプリケーションの内部を知らずに行うテスト）として、DAST は、 開発者と開発者の両方がテストプロセスに関与することを要求します。セキュリティの専門家試験結果の検証と分類。
同様に、44% の回答者が外部侵入テストをセキュリティテストの重要な構成要素と考えているという事実は、侵入テストが内部テストを補完する重要なものであることを証明している。外部侵入テストは、業界の規範や標準に準拠するために実施されることが多く、組織のセキュリティ態勢の客観的な評価や、外部の攻撃者に悪用される可能性のある潜在的な脅威や脆弱性の正確なシミュレーションを提供するなどの追加的な利点をもたらすことができます。

ビジネスクリティカルなアプリケーションのセキュリティをどのように評価またはテストしていますか。(該当するものをすべて選択してください）

主要業績評価指標

この調査では、回答者に対して、DevSecOps プログラムの成功を評価するための主要業績評価指標（KPI）の上位 3 つを選択するよう求めた。リストのトップは、295 人の回答者（29%）が挙げた「オープンな脆弱性の全体的な減少」であり、僅差で 288 人の回答者（28%）が挙げた「SDLC の後期に発見されたセキュリティ関連の問題の減少」が続いた。これに僅差で続いたのは、288 人の回答者（28%）が挙げた「SDLC の後期に発見されたセキュリティ関連の問題の削減」であり、3 位は 281 人の回答者（28%）が挙げた「問題解決までの時間」であった。

調査結果が示すように、時間、生産性、コストは、これまでの KPI と組織がセキュアな SDLC を実装するときに直面する課題の 3 つの共通項である。あるいは、言い換えれば、DevSecOps の参加者が直面している 3 つの主要な問題は次のとおりである。

• どうすれば脆弱性／問題に遭遇する回数を減らせるか？
• SDLC の早い段階で脆弱性を見つけるには？
• 問題解決にかかる時間を短縮して、ビルドの遅れを減らし、開発効率を向上させるにはどうすればいいのか。

DevSecOps活動の成功を評価するために使用している主なKPIは何ですか？(3つまで選択）

どんなASTツールを使っていますか？便利ですか？

この調査結果は、DevSecOps 戦略が、動的アプリケーション・セキュリティ・テスト（DAST）、対話型アプリケーション・セキュリティ・テスト（IAST）、静的アプリケーション・セキュリティ・テスト（SAST）、ソフトウェア構成分析（SCA）ツールなど、ソフトウェア開発ライフサイクル全体を通じてコード品質とセキュリティの問題に対処するために、完全なセキュリティ・ツールセットを使用していることを示している。
調査の結果、SASTは最も人気のあるASTツールであり、72%の回答者が有用であると回答した。僅差でIAST（69%）、SCA（68%）、DAST（67%）が続いた。
SAST と DAST は、異なる SDLC フェーズに対して、異なるテスト方法論を使用します。SAST は、SDLC の早期（すなわち、アプリケーショ ンがデプロイされる前）に、プロプライエタリコードの脆弱性を発見し、排除するために重要です。一方、DAST は、デプロイ後に、 認証やネットワーク設定の欠陥のような運用中の問題を発見するのに適しています。SAST は、SDLC の早期（すなわち、アプリケーションが配備される前）に、プロプライエタリなコードの脆弱性を発見し、排除するために重要です。一方、 DAST は、配備後に、認証やネットワーク設定の欠陥のような運用上の問題を発見するために適しています。
SCA は、オープンソースのセキュリティとライセンシングのリスクを特定・管理するのに適しており、特に、任意のアプリケーションのコードの 4 分の 3 以上がオープンソースである可能性が高い場合には、最新のソフトウェア開発における重要な要件となります。多くの組織が、独立系ソフトウェア・ベンダーから購入したパッケージ・ソフトウェアや、モノのインターネット（IoT）デバイスや組み込みファームウェアを使用しているため、ASTツールキットの中で、何らかの形でSCAバイナリ解析を実施する必要があるかもしれません。

あなたの組織で使用している以下のアプリケーションセキュリティツールは役に立ちますか。

いつテストするのか？パッチはいつ適用されるのか？私たちの仕事のスケジュールにどのような影響がありますか？

アプリケーション・セキュリティ・テストの頻度は、アプリケーションの日常的なビジネス上の重要度、業界、脅威の状況など、多くの要因によって異なります。私たちの調査結果が示すように、非常に重要なアプリケーションは、定期的に評価する必要があります（図）。この調査に参加した回答組織のほとんどは、ビジネスクリティカルなアプリケーションの脆弱性スキャンを平均して週に 2～3 日実施していると回答しています。
一見すると、TP3Tが281の組織では、主要な脆弱性のパッチを当てるのに3週間もかかるという調査結果（図I）は心配に思えるかもしれないが、これは他の要因との関連で考えなければならない。伝説的な開発者はすべての脆弱性にパッチを当てられるという誤解があるが、誰も開発者に、重要でない脆弱性を無意味に掘り下げるよう求めてはいない。
DevSecOps導入の主な障壁として、回答者の31%が「Dev/Opsの透明性の欠如」、29%が「Dev、Ops、セキュリティ間の組織のサイロ化」を挙げていることは注目に値する（図1）。と29%の回答者が「開発、運用、セキュリティ間の組織のサイロ化」を挙げている（図）。これらはいずれも、セキュリティチームと開発チーム間のリスクコミュニケーションの問題や、セキュリティポリシーの迅速なアラートと自動化の必要性を指摘している。
どのような場合でも、脆弱性パッチの優先順位は、パッチを適用する資産のビジネス上の重要性、その資産の重要性、その資産が悪用されるリスク、特に最後のポイントに合わせるべきである。調査によると、全脆弱性の半数以上が公開から1週間以内に悪用されている。

貴社では、ビジネスクリティカルなアプリケーションのセキュリティ評価またはテストを、平均してどのくらいの頻度で実施していますか。

配備済みまたは使用中のアプリケーションに存在する重大なセキュリ ティリスク/脆弱性に対するパッチ適用/対処に要する時間は、平均してどの程度か。

その結果、組織は、共通脆弱性スコアリングシステム（CVSS）スコア、共通脆弱性列挙（CWE）情報、および脆弱性の悪用可能性に基づいて、脆弱性開示の「ゼロ日目」だけでなく、アプリケーションのライフサイクル全体を通じて、脆弱性修正の優先順位を決定する必要があります。
CVSS スコアは、ハザードの深刻度を評価するための業界標準です。国家脆弱性データベース（NVD）の各脆弱性には、脆弱性の深刻度を計算し、脆弱性の改善の優先順位を導くのに役立つ基本スコアがあります。CVSSスコアは、脆弱性の悪用可能性と影響を考慮した包括的な基本スコアです。
タイムスコアは、脆弱性の外部事象による経時変化を考慮した指標である。改善レベル（公式な改善プログラムがあるか）、報告の信頼度（報告が確認されているか？）と報告の信頼度（報告は検証されているか？）は、全体的なCVSSスコアを適切なリスクレベルに調整するのに役立ちます。
CWE 情報は、セキュリティに影響するソフトウェアやハードウェアの不具合をリストアップし、CWE は、どの不具合が悪用可能か（利用可能な脆弱性がある場合）を開発者に伝えます。この情報は、セキュリティチームと開発チームが、開発者のセキュリティトレーニングのどこに重点を置くべきか、SDLC と本番環境でどのような追加的なセキュリティ対策を実装すべきか、そして、リスクの重大度を評価する仕組みを追加すべきかどうかを理解するのに役立ちます。例えば、開発チームは、SQL インジェクション、バッファオーバーフロー、あるいは、サービス拒否に対して、アプリケーショ ンが触れるデータ、配置される場所、および、他の環境とセキュリティ要因によって、異なる優先順位を割り当てるかもしれません。

脆弱性の存在はリスクスコアを高め、作業チームが最もリスクの高い脆弱性の修正に優先順位をつけるのに役立ちます。全体的なリスクを評価した後、パッチ、緩和策、または代替策がすぐに利用可能かどうかを知ることも、考慮すべき重要な情報です。例えば、中リスクだが未使用の脆弱性が2つある場合、どちらを先に修正すべきかは、最終的には既存のパッチやソリューションがあるかどうかによって決まるかもしれない。
デプロイされたアプリケーションにおける重大なセキュリティや脆弱性の問題は、しばしば、図に示すように、組織（あるいは、その顧客）の事業運営に影響を与えるだけでなく、SDLC 全体にも連鎖的な影響を与えます。
開発初期に発見された問題であれば些細なものかもしれませんが、デプロイされたアプリケー ションで発見された場合には、「全員参加」の大きな問題になる可能性があります。IDE や CI パイプラインに統合された自動セキュリティテストツールは、コードがコミットされた直後（あるいは、コミットされる前）に、コードの脆弱性や不具合を特定することができ、開発者は問題が下流に伝播する前に対処することができる。

過去 1 年間（2022～2023 年）において、重大なセキュリ ティ／脆弱性問題の解決は、組織のソフトウ ェア提供計画にどの程度影響を与えましたか （もしあれば）。

効果的なDevSecOpsの課題

図Kに示すように、サイバーセキュリティの人材不足はDevSecOpsにとって大きな課題である。多くの組織は、サイバーセキュリティの重要な役割を担う有能な人材を採用できないでいる。ある調査によると、サイバーセキュリティの欠員は世界中で 350 万人にのぼるという。訓練されたサイバーセキュリティの専門家の市場が拡大するにつれ、供給不足は熟練した実務家の賃金の上昇につながり、多くの政府機関や中小企業（SME）にとって手の届かない存在になるだろう。しかし、図 K が示すように、「開発者/エンジニア向けのセキュリティ研修が不十分である」ことが依然として最大の課題となっている。
セキュリティチャンピオンプログラムの確立は、セキュリティに平均以上の関心や スキルを持つ（そして、その専門知識を活かして開発、品質保証、運用の各チームをサポ ートしている）人材を組織全体から特定することによって、このような問題に対処する効果的な戦 略であることが実証されている。セキュリティチャンピオンは、新規プロジェクトに関するアイデアやフィードバックの提供だけでなく、 セキュリティチームやエンジニアリングチームが、新興技術や急速に変化する技術に不足し ている分野の知識とソフトウェアセキュリティのスキルを組み合わせるのを支援することもできる。アジャイルコーチ、スクラムマスター、DevOps エンジニアは、特にプロセスにおける摩擦を特定し除去するために、セキュリティ支援者の優れた候補者である。

あなたの組織でDevSecOpsを導入する際の課題/障壁は何ですか？(該当するものをすべて選択してください）

本レポートで前述したように、SAST、DAST、IAST、SCAなどのASTツールはいずれも回答者によって広く使用されているが、これらのツールをビジネスニーズに効果的に結びつけることは依然として課題である。
多くのインタビュイーが、使用しているセキュリ ティテストツールでは、セキュリティ脆弱性の露出度、悪用可能性、深刻度などの 要因に基づいて改善作業の優先順位を決定できないこと、迅速なリリースサイクルや継続 的な配備に対応するには時間がかかりすぎること、不正確で信頼性が低いことを不満 に思っている。
さまざまなセキュリティテストの結果を統合したり関連付けたりする方法がないため、セキュリティチームとDevOpsチームは、最初に修正する必要がある脆弱性の特定に多くの時間を費やしている。これは、回答者の約4分の3が、既知の重要な脆弱性のパッチ適用に2週間から1カ月かかると指摘している理由の1つかもしれない。
脆弱性への迅速なパッチ適用の失敗は、基本的な利益に影響する。回答者の80%以上が、配備されたソフトウェアにおける重大な脆弱性や関連するセキュリティ問題への対処が、2022年から2023年にかけての業務スケジュールに影響を及ぼすと回答した。

ガートナーは、ASOC/ASPMが複数のASTツールをオーケストレーションする管理レイヤーとして機能し、検出された問題の相関関係とコンテキスト分析を自動化することで、修復プロセスを迅速化し最適化することができると指摘しています。

ASOC/ASPMは、複数のソースから結果を抽出して統合し、アプリケーション環境全体の統一されたリスクビューを提供します。これにより、ビジネスコンテキスト（深刻度など）に基づいてデータ駆動型の修復作業の優先順位付けを行い、最もリスクの高い脆弱性の迅速な修復を促進することができます。ASOC/ASPMは、本番環境の可視化も提供できるため、配備されたアプリケーションの脆弱性を修正するのに長い時間がかかるという問題に対処し、脆弱性の公開から数日以内に発生することがほとんどであるエクスプロイトを効果的に回避するのに役立ちます。

あなたの組織で使用しているアプリケーションセキュリティテストツールの主な問題点は何ですか。(3つまで選択）

AIの約束と落とし穴

調査結果によると、AIの利用は多くの組織のソフトウェアセキュリティプログラムに浸透しており、回答者の501 TP3T以上が、DevSecOpsの実践においてAIを積極的に利用していると回答している541 TP3Tが、セキュリティ対策の効率と精度を向上させるためにAIに期待している481 TP3Tが、セキュリティテストの手動レビューを削減するためにAIに期待している542 TP3Tが、セキュリティ対策の効率性を向上させるためにAIに期待している543 TP3Tが、セキュリティ対策の効率性を向上させるためにAIに期待している。テストを手作業で実施している。
このことは、AIがDevSecOpsに提供できる可能性のある大きな利点を考えれば納得がいく。 AppSecチームは、完全で一貫性のあるセキュリティテストの必要性と、DevOps手法やCIパイプラインを使用する開発チームと歩調を合わせる必要性との間で、しばしばジレンマに陥っている。納期が厳しいと、開発者は重要なセキュリティリスク評価プロセスをスキップしがちだ。
本調査の回答者は、セキュリティSDLCにAIを導入する主な目的として、「セキュリティ対策の精度と効率の向上」（54%）と「セキュリティデータの手作業によるレビューと分析の必要性の低減」（48%）を挙げている。セキュリティSDLCにAIを導入する主な目的は、以下の2つである。
ただし、インタビューに答えた人々は、AIが「ソフトウェア・セキュリティの複雑さと技術的要件を増大させる」と予想しており、AIが生成したコードを適切に精査できるのはAI自身だけという時代が来るかもしれないとも述べている。

DevSecOpsにAIを導入することは、データ品質の確保やセキュリティとプライバシーの懸念への対応など、さらなる課題をもたらす。AIツールがDevOpsパイプラインにますます統合されるにつれて、それらはほぼ間違いなくセキュリティ脅威の格好の標的になるだろう。AIのトレーニングに使用される機密データの取り扱いも、プライバシーに関する懸念を引き起こす。
例えば、AIによるコーディングは、AIが作成したコードの所有権、著作権、ライセンスの問題を引き起こす可能性がある。
2022年末、GitHub、Microsoft、OpenAIを相手取って、コーディング時に自動補完提案を開発者に提供するクラウドベースのAIツールであるGitHub Copilotが著作権法およびソフトウェアライセンス要件を侵害しており、Copilotのトレーニングに使用されるオープンソースコードが著作権を侵害しているとして集団訴訟が起こされた。Copilotのサービスを訓練するために使用されるオープンソースコードも、開発者の権利を侵害している。この訴訟では、Copilotが提案するコードは、帰属表示、著作権表示、元のライセンス条項の順守なしにライセンスされた素材を使用しているとも主張している。

ChatGPTやGoogle Bardのような大規模な言語モデルに基づく生成AIチャットボットもまた、「錯覚」、つまり信頼でき自信に満ちているように見えて実は間違っている応答、平たく言えば「嘘」をランダムに生成するという問題に悩まされている。「嘘」。
AIの幻覚は明らかにソフトウェアサプライチェーンのセキュリティを脅かす。研究者たちは、ChatGPTが実在しないコードベースやソフトウェアパッケージを示唆する可能性があることを発見した。悪意のある行為者は、同じ名前のパッケージを作成し、悪意のあるコードを埋め込み、AIのアドバイスに従う疑うことを知らない開発者に配布する可能性がある。これはサイバー犯罪者に破壊的な効果をもたらし、スペルミスや偽装など、より伝統的で検知されやすいテクニックを迂回させることができる。実際、研究者たちは、ChatGPTの幻のアドバイスに基づいて作成されたマルウェアパッケージが、PyPIやnpmといった一般的なパッケージマネージャーにすでに存在していることを発見している。
この脅威は机上の空論ではなく、現実に起こっている。サプライチェーンへの攻撃がAIの幻覚に由来するものであれ、悪意のある行為者に由来するものであれ、コードのソースを理解し、開発者や保守者の身元を確認し、信頼できるベンダーやソースからのみパッケージをダウンロードすることが、防御のためには極めて重要である。

教訓

ほとんどの組織がDevSecOpsのプラクティスをある程度は導入しているものの、効果的に実施する上では依然として課題に直面している。調査では、問題は主に2つの分野に集中していることが明らかになった。
- 複数のアプリケーションセキュリティテスト（AST）ツールの結果を統合し、ビジネス上の優先事項と整合させる。
- 重要な脆弱性への対応に要する時間の短縮
回答者の28%が、導入済みアプリケーションの主要なセキュリティリスク／脆弱性のパッチを適用するのに最長3週間かかると回答した。また、20%の回答者が、脆弱性のパッチ適用には最大1カ月かかるが、ほとんどの脆弱性は公開から数日以内に悪用されると回答した。回答者は、ASTツールがビジネスニーズに基づいて脆弱性パッチの優先順位付けを行うことができないことを最も不快に感じていると回答した。
本レポートの冒頭で述べたように、アンケートを作成する際の課題の1つは、「DevSecOps」という用語が多くの異なる分野を包含しており、その多くが独自の役割を持っていることであった。ビジネスの優先順位」という点では、役割によってこの用語に対する理解が異なる可能性がある。
例えば、経営幹部は、AppSec のツールの有効性を知ることに最も関心があり、プロセスの包括的なビューと、それがチーム全体のパフォーマンスをどのように向上させるかを知りたがっている。 開発・運用チームは、AppSec がすべての問題を一元的に把握し、最も価値のあるセキュリティ活動を特定できるようになることを望んでいる。セキュリティ担当者は、ノイズを排除して、重要な問題に優先順位をつけて迅速に対処できるようにしたいと考えている。
アプリケーションセキュリティポスチャ管理（ASPM）は、ビジネスニーズを満たしながら、サイロ化したセキュリティツールを統合するのに苦労している組織に必要な機能強化を提供し、サイロ化したツールを自動的にオーケストレーション、コンテキスト化、優先順位付けして、組織がビジネスにとって最も重要なアプリケーションセキュリティの問題に集中できるようにする。
- ASPMは、開発ツールやセキュリティ・テスト・ツール、運用・保守監視ツールと統合して、組織全体のセキュリティ関連情報を統合した単一のビューを提供することができる。
- ASPM は、特定のアプリケーションと脆弱性を分析するさまざまなツールからのデータを関連付け、グループ化することで、アプリケーションの全体的なセキュリティ態勢に関する包括的なビューを提供することができる。DevSecOps チームは、それぞれの役割と責任に関連するデータを生成することができ、ASPM は、より広範な視点を必要とする事業部門の管理者やその他の人にとって意味のある方法で、このデータを提示することができる。DevSecOps チームは自分の役割と責任に関連するデータを生成でき、ASPM はそのデータを、より広範な視点を必要とするビジネス部門のマネジャーやその他の人々にとって意味のある方法で提示できる。
- ASPM では、特定のアプリケーションや脆弱性に関連する特定のリスクに対処するセキュリティ・ポリシーを策定し、実施することができます。また、ASPM を開発または運用インフラストラクチャと統合することで、セキュリティ問題を早期に特定して解決することができます。
2021年のガートナー・レポートでは、次のように述べている。調査対象組織の約51 TP3Tが、ASPMまたはその前身であるASOC（Application Security Orchestration and Correlation）ツールを採用している。 ガートナー社は、採用率が急速に高まると予測しており、この予測は、調査対象組織の281 TP3TがすでにASOC/ASPMの使用を開始している2023年の調査結果でも裏付けられている。ガートナー社はまた、早期導入者は成熟したDevSecOpsプログラムを持つチームである傾向があり、複数のセキュリティツールを使用していることも指摘している。

回答者の特徴

本レポートで調査したところ、セキュリティツールが提供する断片的な結果、過剰な負担を強いられる作業員、脆弱性修正のペースの遅さが、DevSecOps の成功を妨げる基本的な課題であることが強く示唆された。多様なDevSecOpsチームを擁し、複数のアプリケーションセキュリティテストツールを使用している組織にとって、ASPMは、これらの課題に効果的に対処するための鍵となるかもしれない。

回答者の業種分布