DevSecOps成熟への道のりに立ちはだかる、意外な7つの障壁

Snykは、DevSecOps成熟度フレームワークの策定と発表にあたり、ソフトウェアを中心とする企業における開発者セキュリティの現状について、業界全体を対象とした広範な調査を実施しました。300を超える組織からデータを集め、DevOps、アプリケーションセキュリティ、脆弱性管理、優先順位付け、開発者の導入状況、プログラムガバナンスにおける自組織の成熟度をどのように評価しているかを把握しました。

全体として、成熟したDevSecOpsの実践がもたらす価値を多くの企業が理解し、継続的な改善を目指す最新のセキュリティ文化とAppSecプログラムの構築に積極的に取り組んでいることが、調査結果から明らかになりました。しかし、その取り組み方は一様ではありません。成熟度向上という共通のテーマのもとでも、セキュリティ実践の重要な要素について組織ごとに捉え方が大きく異なり、DevSecOps成熟度という共通の目標に向けて、依然として大きなギャップが存在することがわかりました。改善の可能性を示す調査結果をいくつか見ていきましょう。

リスク低減とセキュリティ疲れは、セキュリティチームが測定する可能性の低いKPIですが、測定したい指標の上位5項目に入っています。

調査対象チームが追跡しているセキュリティ指標のうち、測定される可能性が最も低かったのは「開発者の行動によるリスク低減」と「セキュリティ疲れの軽減（手動トリアージ、ビルドの失敗、セキュリティ対応のやり直しに費やす時間）」の2つでした。しかし、関連データがすべて得られるなら、理想的にはどの指標を測定したいかと同じ回答者に尋ねたところ、この2つは上位に挙がりました。

脆弱性の検出・修正件数、CVSSスコア、修正にかかる時間など、セキュリティツールが容易に報告できるデータと、「特定の種類の対策によってリスクをどれだけ低減できているか」といった、プログラムの有効性やROIを判断するためにセキュリティ担当者が知りたいこととの間には、依然として大きな隔たりがあります。だからこそ、複数のソースから脆弱性データを集約・相関分析し、サイロを解消するとともに、アプリケーション、ビジネス、脆弱性のコンテキストを総合的に捉えてリスクを理解することが重要です。Snyk AppRiskのようなアプリケーションセキュリティポスチャ管理（ASPM）ツールは、リスクベースのセキュリティインサイトを得るための社内ハブ、つまり信頼できる唯一の情報源として役立ちます。

一方、調査対象のすべての職種の中で、ソフトウェア開発者はセキュリティ疲れ、いわゆる toil の測定に最も関心を示していました。この幅広い概念は、シフトレフトによって失われる開発者の生産性というコストを測定しようとするものです。そこには、容易に自動化できないセキュリティ作業に費やされる時間も含まれます。多くの脆弱性スキャンツールはセキュリティ担当者向けに設計されているため、開発者への影響が見過ごされがちです。その結果、SDLCに組み込まれた検出・修正プロセスにどれだけ非効率が生じているかを把握できません。セキュリティ業務の負担を測定できないことは、DevSecOps成熟度の高い組織でさえ、開発チームとセキュリティチームの間に依然として大きな摩擦が見られる一因です。

リスクに基づいてセキュリティポスチャを正確に測定することは、セキュリティチームとエンジニアリングチームに共通する、DevSecOpsの最優先目標です。

アプリケーションセキュリティの分野では、開発者はソフトウェアのリスクを気にかけないという誤解が根強くあります。しかし、開発者がDevSecOpsで最も優先するのは、リスクに基づくセキュリティポスチャを正確に把握することでした。これはAppSecの同僚と同じであり、プラットフォームエンジニアリンググループでも2番目に優先される目標でした。つまり開発者は、組織のリスク低減に貢献したいと考えていますが、優先順位を適切に判断するためのデータが足りないと感じているのです。

この隔たりの根底にあるのは、アプリケーションリスクの算出の複雑さです。単純な問題数や深刻度だけでなく、ビジネスへの影響、到達可能性、悪用の成熟度、補完的な制御の有無などの追加コンテキストが必要です。現代のソフトウェアは非常に複雑で、修正に使える予算は常に限られています。そのため、修正の優先順位は、最も深刻度の高い脆弱性だけを基準に決めるべきではありません。それらが実際に悪用可能とは限らず、悪用された場合も大きなビジネス影響につながるとは限らないからです。SDLC全体から得られる複数のコンテキストに基づく、組織に合わせたリスクベースのスコアリングが必要です。

リスクに基づく優先順位付けの方法を統一できないことは、エンジニアとセキュリティチームの摩擦を生む大きな要因であり、信頼が得られない状態が続けばDevSecOpsの取り組みが失敗する可能性もあります。開発者は、実際にはリスクの低い「誤った」問題に修正時間を費やすよう求められていると感じることが少なくありません。一方、セキュリティ担当者は、両者のワークフローで利用できる、共通かつ信頼できるリスクスコアリングの仕組みがないため、本当に危険なリスクが本番環境に入り込んでいると感じています。リスクの正確な測定が双方にとって最優先事項なのは明らかですが、ほとんどのセキュリティツールは、このニーズへの対応をまだ進めている段階です。

