State of DevSecOps | Datadog
State of DevSecOps

/ / /

2025 年 4 月更新

この調査は、2024 年 4 月に公開した前回の記事を基にしています。各項目のグラフは、こちらからダウンロードできます。

DevSecOps は、ソフトウェア開発ライフサイクル (SDLC) の各段階に潜むセキュリティリスクを特定し、早期に対策を講じることを重視する考え方です。現在ではIT業界における標準的なアプローチとして広く受け入れられつつあります。組織が把握すべきリスクの種類や、セキュリティ体制を強化するための具体的な対策を明らかにするため、Datadogでは数千のクラウド環境における数万のアプリケーションおよびコンテナイメージを分析しました

その結果、Webアプリケーションは既知の脆弱性を悪用する攻撃、ソフトウェアサプライチェーン攻撃、CI/CD(継続的インテグレーション/継続的デリバリー)におけるアクセス制御の設定ミスなど、さまざまなリスクにさらされていることが明らかになりました。こうしたリスクに適切に対処するためには、アプリケーションが使用している言語や実行環境を踏まえ、誤検知や関連性の低いアラートを除外することが重要です。そうすることで、実際に対応すべきリスクに優先順位を付けやすくなります。その上で、コンテナイメージの軽量化、IaC (コードによるインフラ構成管理)の活用、サービスの頻繁なデプロイといった運用上のベストプラクティスを取り入れることで、セキュリティリスクにさらされる機会を減らすことがで可能です。こうした取り組みを通じて、SDLC 全体のセキュリティ基盤を強化することができます。


事実 1

悪用されやすい脆弱性は、特に Java ベースの ウェブアプリケーションで多く確認されている

Datadog が保有するアプリケーションのデータセットを分析したところ、全サービスの15%に過去に悪用された既知の脆弱性が含まれており、調査対象組織の約30%がこれらの脆弱性の影響を受けていました。特に Java サービスではその割合が高く、全体の44%が、実際に悪用された既知の脆弱性を含んでいました。一方、Go サービスでは同様の脆弱性を含む割合は5%にとどまり、Java 以外のサービス全体の平均は2%程度となっています。

Javaアプリケーションの約半数が過去に悪用された脆弱性を抱えています

実際、Log4Shell や Spring4Shell などのリモートから任意のコードを実行されるおそれのある脆弱性(RCE)や、継続的に悪用されている攻撃経路など、影響が大きいとされる脆弱性に限定して分析した結果、Javaサービスの14%が、依然として少なくとも1件の脆弱性を含んでいることがわかりました。

さらに、Java アプリケーションは高リスクの脆弱性を含む可能性が高いだけでなく、他のプログラミング言語の開発環境と比べても、パッチの適用が遅れがちであることが明らかになりました。Java ベースの Apache Maven エコシステムに属するアプリケーションでは、ライブラリの脆弱性を修正する中央値が 62 日であるのに対し、.NET ベースの NuGet エコシステムでは 46 日、JavaScript ベースの npm を使用するアプリケーションでは 19 日と、大きな差があります。

Mavenを使用するJava環境では脆弱性の修正に最も時間がかかります

インターネットに公開されていることの多いウェブアプリケーションでは、既知の脆弱性を長期間放置することが深刻なリスクにつながる可能性があります。攻撃者は自動スキャナーを使って、影響が大きく悪用しやすい脆弱性を常にインターネット上で探しています。実際、最近の研究では、脆弱性が公開されてからわずか数時間以内に悪用されるケースも珍しくないことが示されています。

Datadogの調査も、こうした攻撃者の行動パターンを裏付けています。調査結果によれば、88% の組織が、/backup.sql など機密情報を含むおそれのあるファイルや、 API エンドポイントを狙った無差別かつ悪意ある HTTP リクエストを受信していました。さらに、特定の URL を悪用しようとした攻撃のうち、65% が無差別スキャンによるものであり、同じ攻撃者が、Datadogが監視する他の組織に対しても同じURLを使って攻撃を試みていたことが明らかになりました。

