正井氏は「DevSecOpsとは、開発、運用、セキュリティを一体化し、セキュリティを最初から組み込み継続的に改善していく、文化的／構造的な改革」だと定義。かつて一般的だった「ソフトウェアが完成してからセキュリティ対策を後付けする」という方法では、現在の高度化したサイバー攻撃には対応が困難であると指摘し、その一方で「DevSecOpsは単なる技術導入の話ではなく、企業文化そのものを変革する取り組みだ」と強調した。

　調査を主導したDatadogのアンドリュー・クルーグ氏（Head of Security Advocacy）は、今回のレポートについて、同社製品のユーザー企業が運用する「数千ものクラウド環境で稼働する数万のアプリケーションおよびコンテナイメージを分析」した結果だとした上で、分析の結果得られた知見として次の4点を紹介した。

• 国家支援型の攻撃者と一般的なサイバー攻撃者の双方が、ソフトウェアサプライチェーンを標的にしている
• 実行時の状況を踏まえた分析では、緊急度が最も高い脆弱（ぜいじゃく）性のうち優先すべきものは5件中1件にも満たない（18％）
• 全ての言語で依存ライブラリは最新のメジャーバージョンから数ヶ月遅れている
• デプロイ頻度の低いサービスは、古い依存ライブラリを抱えている傾向がある

　最も興味深いポイントは、一般的に緊急度が高いとされる脆弱性でも、ユーザーの実際の実行環境においてはさほどリスクが高くない例が多いという指摘だ。セキュリティ担当者の負担軽減のためにも実態に即した警告を発することが重要だ。クルーグ氏は、標準的な脆弱性のリスク情報として「CVSS」（Common Vulnerability Scoring System）と「EPSS」（Exploit Prediction Scoring System）の2種類（注）が使われていることを紹介した上で、「ランタイムコンテキストの評価を加えることで、急いで対応すべき脆弱性の数を大幅に削減することができる」と語る。ランタイムコンテキストとは、脆弱性を含むソフトウェアが実行されている環境に関する広範な情報のことを意味する。

※注：「CVSS」は脆弱性の深刻度を評価するための指標で、0.0から10.0の範囲で数値が大きいほど深刻度が高いことを示す。「EPSS」は脆弱性が今後30日以内に実際に悪用される可能性を予測するスコアリングシステムで、30日以内に実際に悪用される確率を0～100％で数値化する。

　CVSSスコアは、「任意のコードを実行される可能性があるかどうか」といった技術的な危険性など、脆弱性そのものの深刻度を評価したものだ。脆弱性そのものは深刻であっても、実際の危険度はシステムごとの運用環境によって異なる。例えば、任意のコードを実行する難易度がどのくらいかによって実際に悪用される可能性は変わるし、脆弱性のあるシステムが外部ネットワークと隔離されている場合にはリスクは相対的に低くなる。

脆弱性の深刻度は稼働環境によって異なる（出典：Datadog Japan資料）《クリックで拡大》

「運用環境に即した脆弱性評価」が鍵に

　Datadogのオブザーバビリティ製品を活用すれば、どのソフトウェアモジュールがどこで稼働しているか、セキュリティパッチの適用状況はどうか、といった実際の運用環境に関する情報を収集できる。CVSSの情報だけでは、その脆弱性を含むソフトウェアがどのような状況で運用されているかまでは分からないが、オブザーバビリティ製品と組み合わせることで、稼働環境に関する情報と組み合わせて評価することが可能になる。また同社はアラートのノイズを削減するために、「Security Inbox」と「Datadog Severity Scoring」の2つの機能を提供しており、これらの機能を使えばリアルタイムの運用状況を活用して不要なアラートを削減することができる」という。

　Datadog Severity Scoringでは、「CVSS基本スコアに、『悪用されやすいか』『外部からアクセスできるか』『狙われやすいか』などの重要な環境条件を重ね合わせて評価を調整」している。環境状況を踏まえて個別具体的な判断が可能な点は、膨大な環境情報を収集し、それらを組み合わせて総合的な判断を行えるオブザーバビリティ製品ならではのメリットと言え、こうした情報をセキュリティに活用できる点が同社のセキュリティ機能の強みとなっている。

　なお、クルーグ氏は最後にDevSecOpsを定着させるためのポイントとして以下の3点を推奨した。

• DevSecOpsは社内文化の改革から始まる
• KPIで「見える化」し、小さく始める
• 継続的な改善と学びの文化を育てる