悪用されやすい脆弱性は、特に Java ベースの ウェブアプリケーションで多く確認されている
Datadog が保有するアプリケーションのデータセットを分析したところ、全サービスの15％に過去に悪用された既知の脆弱性が含まれており、調査対象組織の約30％がこれらの脆弱性の影響を受けていました。特に Java サービスではその割合が高く、全体の44％が、実際に悪用された既知の脆弱性を含んでいました。一方、Go サービスでは同様の脆弱性を含む割合は5％にとどまり、Java 以外のサービス全体の平均は2％程度となっています。
実際、Log4Shell や Spring4Shell などのリモートから任意のコードを実行されるおそれのある脆弱性（RCE）や、継続的に悪用されている攻撃経路など、影響が大きいとされる脆弱性に限定して分析した結果、Javaサービスの14％が、依然として少なくとも1件の脆弱性を含んでいることがわかりました。
さらに、Java アプリケーションは高リスクの脆弱性を含む可能性が高いだけでなく、他のプログラミング言語の開発環境と比べても、パッチの適用が遅れがちであることが明らかになりました。Java ベースの Apache Maven エコシステムに属するアプリケーションでは、ライブラリの脆弱性を修正する中央値が 62 日であるのに対し、.NET ベースの NuGet エコシステムでは 46 日、JavaScript ベースの npm を使用するアプリケーションでは 19 日と、大きな差があります。
インターネットに公開されていることの多いウェブアプリケーションでは、既知の脆弱性を長期間放置することが深刻なリスクにつながる可能性があります。攻撃者は自動スキャナーを使って、影響が大きく悪用しやすい脆弱性を常にインターネット上で探しています。実際、最近の研究では、脆弱性が公開されてからわずか数時間以内に悪用されるケースも珍しくないことが示されています。
Datadogの調査も、こうした攻撃者の行動パターンを裏付けています。調査結果によれば、88% の組織が、/backup.sql など機密情報を含むおそれのあるファイルや、 API エンドポイントを狙った無差別かつ悪意ある HTTP リクエストを受信していました。さらに、特定の URL を悪用しようとした攻撃のうち、65% が無差別スキャンによるものであり、同じ攻撃者が、Datadogが監視する他の組織に対しても同じURLを使って攻撃を試みていたことが明らかになりました。
攻撃者は、特定のアプリケーションを狙うというよりも、インターネット全体を広範にスキャンし、容易に悪用できる脆弱性を探す傾向があります。そのため、依存ライブラリを常に最新のパッチで更新しておくことが不可欠です。既知の脆弱性は、放置すれば重大なリスクにつながります。特にJavaライブラリでは、攻撃コードが公開されているような RCE などの深刻な脆弱性が含まれているケースが多く、加えてパッチの適用が遅れがちであることから、Javaアプリケーションの脆弱性には優先的な対応が求められます。
攻撃者は以前としてソフトウェアサプライチェーン全体を標的にしている
攻撃者は既知の脆弱性をウェブアプリケーションで探すだけでなく、開発者をだまして、オープンソースライブラリの悪意あるパッケージをダウンロード・デプロイさせる手口も頻繁に用いています。2024 年を通じて、Datadog は実環境で数千件の悪意ある PyPI および npm ライブラリを確認しました。これらの中には、たとえば正規の passport ライブラリを装った passports-js のように、正規パッケージの名前を模倣する「タイポスクワッティング」型の悪意あるパッケージも含まれていました。また、 Ultralytics や Solana の web3.js、lottie-player など、人気のある正規の依存ライブラリが積極的に乗っ取られたケースも確認されています。こうした手法は、国家支援の攻撃者だけでなく、一般的なサイバー犯罪者にも使われています。
攻撃者は、開発者にとってサードパーティの依存ライブラリの精査が難しいという状況を巧みに突いてきます。 特に、パッケージのメタデータや機能が正規のもののように見える場合は、内容を十分に検証するのが難しくなり、攻撃者にとっては格好の標的となります。
オープンソースエコシステムで増加し続ける悪意あるパッケージへの対策としては、npm や PyPI で利用可能になったパッケージマネージャーのアテステーション（署名付きのビルド情報などパッケージのビルド元を証明するメタデータ）機能や、メンテナー権限を持つアカウントのセキュリティ強化の普及が期待されます。これにより、正規のパッケージが悪意ある第三者に乗っ取られるリスクが軽減されることが見込まれます。さらに、GuardDog や Supply-Chain Firewall などのオープンソースツールを使えば、パッケージがインストールされる前にソフトウェア内の悪意あるコードを検出することも可能です。
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% から低下しました。
長期認証情報のリスクは多くの組織で認識されているにもかかわらず、半数以上が OIDC などのより安全な認証方式への移行に至っておらず、この問題は依然として重大な技術的負債となっています。
最も深刻と分類される脆弱性の中で本当に対応が必要なものはごく一部に限られる
ライブラリの脆弱性、悪意あるオープンソースパッケージ、アイデンティティの誤設定などが多発しており、防御側にとってはノイズの多い環境が常態化しています。こうした状況では、セキュリティチームは各問題の優先順位を見極め、どれから対応すべきかを判断する必要があります。多くの場合、この判断は、既知の脆弱性に関するメタデータとともに公開されている CVSS基本スコア にもとづいて行われます。CVSS スコアで「高」または「緊急 (最も深刻)」に分類される脆弱性の数は増加傾向にあり、平均的なサービスには こうした脆弱性が13.5 件ありました。(2024 年の 11.9 件から増加)。
しかし、脆弱性の深刻度を正しく評価するには、実行環境の状況を適切に考慮することが不可欠です。たとえば、その脆弱性が含まれるアプリケーションが本番環境で稼働しているかどうか、あるいは脆弱性のあるアプリケーションがインターネットに公開されているかどうかといった要素が重要になります。CVSS はこれらの要素を考慮しないため、防御側にとっては不要なノイズが生じやすくなります。
このノイズを減らすために、Datadog では実行時の状況（ランタイムコンテキスト）を考慮する優先順位付けアルゴリズムを開発しました。この手法を適用した結果、1 アプリケーションあたりの「高」または「緊急」な脆弱性の平均数は、12.2 件から 7.5 件へと減少しました。
この減少は、最も深刻な「緊急」な脆弱性に注目すると、さらに顕著です。つまり、CVSS スコアで緊急と評価された脆弱性のうち、Datadog のアルゴリズムを適用した後も引き続き「緊急」と判定されたものは、全体の 18％にとどまっており、5 件中 1 件未満に相当します。
こうした大幅な削減により、週次・月次・四半期ごとの脆弱性トリアージにかかる時間を大幅に短縮でき、防御者は組織の攻撃対象領域をより迅速に縮小できます。特に、インターネットに公開されているアプリケーションの本番環境に存在し、容易に悪用されやすい脆弱性に優先的に対処することが、セキュリティ体制を効果的に改善する最も現実的な方法です。
“コンテキストが考慮されなければ、脆弱性の深刻度は実際のリスク評価において有効な指標とはなりにくく、過剰なノイズの要因となる可能性があります。セキュリティの本質は、すべての脆弱性にパッチを当てることではなく、本当に対処すべきリスクを正確に見極め、優先順位をつけることにあります。”
Sanofi 社 プリンシパルソフトウェアエンジニア
開発者にとってライブラリを最新に保つことは大きな課題である
Datadog の調査では、依存ライブラリのバージョンが最新のメジャーバージョンより中央値で 215 日遅れていることが明らかになりました。これは、DevSecOps の各機能を担うエンジニアが多忙で、ライブラリの更新が後回しになりがちであることを示しており、ノイズの多い環境での優先順位づけの重要性を裏付けています。古いライブラリは、未修正で悪用可能な脆弱性が含まれていることが多くあります。
依存ライブラリが時代遅れになりがちな傾向は、すべてのエコシステムで共通して見られますが、エコシステムによってその程度には差があります。たとえば、JVM ベースのアプリケーションでは、依存ライブラリのバージョンが最新のメジャーバージョンより中央値で 401 日遅れていたのに対し、Go では 168 日の遅れでした。
デプロイ頻度が平均で月1回に満たないサービスでは、依存ライブラリのバージョンが毎日デプロイされるサービスと比べて約47%古い状態にあります。中央値で見ると、月1回未満のサービスでは最新バージョンから217日遅れ、毎日デプロイされるサービスでは148日遅れでした。
問題をさらに複雑にしているのは、サービスの約半数が、すでに積極的な保守が行われていないライブラリを使用していることです。このようなライブラリは更新が止まっているため、新たな脆弱性が発見されてもパッチが適用されず、リスクが残り続けるという課題があります。
脆弱性への露出を低減するには、古いライブラリを継続的かつ計画的に特定・更新する取り組みが不可欠です。特に、メンテナンスが終了しているライブラリは、サポートが終了した OS と同様に扱い、速やかにアクティブに保守されているバージョンへ置き換えることが望まれます。また、サービスを頻繁にデプロイすることも重要です。これは運用上のベストプラクティスであるだけでなく、各デプロイのタイミングで依存ライブラリを更新できる機会が生まれ、セキュリティ体制の維持にもつながります。
コンテナ イメージを軽量化してセキュリティ体制を強化する
近年、エンジニアリングチームは、システムの効率化とコスト最適化を目的に、軽量なコンテナイメージの採用を進めています。こうした動きは、 Alpine Linux のような軽量なディストリビューションから始まり、さらに小型のdistroless や from-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（公開脆弱性情報）の件数を減らすだけでなく、コンプライアンス対応の迅速化にも貢献しています。”
Chainguard 社 プリンシパルプロダクトマネージャー、プロダクトセキュリティ担当
AWS では IaC の利用が進む一方で、ClickOps も依然として使われている
Infrastructure as Code (IaC) は、バージョン管理やトレーサビリティの向上など、運用面でのメリットをもたらすことから、クラウド環境における標準的な運用手法として広く採用されています。また、IaC はセキュリティにおける推奨される対策の一つでもあり、他の開発者によるコードの事前確認 (ピアレビュー) を促進し、設定ミスの自動スキャンを容易にする効果があります。
IaCの普及は引き続き進んでおり、AWS を利用する組織のうち 59% が Terraform を、57% が CloudFormation を利用しています（いずれも 2024 年から緩やかに増加）。全体としては、80% の組織が何らかの IaC ツールを活用していることがわかります。
同時に、少なくとも 38% の組織が、本番環境に対して ClickOps によるデプロイを行っていることも明らかになりました。これは、担当者が AWS に手動でログインし、管理画面上でシステムの設定や構成を行っていることを意味します。ClickOps は、人為的なミスが発生しやすくなるだけでなく結果としてクラウド環境に管理者権限を持つユーザーが増えやすいため、一般的に IaC よりもセキュリティ上のリスクが高いとされています。
さらに調査の結果、IaC を導入している組織であっても、ClickOps を完全に排除できているとは限らず、両方を併用しているケースが確認されました。これは、運用やセキュリティの観点から不可欠とされる IaC だけでは十分とは言えず、本番環境への手動アクセスが依然として残っている実態を示しています。そのため、IaC を徹底し、高い操作権限 (特権アクセス) を最小限に抑えるとともに、クラウドリソースを継続的にスキャンして脆弱性を把握する取り組みが、引き続き極めて重要です。