攻撃者は、特定のアプリケーションを狙うというよりも、インターネット全体を広範にスキャンし、容易に悪用できる脆弱性を探す傾向があります。そのため、依存ライブラリを常に最新のパッチで更新しておくことが不可欠です。既知の脆弱性は、放置すれば重大なリスクにつながります。特にJavaライブラリでは、攻撃コードが公開されているような RCE などの深刻な脆弱性が含まれているケースが多く、加えてパッチの適用が遅れがちであることから、Javaアプリケーションの脆弱性には優先的な対応が求められます。

事実 2

攻撃者は以前としてソフトウェアサプライチェーン全体を標的にしている

攻撃者は既知の脆弱性をウェブアプリケーションで探すだけでなく、開発者をだまして、オープンソースライブラリの悪意あるパッケージをダウンロード・デプロイさせる手口も頻繁に用いています。2024 年を通じて、Datadog は実環境で数千件の悪意ある PyPI および npm ライブラリを確認しました。これらの中には、たとえば正規の passport ライブラリを装った passports-js のように、正規パッケージの名前を模倣する「タイポスクワッティング」型の悪意あるパッケージも含まれていました。また、 Ultralytics や Solana の web3.jslottie-player など、人気のある正規の依存ライブラリが積極的に乗っ取られたケースも確認されています。こうした手法は、国家支援の攻撃者だけでなく、一般的なサイバー犯罪者にも使われています。

国家支援型の攻撃者と一般的なサイバー攻撃者の双方が、ソフトウェアサプライチェーンを標的にしています

攻撃者は、開発者にとってサードパーティの依存ライブラリの精査が難しいという状況を巧みに突いてきます。 特に、パッケージのメタデータや機能が正規のもののように見える場合は、内容を十分に検証するのが難しくなり、攻撃者にとっては格好の標的となります。

オープンソースエコシステムで増加し続ける悪意あるパッケージへの対策としては、npmPyPI で利用可能になったパッケージマネージャーのアテステーション(署名付きのビルド情報などパッケージのビルド元を証明するメタデータ)機能や、メンテナー権限を持つアカウントのセキュリティ強化の普及が期待されます。これにより、正規のパッケージが悪意ある第三者に乗っ取られるリスクが軽減されることが見込まれます。さらに、GuardDogSupply-Chain Firewall などのオープンソースツールを使えば、パッケージがインストールされる前にソフトウェア内の悪意あるコードを検出することも可能です。

事実 3

CI/CD パイプラインでは、有効期限の長い認証情報の使用が依然として多いが、徐々に減少傾向にある

脆弱なコードや悪意あるオープンソースパッケージに加えて、有効期限が設定されていない長期有効な認証情報の使用は、クラウド環境におけるデータ漏えいの主要な原因の一つとなっており、現在広く問題視されています。長期認証情報には管理者レベルの権限が割り当てられている場合が多く、特にそれらがCI/CDパイプラインで使用されるとリスクが高まります。

長期利用の認証情報が CI/CD に混入しやすい典型的なシナリオの一つが、組織が GitHub Actions を使って AWS にアプリケーションをデプロイするケースです。GitHub Actions は、OpenID Connect (OIDC:認証プロトコル) を通じて発行される短期認証情報、または AWS IAM ユーザーの長期アクセスキーを使用するように設定できます。Datadog に CloudTrail ログを送信しているお客様のうち 37% が、GitHub Actions で IAM ユーザーを使用していることがわかりました。このような構成では、長期認証情報に依存するリスクが高まるため、Datadog では OIDC の使用を強く推奨しています。

AWS と GitHub Actions を併用している組織のうち、2025 年時点で 63% が OIDC を活用しており、2024 年の 58% から増加しています。一方、IAM ユーザーから発行される長期認証情報を使用している組織は 58% に減少し、2024 年の 63% から低下しました。