開発者向けのジャストインタイムセキュリティトレーニングへの投資と、開発チーム内でのSecurity Championsプログラムの構築を行っている組織は、わずか50%です。

特にソフトウェア開発者に対するセキュリティ教育は、成熟したDevSecOpsの実践に欠かせません。効果を上げるには、実務に即し、実行に移せる内容で、継続的に行われ、チームのプロセスや働き方に密接に組み込まれている必要があります。しかし、従来型のセキュリティトレーニングの多くはこうした要件を満たせず、開発者がアプリケーションセキュリティリスクや、それに対処するセキュアコーディングの手法を十分に理解できないというギャップが生じています。

このギャップの背景には、エンジニアが実際の問題解決を通じて学ぶことを好むという特性があります。現代のソフトウェア開発手法は非常に複雑で、従来のトップダウン型の方法だけでエンジニアに必要なすべてを教えるのは困難です。開発者は実践を通じて学び、問題に直面すると、先に進むために解決策を見つけます。このような「ジャストインタイム」の学習は、知識の定着率が高いことが実証されています。それでも、多くのセキュリティトレーニングプログラムは逆の、効果の低い方法を取っています。たとえばSnyk Learnのように、開発者が自分のコードで見つかった問題に対処するなど、特定の脆弱性のリスクと修正方法を短いレッスンで学べるジャストインタイムのセキュリティ教育への投資は、セキュリティ成果の向上につながることがわかっています。しかし、調査対象組織のうち、こうした教育を活用しているのは依然として約半数にとどまります。

同様に、ソフトウェアエンジニアリングチームにセキュリティの知識を直接浸透させるSecurity Championsプログラムの有効性も、これまでの調査で一貫して示されています。各チームの開発者1人に、対象を絞った専門的なトレーニングとリソースを提供し、開発者の同僚とAppSec組織をつなぐ役割を担ってもらいます。エンジニアは他のエンジニアから学ぶことを好み、同僚のほうがセキュリティ要件をチームの働き方に合わせて伝えやすいため、Security ChampionsはAppSecとの摩擦を減らし、成果を高めることが示されています。まだChampionsプログラムを導入していない半数の組織は、開発者セキュリティの取り組みに不可欠な文化的基盤を欠くことで、今後も困難に直面する可能性があります。

自社のミッションクリティカルなアプリケーションを正確に特定できると回答した組織は、46%にとどまります。

リスクは一般に、発生可能性と影響度を掛け合わせて算出されます。脆弱性スキャンツールは、悪用の可能性をある程度正確に測定できます（到達可能性や悪用の成熟度などの追加コンテキストが含まれている場合は特にそうです）。しかし、影響度を評価できるのは定義上、ビジネス側だけです。セキュリティスキャナーでは、ミッションクリティカルなアプリケーションにある深刻度の高い問題と、古いプロモーションサイトを支える使われていないサービスにある同じ脆弱性を区別できません。この2つの問題に伴うリスクは、大きく異なる可能性があります。

成熟したDevSecOpsを実現するには、ソフトウェア資産がビジネスに与える影響を組織が理解し、その評価を問題の優先順位付けに使うリスクスコアへ組み込む必要があります。構成管理データベース（CMDB）などのツールは、コードリポジトリ、コンテナイメージ、デプロイメント、その他の成果物の最新インベントリを管理するためによく使われます。また、ビジネス上の重要度を評価するための信頼できる情報源にもなります。この情報をセキュリティオーケストレーションプラットフォーム、特にSnyk AppRiskのようなASPMソリューションに取り込み、リスクベースの優先順位付けアルゴリズムと連携させることができます。

ミッションクリティカルなソフトウェアを特定できずにいる調査対象組織の多くは、二重の問題を抱えています。まず、悪用された場合に大きなビジネス影響をもたらす、重要資産であるアプリケーションに過度のリスクを残したまま、本番環境にリリースしている可能性があります。さらに、影響度が非常に低いアプリケーションの修正優先度を簡単に下げられないため、全体として修正プロセスも非効率になります。成熟したDevSecOpsには、あらゆるリスク算定でビジネスへの影響を最優先の要素として扱えるツールとプロセスが必要です。

本番環境に移行する前に、SDLCの複数の段階でセキュリティ要件を自動的に適用している組織は、わずか31%です。

調査によると、ほとんどの組織ではソフトウェアのリスクプロファイルが完全に文書化され、自動的に適用可能になっています。しかし、最大の割合を占めるグループ（40%）では、適用されるのは本番環境またはランタイム環境だけです。これに対して、より少数の組織は、本番前の環境でSDLCの複数の段階にわたってポリシーを適用しています。重要なのは、DevSecOps文化が成熟した組織であっても、セキュリティ問題を迅速かつ早期に修正するメリットの多くを得られていないという点です。