改善傾向はあるものの、AWSを利用する多くの組織では依然としてGitHub Actionsで長期有効な認証情報を使用しています

長期認証情報のリスクは多くの組織で認識されているにもかかわらず、半数以上が OIDC などのより安全な認証方式への移行に至っておらず、この問題は依然として重大な技術的負債となっています。

事実 4

最も深刻と分類される脆弱性の中で本当に対応が必要なものはごく一部に限られる

ライブラリの脆弱性、悪意あるオープンソースパッケージ、アイデンティティの誤設定などが多発しており、防御側にとってはノイズの多い環境が常態化しています。こうした状況では、セキュリティチームは各問題の優先順位を見極め、どれから対応すべきかを判断する必要があります。多くの場合、この判断は、既知の脆弱性に関するメタデータとともに公開されている CVSS基本スコア にもとづいて行われます。CVSS スコアで「高」または「緊急 (最も深刻)」に分類される脆弱性の数は増加傾向にあり、平均的なサービスには こうした脆弱性が13.5 件ありました。(2024 年の 11.9 件から増加)。

しかし、脆弱性の深刻度を正しく評価するには、実行環境の状況を適切に考慮することが不可欠です。たとえば、その脆弱性が含まれるアプリケーションが本番環境で稼働しているかどうか、あるいは脆弱性のあるアプリケーションがインターネットに公開されているかどうかといった要素が重要になります。CVSS はこれらの要素を考慮しないため、防御側にとっては不要なノイズが生じやすくなります。

このノイズを減らすために、Datadog では実行時の状況(ランタイムコンテキスト)を考慮する優先順位付けアルゴリズムを開発しました。この手法を適用した結果、1 アプリケーションあたりの「高」または「緊急」な脆弱性の平均数は、12.2 件から 7.5 件へと減少しました。

この減少は、最も深刻な「緊急」な脆弱性に注目すると、さらに顕著です。つまり、CVSS スコアで緊急と評価された脆弱性のうち、Datadog のアルゴリズムを適用した後も引き続き「緊急」と判定されたものは、全体の 18%にとどまっており、5 件中 1 件未満に相当します。

実行時の状況をふまえた分析では、緊急度が最も高い脆弱性のうち優先すべきものは5件中1件にも満たないことが明らかになっています

こうした大幅な削減により、週次・月次・四半期ごとの脆弱性トリアージにかかる時間を大幅に短縮でき、防御者は組織の攻撃対象領域をより迅速に縮小できます。特に、インターネットに公開されているアプリケーションの本番環境に存在し、容易に悪用されやすい脆弱性に優先的に対処することが、セキュリティ体制を効果的に改善する最も現実的な方法です。

“コンテキストが考慮されなければ、脆弱性の深刻度は実際のリスク評価において有効な指標とはなりにくく、過剰なノイズの要因となる可能性があります。セキュリティの本質は、すべての脆弱性にパッチを当てることではなく、本当に対処すべきリスクを正確に見極め、優先順位をつけることにあります。”

Jean Burellier
Sanofi 社 プリンシパルソフトウェアエンジニア
事実 5

開発者にとってライブラリを最新に保つことは大きな課題である

Datadog の調査では、依存ライブラリのバージョンが最新のメジャーバージョンより中央値で 215 日遅れていることが明らかになりました。これは、DevSecOps の各機能を担うエンジニアが多忙で、ライブラリの更新が後回しになりがちであることを示しており、ノイズの多い環境での優先順位づけの重要性を裏付けています。古いライブラリは、未修正で悪用可能な脆弱性が含まれていることが多くあります。

依存ライブラリが時代遅れになりがちな傾向は、すべてのエコシステムで共通して見られますが、エコシステムによってその程度には差があります。たとえば、JVM ベースのアプリケーションでは、依存ライブラリのバージョンが最新のメジャーバージョンより中央値で 401 日遅れていたのに対し、Go では 168 日の遅れでした。

すべての言語において、依存ライブラリは最新のメジャーバージョンから数か月遅れている傾向があります

デプロイ頻度が平均で月1回に満たないサービスでは、依存ライブラリのバージョンが毎日デプロイされるサービスと比べて約47%古い状態にあります。中央値で見ると、月1回未満のサービスでは最新バージョンから217日遅れ、毎日デプロイされるサービスでは148日遅れでした。

デプロイ頻度が低いサービスほど、依存ライブラリのバージョンが古くなりやすい傾向があります

問題をさらに複雑にしているのは、サービスの約半数が、すでに積極的な保守が行われていないライブラリを使用していることです。このようなライブラリは更新が止まっているため、新たな脆弱性が発見されてもパッチが適用されず、リスクが残り続けるという課題があります。

脆弱性への露出を低減するには、古いライブラリを継続的かつ計画的に特定・更新する取り組みが不可欠です。特に、メンテナンスが終了しているライブラリは、サポートが終了した OS と同様に扱い、速やかにアクティブに保守されているバージョンへ置き換えることが望まれます。また、サービスを頻繁にデプロイすることも重要です。これは運用上のベストプラクティスであるだけでなく、各デプロイのタイミングで依存ライブラリを更新できる機会が生まれ、セキュリティ体制の維持にもつながります。

事実 6

コンテナ イメージを軽量化してセキュリティ体制を強化する

近年、エンジニアリングチームは、システムの効率化とコスト最適化を目的に、軽量なコンテナイメージの採用を進めています。こうした動きは、 Alpine Linux のような軽量なディストリビューションから始まり、さらに小型のdistrolessfrom-scratch イメージへと進化してきました。これらはいずれも、不要なコンポーネントを削除することで、コンテナイメージのサイズを大幅に削減することを目的としています。たとえば、python:3.11 の標準 Docker イメージは 1 GB 超える一方で、python:3.11-alpine は 58MB に収まり、サイズは 95% 削減されています。

この「Less is more(少ない方が優れている)」という考え方は、セキュリティの面でも有効です。Datadog では数千のコンテナイメージを分析し、100MB 未満のイメージでは、深刻な脆弱性(CVSS スコアが高または緊急)の平均件数は 3 件(中央値 0)であるのに対し、500MB を超えるイメージでは平均 20 件(中央値 7 件)にのぼることがわかりました

コンテナイメージが軽量なほど脆弱性は少ない傾向にあります

軽量なコンテナイメージには、もともと含まれる脆弱性が少ないだけでなく、curl や wget などのシステムユーティリティが含まれていないことが多いため、攻撃者がいわゆる“live off the land”(標準ツールを悪用する)手法を使って攻撃を実行することが難しくなります(こうした攻撃手法は非常に一般的です)。 軽量なコンテナイメージを可能な限り採用することは、運用面のベストプラクティスであると同時に、セキュリティ対策としても非常に有効であることが、あらためて示されています。

“イメージが軽量なほどパッチ対象が減り、攻撃者にとって悪用可能な箇所も少なくなります。コンポーネントを多く含めるほど、攻撃対象領域(アタックサーフェス)は広がってしまいます。Distrolessアプローチでは、不要なパッケージやユーティリティをすべて取り除き、目的に必要なものだけを残すことで、脆弱性を最小限に抑え、攻撃者が利用できる侵入経路を大幅に削減できます。私たちの経験では、セキュリティを強化した軽量なイメージは、CVE(公開脆弱性情報)の件数を減らすだけでなく、コンプライアンス対応の迅速化にも貢献しています。”

Amber Bennoui
Chainguard 社 プリンシパルプロダクトマネージャー、プロダクトセキュリティ担当
事実 7

AWS では IaC の利用が進む一方で、ClickOps も依然として使われている