ソフトウェア開発が左から右へ進むにつれて、問題の修正コストが高くなるというのは、セキュリティ分野で長く知られてきた原則です。セキュリティポリシーの一部しか本番前（CI/CDパイプライン、PRチェック、ステージング環境など）で適用されない場合、多くの問題で最もコストのかかる修正プロセスが必要になります。

修正コストと検出精度の間にはトレードオフがあります。SDLCの早い段階で問題を検出すれば、開発者のワークフローに届くフィードバックループが短くなるため、より迅速かつ効率的に修正できます。一方、ソフトウェアが本番環境に近づき、コンパイル、パッケージ化され、本番環境に近い環境へ段階的にデプロイされてテストされるほど、リスクを把握しやすくなり、セキュリティスキャンの精度も高まります。DevSecOpsを重視するSDLCにおいて、セキュリティテストを実施する「正しい」場所は一つではありません。ソフトウェアへの変更に応じて各段階でポリシーを適用する、軽量なセキュリティチェックポイントを複数設けることで、精度と効率のバランスを最適化できます。単一の段階でしかセキュリティを適用しない組織は、精度か修正効率のどちらかを犠牲にせざるを得ず、DevSecOps成熟度の向上が妨げられます。

セキュリティアラートが適切な関係者だけに送信され、対応に必要なコンテキストがすべて含まれていると回答した組織は、わずか25%です。

アラート疲れは、セキュリティ上の摩擦を生む大きな原因です。通知が多すぎたり、関連性が感じられなかったり、内容の解釈に余計な手間がかかったりすると、簡単に無視されてしまいます。こうした状況が続くと、たとえ今後のアラートがより適切なものになっても、ノイズの多いセキュリティツールへの信頼が失われかねません。そのため、DevSecOpsの成熟に向けてアラート疲れを防ぐことが重要です。

組織の4分の3が、適切に対応できない通知に悩まされています。必要なコンテキストが不足していたり、適切な担当者に届かなかったり、問題解決に向けた明確で信頼できる手順が示されていなかったりするケースが少なくありません。こうしたアラートの混乱は、複数のサイロ化したセキュリティツールが同じ関係者の注意を奪い合うことで生じる場合があります。その結果、対応が必要なレベルの通知に割けるリソースが減ってしまいます。

対応と修復は、SnykのDevSecOps成熟度フレームワークを構成する6つの柱の1つです。ただし、再現性のある対応戦略を実現するには、まず適切な担当者が確実かつ迅速に断固とした行動を起こせるアラートの流れを整える必要があります。アラート疲れを解消できない組織は、時間とともに改善される、信頼性の高い修復ループを実現する能力に限界があることにすぐ気づくでしょう。

DevSecOpsプログラムについて、「エンジニアの視点から見て透明性が高く、セルフサービスで利用でき、安全を確保しやすく、ソフトウェアリスクを持ち込みにくい」と回答した組織は、わずか37%です。 

DevSecOps成熟への道のりで、おそらく最大の隔たりは、開発者の体験を理解することです。当初、「Sec」が加わる前のDevOpsは、中央のITチームの支援が必要だった作業を開発者自身で行えるツールを提供し、開発者の負担を軽減することを目指していました。ソフトウェアのパッケージ化、アプリケーションのデプロイ、インフラの構築といった作業は、コードを書くだけで開発者自身が管理できるようになりました。自動化された再現性のあるプロセスによるセルフサービスへの移行は、現代のソフトウェア開発の礎となり、市場投入までの時間を大幅に短縮しました。

しかし、セキュリティに関しては、同じような進歩が実現していません。「DevSecOps」という考え方が登場してから10年以上が経ちますが、従来型のAppSecツールやプロセスに依存していることが多く、現代のソフトウェア開発者の慣行に合っていません。このミスマッチは、開発者体験を損ないます。エンジニアは自分でコンテナや自動テスト、クラウドサービスを簡単に管理できる一方、セキュリティスキャンが通常の開発フローとは別に実行されるのを待たされることがよくあります。その結果、修復コストが増大し、AppSecチームとの緊張も絶えません。

透明性とセルフサービスが不足していると、開発者がソフトウェアリスクを効果的に管理することは難しくなります。問題を事前に防ぐどころか、安全な選択肢を推測するしかなく、修正コストが最も高くなる段階で対応することになりがちです。つまり、リスクを持ち込むのは簡単なのに、安全を確保するのは難しいのです。真のDevSecOpsを実現するには、この悪循環を断ち切り、「設計段階からセキュア」の原則に移行する必要があります。開発者がセルフサービスでリスクを管理できる道筋を整え、標準の選択肢が安全であると信頼できるようにすることが重要です。

DevSecOpsは登場以来、大きく進化してきました。調査によると、ほとんどの組織が成熟に向けて着実に進んでいますが、信頼できる自動化された開発者中心のセキュリティプラクティスの実現には、まだ大きな伸びしろがあります。

DevSecOpsプログラムをさらに前進させませんか？今すぐ電子書籍をダウンロードしてください。