Infrastructure as Code (IaC) は、バージョン管理やトレーサビリティの向上など、運用面でのメリットをもたらすことから、クラウド環境における標準的な運用手法として広く採用されています。また、IaC はセキュリティにおける推奨される対策の一つでもあり、他の開発者によるコードの事前確認 (ピアレビュー) を促進し、設定ミスの自動スキャンを容易にする効果があります。

IaCの普及は引き続き進んでおり、AWS を利用する組織のうち 59% が Terraform を、57% が CloudFormation を利用しています(いずれも 2024 年から緩やかに増加)。全体としては、80% の組織が何らかの IaC ツールを活用していることがわかります。

AWS では、Terraform と CloudFormation が事実上の標準ツールとして広く使われています。

同時に、少なくとも 38% の組織が、本番環境に対して ClickOps によるデプロイを行っていることも明らかになりました。これは、担当者が AWS に手動でログインし、管理画面上でシステムの設定や構成を行っていることを意味します。ClickOps は、人為的なミスが発生しやすくなるだけでなく結果としてクラウド環境に管理者権限を持つユーザーが増えやすいため、一般的に IaC よりもセキュリティ上のリスクが高いとされています。

さらに調査の結果、IaC を導入している組織であっても、ClickOps を完全に排除できているとは限らず、両方を併用しているケースが確認されました。これは、運用やセキュリティの観点から不可欠とされる IaC だけでは十分とは言えず、本番環境への手動アクセスが依然として残っている実態を示しています。そのため、IaC を徹底し、高い操作権限 (特権アクセス) を最小限に抑えるとともに、クラウドリソースを継続的にスキャンして脆弱性を把握する取り組みが、引き続き極めて重要です。

Datadog のセキュリティに関する最新のリサーチ、イベント情報、アップデートを継続的に受け取りたい方は、ぜひご登録ください。

Datadog Security Digest に登録する

方法論

第1の事実

この事実を明らかにするため、Datadog Code Security の Software Composition Analysis 機能を活用し、Java、.NET、PHP、Python、Ruby、JavaScript、Go の各言語・ランタイムで動作するアプリケーションに含まれるサードパーティライブラリの脆弱性を分析しました。実際に攻撃に利用された脆弱性については、2025 年 4 月 9 日時点の CISA KEV カタログを参照しました。

パッチ適用までの期間については、各エコシステムで組織が該当の脆弱性を修正するまでの所要時間を計測して算出しました。

「untargeted (無差別)」とは、同一の攻撃者 (送信元 IP アドレスで特定) が同じ HTTP リクエストを Datadog をご利用の 複数のお客様に送信したケースを指します。

第2の事実

この事実を明らかにするため、Datadog のセキュリティリサーチチームが行った調査と分析を活用しました。同チームは GuardDog などのツールを活用し、2024 年版のレポート公開以降、複数のソフトウェア エコシステムにわたって悪意あるパッケージの特定と分類を行ってきました。

第3の事実

GitHub Actions では、OIDC による認証方式が利用されています。GitHub Actions で OIDC 認証を使用している組織を特定するために、以下の Datadog Logs クエリを使って AWS CloudTrail ログを調査しました。

  @eventName:AssumeRoleWithWebIdentity
  @userIdentity.identityProvider:*token.actions.githubusercontent.com* -status:error

また、GitHub Actions が IAM ユーザーの認証情報を使って AWS にアクセスしている可能性のある組織を特定するために、同様に以下のクエリを使用して AWS CloudTrail ログを調査しました。 @userIdentity.accessKeyId:AKIA* @userIdentity.type:IAMUser -status:error さらに、GitHub Actions の実行環境からのアクセスであることを確認するために、CloudTrail に記録されたソース IP アドレスを、GitHub の API エンドポイント で公開されている IP アドレスと照合し、該当する結果のみをフィルタリングしました。

第4の事実

Datadog Code Security の Software Composition Analysis (SCA) 機能を用いて、アプリケーションが利用するサードパーティライブラリに含まれる脆弱性を分析しました。

対象としたのは、CVSS v3 の基本スコアで「緊急」と判定された脆弱性です。当時入手可能だった環境情報やリスク要素に基づいて、以下の調査方法により「時間(Temporal)」および「環境(Environmental)」メトリクス(CVSS v3)の補正を以下の方針で行いました。 サービスが本番環境以外で稼働していた場合は、「修正後の機密性・完全性・可用性への影響(Modified CIA Impact)」を「Low(低)」に設定しました。

  • サービスがインターネットに公開されておらず、攻撃元ベクター(Attack Vector)が「Network(ネットワーク)」とされていた場合は、「Local(ローカル)」に補正しました。
  • EPSS スコア が 1% 未満であった場合は、「攻撃の複雑さ(Attack Complexity)」を「High(高)」に設定しました。
  • 公開された攻撃コード(エクスプロイト コード)が存在する場合は、「エクスプロイトコード成熟度(Exploit Code Maturity)」を「Proof of Concept(概念実証)」に、存在しない場合は「Unproven(未確認)」に設定しました。

こうした補正を踏まえ、CVSS v3.1 の方法論に基づいてスコアを再計算し、補正後も依然として「緊急」と評価された脆弱性の割合を算出しました。

第5の事実

この事実を明らかにするため、2025年3月時点でアクティブだったライブラリのデータを収集しました。各依存関係については、ライブラリの現行メジャーバージョンが最後に更新されてからの日数を算出し、エコシステム(例:JVM、Go)ごとの中央値を求めました。また、デプロイ頻度別の比較も行いました。

分析対象は、SemVer (Semantic Versioning) を採用しているライブラリに限定し、一般公開されているライブラリは除外しました。

デプロイ頻度については、過去 6 か月間の datadog.service.time_between_deployments メトリクスから取得したデータを使用しました。過去6か月間に100回以上デプロイされたサービスは、6か月にはおよそ100営業日あることから「日次デプロイ」に分類し、26回以上は「週次デプロイ」、6回以上は「月次デプロイ」、6回未満の場合は「平均して月1回未満のデプロイ」としました。

第6の事実

Datadog Cloud Security の Vulnerability Management 機能でスキャンされたコンテナのデータを分析し、検出された OS レベルの脆弱性を精査しました。分析対象には、公開イメージと、少なくとも 1 件の脆弱性を含むプライベートレジストリのイメージの両方が含まれます。なお、Datadog のコンテナイメージは除外しています。

第7の事実

この事実を明らかにするために、AWS CloudTrail ログを分析し、HTTP ユーザーエージェントに基づいて使用されている IaC 技術を特定しました。

注: この分析のデータ期間は 2025 年 3 月です。期間中に既知の IaC 技術を使用していなかった組織は、「IaC を使用していない」とみなしました。

ClickOps (手動によるクラウド操作) を使用している組織数を特定するためにも、同様に、AWS CloudTrail ログを分析しました。具体的には、Datadog でモニタリングしている AWS アカウント内で以下のいずれかのイベントが確認された場合、その組織は「AWS コンソールを使用して手動でクラウド環境の構築・変更(デプロイ)を実施している」と定義しています。Datadog は、各組織が少なくとも 1 つの本番アカウントを監視していると想定しており、これらの基準を満たす組織は「本番環境で ClickOps を使用している」と判断しました。

RunInstances
AuthorizeSecurityGroupIngress
CreateVpc
CreateCluster
CreateDBCluster
CreateDBInstance
CreateInstances
CreateKeyPair
RegisterTaskDefinition

その後、Arkadiy Tetelman が説明した手法を用いて、これらのイベントが AWS コンソールから手動で実行されたかどうかを特定しました。

ライセンス

Licensing Report: CC BY-ND 4.0

Images: CC BY-ND 4.0