Rory McCune
Seth Art
Christina DePinto
このたび、Datadogでは「2025年版 DevSecOps 調査レポート を公開しました。このレポートでは、数千におよぶクラウド環境で稼働する数万のアプリケーションおよびコンテナイメージを解析し、ソフトウェア開発ライフサイクル（SDLC）の各段階におけるセキュリティ体制の傾向とベストプラクティスを明らかにしています。特に、次のような傾向が明らかになりました。
- 悪用されやすい脆弱性は、特に Java ベースの ウェブアプリケーションで多く確認されている
- 攻撃者は以前としてソフトウェアサプライチェーン全体を標的にしている
- CI/CD パイプラインでは、有効期限の長い認証情報の使用が依然として多いが、徐々に減少傾向にある
- 緊急とされる脆弱性のうち、本当に優先すべきものはごく一部に限られる
- 開発者にとってライブラリを最新に保つことは大きな課題である
- コンテナ イメージを軽量化してセキュリティ体制を強化する
- AWS では IaC (インフラをコードで管理) の利用が進む一方で、ClickOps (手動操作) も依然として使われている
本記事では、これらの調査結果を踏まえて、組織として取り入れるべきいくつかのベストプラクティスをご紹介します。 具体的には以下のような取り組みを含みます。
- 稼働状況を考慮して脆弱性に優先順位をつける
- ソフトウェアサプライチェーンに自動的に安全性を確保する仕組みを導入する
- 最新のパッチを適用した状態を保つため頻繁にデプロイを行う
- 軽量なコンテナイメージを取り入れる
- IaCの使用を拡大し、ClickOpsへの依存を減らす
さらに、Datadogのプラットフォーム上で提供するDatadog Code Security、Cloud Security、Cloud SIEM、Workload Protectionなど活用して、セキュリティ体制を強化し、脅威から組織を守る方法を解説します。
稼働状況を考慮して脆弱性に優先順位をつける
多くのセキュリティチームの人員や予算には限りがあるため、すべての脆弱性を一度に修正することは困難です。そのため、優先順位を正しく見極めることが極めて重要です。幸い、すべての脆弱性が等しく緊急というわけではありません。CVSS（共通脆弱性評価システム）の基本スコアは、優先順位を判断するうえで有用な指標のひとつですが、そのスコアは「外部公開されているかどうか」や「既知のエクスプロイト（脆弱性を悪用する攻撃）が存在するか」といった実環境の条件を考慮していません。こうしたコンテキスト情報を数千件の脆弱性それぞれに対して手作業で適用することは、ほとんどのチームにとって膨大な時間と労力を要する作業であり、現実的に対応するのは困難です。
しかし、クラウド資産の環境情報を各リソースに関連付けられた脆弱性と照らし合わせることで、実行時の状況（ランタイムコンテキスト）を踏まえた優先順位付けが可能になります。つまり、悪用される可能性が高い脆弱性から効率的に対処することができるのです。脆弱性の深刻さを見直す際に考慮すべき主な特性は以下のとおりです。
- 外部公開の有無: システムがインターネットに接続している場合、脆弱性が発見・悪用されやすいため、優先的な対応が必要です。一方、非公開システムにおける脆弱性も無視できません。ひとたび攻撃者が内部環境に侵入した場合、こうした脆弱性が悪用される可能性があります。しかし、対応の優先順位という観点では、まずは外部に公開されているシステムに影響を与える脆弱性に注力することが重要です。
- 稼働環境 : 本番環境は、最も機密性の高いデータや実際のユーザーセッションを扱っているため、脆弱性が悪用された場合、サービス停止や情報漏えい、さらに他の本番サービスへの波及的な被害につながる可能性が高く、優先的な対応が求められます。一方、開発環境やステージング環境に存在する脆弱性は、通常、本番環境に比べてリスクや深刻度が低いと考えられます。
- 現在進行中の攻撃状況: 自動スキャナーや、エクスプロイト（脆弱性を悪用する攻撃）、その他の不正アクセスの兆候（例：侵害インジケーター）など、実際に攻撃を受けている可能性があるシステム上の脆弱性は、真っ先に対応すべき対象です。
- 管理者権限を持つアカウント: 管理者権限を持つアカウントが紐づくシステムや端末に脆弱性があると、攻撃者が一度侵入した後の追加攻撃が非常に容易になるため、格段に高いリスクに晒されることになります。管理者ユーザーなど強力な権限を持つアカウントは、機密性の高いデータや重要なシステム機能へのアクセス権を広く持ちます。そのため、このアカウントが侵害されると、攻撃者はさらに権限を昇格させ、インフラ全体を制御してしまう恐れが高くなります。
- 検証用のエクスプロイトコード: 既知のエクスプロイト が存在する脆弱性は、攻撃者がすぐに利用できるツールや手法を持っているため、悪用されるリスクが非常に高くなります。こうした脆弱性は実際に積極的に狙われており、インターネットに直接接続されていないシステムであっても、一度侵入を許すと短時間で広範囲に影響が及ぶおそれがあります。エクスプロイトコードが確認されている脆弱性は、被害の拡大を防ぐためにも、最優先で対処することが極めて重要です。
これらの評価要素を踏まえることで、優先的に対応すべき脆弱性を見極め限られたリソースを最も重大なリスク対策に集中させることができます。このアプローチにより組織にとって最も価値ある資産を守りながら、効果的に脅威を軽減できます。
Datadogで実行時の状況に応じて脆弱性や脅威に優先順位を付ける
Datadog のセキュリティ製品は、検出された脆弱性やセキュリティイベントを、実際に稼働中のデータと結びつけ相関付けします。セキュリティ上の問題点にリアルタイムの状況を紐付けることができるため、危険度をより正確に判断し対応することができます。Datadogでは、Security Inbox と Datadog Severity Scoring の2つの機能を提供しており、リアルタイムの運用状況を活用して不要なアラートを低減することができます。
Datadog Severity Scoring は、CVSSの 基本スコア（脆弱性の深刻さを数値化して評価するための業界標準のフレームワーク）に、「悪用されやすいか」、「外部からアクセスできるか」、「狙われやすいか」などの重要な環境条件を重ね合わせて評価を調整します。お客様の環境に応じてスコアが上下するため、最も優先して対応すべき脆弱性を効率的に特定できます。
この機能は、Datadog Code Security のSecurity Posture Funnelでご確認いただけます。以下の例では、Datadog Code Securityを使い、本番環境で稼働中かつ既知のエクスプロイトコードが存在し、実際に攻撃を受けた脆弱性だけに絞り込むことで、深刻な脆弱性の件数を 92% 以上削減できることが分かります。
次に、Datadog Severity Scoring の別の事例をご紹介します。下図はaiohttp ライブラリの脆弱性を示しており、 CVSS基本スコアは 7.5（高）でした 。しかし、Datadog はこのサービスが本番環境では動作しておらず、攻撃も受けておらず、既知のエクスプロイトコードも存在しない上、Exploit Prediction Scoring System (EPSS) の予測でも悪用される可能性が低いと判断できる情報を持っていました。この状況を踏まえ、Datadog はこの脆弱性の評価を「高」から「低」に再分類しました。
以下は、Datadog Cloud Security の別の例です。EC2インスタンス上の脆弱性はCVSS 基本スコアが 6.5と評価されました。通常はスコアが6.5の場合、緊急対応が必要とまではみなされません。しかし、Datadog はこの EC2 インスタンスに管理者権限を持つ役割が割り当てられていることを検出しました。もし攻撃者がこの権限を悪用するとクラウドの他のリソースにもアクセスされてしまうため、リスクが大幅に上昇します。Datadogはこうした環境情報を加味してスコアを引き上げ、当該の脆弱性が想定以上に深刻であることをセキュリティチームに通知することができます。
また、DatadogのSecurity Inbox を使うと、検出結果の優先順位付けも行います。脆弱性、アラート、設定ミス、権限リスクなどを自動で関連付け、優先度に応じた具体的な対策リストを表示します。これにより、攻撃者が標的としやすいリスクの組み合わせをすぐに把握し、優先的に対策を進めることができます。
ソフトウェアサプライチェーンに自動的に安全性を確保する仕組みを導入する
攻撃者は、npm や PyPI などソフトウェア開発を支えるエコシステムを標的とし、開発者に悪意のあるライブラリをインストールさせようとする手口を日々巧妙化させています。こうした攻撃は、開発者のローカル環境（ノートパソコン）から、企業の CI/CD パイプライン（開発から本番環境へのコード反映を自動化する仕組み）に至るまで、あらゆる段階で発生する可能性があります。
このリスクを軽減するには、多面的な対策が必要です。まず、社内の開発環境や CI/CD パイプラインで不正なパッケージの起動を防ぎ、検知できる仕組みを導入します。さらに、ソフトウェアリポジトリ自体にも保護する仕組みを導入し、開発エコシステム全体を強固にします。
対策としては、ソフトウェアパッケージの使用時にそれらをスキャンし、悪意のあるパッケージを検出・防止する仕組みを導入することが重要です。たとえば、Datadog の Supply-Chain Firewall は、Datadog Security Researchが公開する悪意あるパッケージのデータセットや OSV.dev のような既知のデータベースを参照し、そこに該当するパッケージの実行を自動的にブロックします。さらに、GuardDogを併用すれば、パッケージ全体を包括的に分析して悪意のあるパターンを検出することが可能です。独自のシグネチャを追加することで、検出精度をさらに高めることもできます。
セキュリティ担当者は、いつか防御が突破されることを前提に備える必要があります。そのため、開発者のワークステーションには従来型のエンドポイント検知・対応（EDR）ツールを導入して不審な動きを検出できる体制を整えることが重要です。加えて、CI/CD パイプラインやクラウド環境にも監視範囲を拡大し、同様にマルウェアや攻撃の兆候を早期に検知できる可視性を確保することが求められます。
もう一つの対策としては、パッケージリポジトリやマーケットプレイスの運営者に、攻撃を未然に防ぐ仕組みを導入してもらうよう促すことです。例えば、パッケージの作成者が署名や出所情報を提供すると、利用時に真正性を確認でき、未署名や改ざんされたパッケージが実行されるのを防ぐことができます。
長期間有効な認証情報を廃止し、パイプラインの安全性を強化する
有効期限の長いクラウド認証情報が流出すると攻撃者の侵入口になりやすく、クラウドが侵害されてしまう大きな要因となります。設定ファイルやソースコードなどから認証情報が漏れると、そのまま悪用されかねません。そのため、OpenID Connect (OIDC：認証プロトコル） などを用いて短期間で失効する認証情報を発行し、稼働中のサービスにも可視性を確保し、不正な動きを検知することが必要です。
CI/CDパイプラインでは、外部の自動化システム上でリソースを展開するため、短期間で失効する認証情報の利用が特に重要です。通常はIaCや各種自動化ツールを通じてクラウドにアクセスするため、長期間有効な認証情報を避け、OIDCプロトコルを使って CI/CDプロバイダー上で短期間だけ有効なクラウド認証情報を発行・利用する方法をご紹介します。
- CI/CDプロバイダーは、実行中のパイプラインに署名付きJason Web Token（JWT） を自動で組み込み、パイプラインの正当性を証明します。パイプラインはこのトークンを用いてクラウド認証情報を取得します。
- CI/CD パイプラインはこの JWT を利用してクラウドの認証情報を取得します。手順はクラウドプロバイダーによって異なりますが、例えば、AWS では AssumeRoleWithWebIdentity を呼び出して認証を行います。
- CI/CD パイプラインからのリクエストを受け付けるようクラウド環境が適切に設定されていれば、この処理により数時間のみ有効な短期間認証情報が発行されます。 さらに、過剰な権限を持つユーザーや使われていない認証情報などのリスクについても、すべてのシステムで継続的に監視する必要があります。
Datadogで認証イベントを監視する
Datadog は、クラウド環境における不審な認証や設定ミスを監視するさまざまな機能を提供しています。例えば、 Cloud Securityの標準ルールでは長期間使われていない IAM ユーザー を自動で検出できます。さらに Access Insights 機能により、各リソースにどのアカウントがアクセスできるかを可視化し、詳細な権限情報を把握できます。これをもとに、自動生成ポリシーでアクセス権を適切な範囲に調整し、すぐに権限を最適化できます。
さらに、Datadog Cloud SIEMでは、あらかじめ用意された多数のルールにより、漏えいしたアクセスキーを迅速に検出できます。たとえば、次のようなルールが含まれます。
- 漏えいしたAWSのIAMユーザーアクセスキーを検出する
- AWS上でTruffleHogのユーザーエージェントがで観測された場合、漏えいしたアクセスキーの特定に広く使われているTruffleHogツールを悪用した攻撃者の活動である可能性があります。
- AWSマネージドポリシー「CompromisedKeyQuarantineV2」 が適用された場合、AWSがアクセスキーの公開による漏えいを検知し、該当する IAM ユーザーに隔離措置を講じたことを示します。 また、MITRE ATT&CK マップを活用することで、既存のセキュリティルールが対応しきれていない領域を簡単に特定でき、未観測値（New Value)や異常検知、地理的に不可能な移動（Impossible Travel）などの検出条件を組み合わせたカスタムCloud SIEMルールの作成によって、不審な活動を効率的に検出することもできます。
例えば、有効期限の長いAWSアクセスキーによるAmazon Bedrock へのアクセス試行を検出し、自動でアラートを発するルールを作成することができます。
最後に、App and API Protection を活用することで、膨大な認証関連のノイズをノイズをフィルタリングし、クレデンシャルスタッフィング（漏洩または使い回された ID・パスワードを使って不正ログインを試みる攻撃）やアカウント乗っ取りといった攻撃の兆候となる不審な認証パターンを特定しやすくなります。
最新のパッチを適用した状態を保つため頻繁にデプロイを行う
サービスを定期的にデプロイしておくことで、古い依存ライブラリの滞留を防ぎ、セキュリティリスクを低減できます。コードに変更がなくても、依存関係の更新・ビルド・テストといった CI 処理を定期的に実行するだけで、手間をかけずにサービスの安全性を向上させることが可能です。
とはいえ、依存ライブラリの自動更新にはリスクとメリットの両面があり、採用にあたっては自社の運用体制に適しているか慎重に検討することが推奨されます。
ソフトウェアの依存関係を自動更新することは非常に有効ですが、それだけでは対策として不十分なケースもあります。Datadogの調査では、サービスの約半数がすでにサポートが終了（EOL）したライブラリを使用していることがわかりました。これらのライブラリは、たとえ新たな脆弱性が見つかっても、今後セキュリティパッチが提供されない可能性が高く、重大なリスクとなります。
この問題に対処するには、まず組織内で使用されている EOLライブラリをすべて把握し、それらを優先的に対処（除去・更新）することを推奨します。
加えて、Datadogを使うことで、EOLライブラリが稼働中のサービスやその依存状況を継続的に可視化・監視でき、リスクの高い構成を効率的に特定できます。
Datadogでサービスの稼働状況を監視する
Datadog は、サービスの稼働状況を可視化し、より頻繁かつ迅速なデプロイやライブラリの更新を可能にする多彩な機能を提供しています。中でも CI Pipeline Visibility は、CI/CD システム全体の健全性を俯瞰的に把握できるよう可視化を行い、開発スピードの向上を支援します。
また、Software Catalog を活用すれば、サービスエコシステム全体をリアルタイムかつ一元的に把握できます。この画面から、各サービスの担当者情報、パフォーマンスの監視状況、セキュリティおよびコンプライアンス基準の適用状況をひと目で確認できるほか、SQLインジェクションなどのアクティブな脅威や、アプリケーションコードやライブラリ内の脆弱性もサービス単位で可視化できます。
軽量なコンテナイメージを取り入れる
現在の多くのアプリケーションは、Kubernetes や Amazon ECS、Azure Container Instancesなど、クラウドネイティブなコンテナ環境で動作しており、すべてがコンテナイメージとしてパッケージ化されています。このようなアプリケーションを構築する際には、できるだけ小さく、軽量な構成でコンテナイメージを作成することが重要です。イメージを軽量化することで、デプロイ時間が短縮され、システムの複雑さが軽減されるほか、OSレベルの脆弱性も大幅に減らすことができます。
コンテナイメージを軽量化する方法はいくつかあります。たとえば、既存のイメージを解析し、slimのようなプロファイリングツールを使って不要なソフトウェアを自動的に削除する方法があります。このアプローチは、設計を一から見直すことが難しい既存環境でも容易に導入できる点が大きな利点です。
新しいイメージを構築する際は、ベースイメージをできるだけ軽量に抑えることが重要です。アプリケーションの実行に完全なLinux環境が不要であればは、Dockerのscratchイメージのように、ほぼ空の状態から開始する構成を選択できます。一方で、動作に一部のOSファイルが必要な場合は、Distrolessのような軽量なベースイメージ使用することで、必要最低限の構成を保ちつつ必要な実行環境を確保できます。
アプリケーションに追加の OS サポートファイルが必要な場合でも、開発時にのみ使用する依存パッケージ（ビルド用ライブラリやテストツールなど）を本番環境のイメージに含めないよう注意が必要です。マルチステージビルドなどを活用すると、最終的なコンテナイメージを可能な限り軽量に抑えることができます。
Datadogでコンテナイメージのセキュリティを継続的に監視する
開発から本番環境まで、Datadog は稼働中のコンテナイメージのセキュリティ状態を詳細に可視化します。インフラストラクチャ モニタリング の画面にセキュリティ情報が統合されているため、エンジニアやリソースオーナーは、通常の最適化・本番環境への導入プロセスの一環として、コンテナのセキュリティ対策をスムージに実施できます。
Container Images の画面では、各コンテナイメージのサイズ、作成からの経過日数、検出された脆弱性の詳細を確認できます。特定のイメージをクリックすると、そのイメージを使用して稼働中のすべてのコンテナが一覧表示され、各コンテナのステータスや CPU 使用率もあわせて確認可能です。これにより、各イメージがどこでどのように実行されているかを把握でき、より迅速かつ的確な対応判断を下すための十分な情報を得ることができます。
コンテナの脆弱性を調査する際には、リポジトリのダイジェスト、リソースタグ、脆弱性が導入された時期を示すタイムラインなど、詳細なインサイトを即座に確認できます。さらに、標準搭載されたワークフロー自動化機能により、修正プロセスの自動化も可能です。これにより、セキュリティチームからの修正依頼を待つことなく、エンジニアは性能に影響が出る前に自ら脆弱性へ対処することができます。
さらに、Datadog と Chainguard の連携により、広く使われている脆弱なコンテナイメージを可視化し、リスクを低減するために Chainguard のセキュアなイメージに置き換えるべき箇所を特定できます。これにより、本番環境で稼働させる前に、重要なコンテナイメージを軽量かつ安全な状態で維持することが可能になります。
IaC の導入範囲を拡大し、ClickOps への依存を減らす
Zero Touch 本番環境（ゼロタッチ本番環境）の概念は、2019 年のUSENIX会議において、ミハウ・チャピンスキ（Michał Czapiński）氏とライナー・ヴォラフカ（Rainer Wolafka）氏によって初めて紹介されました。このアプローチでは、人為的なミスを避けるために、手動による操作ではなく、信頼性の高い自動化を中核に据えています。また、「最小権限の原則」に基づき、自動化されたワークフロー（例：クラウド環境へのアプリやサービスのデプロイ）が存在する場合には、オペレーターが本番環境に直接アクセスする必要はなく、安全で使いやすい間接的なインターフェイスを通じて作業を実行できる設計となっています。
ゼロタッチ本番環境を実現するには、、まず IaCを活用してデプロイプロセスを自動化することです。また、既存の環境をコード化して再現したい場合には、Terraformerのようなツールを使うことで、既存のインフラ環境をコード化してIaCツールで再利用することができます。
インフラのプロビジョニングがすべて自動化されると、本番環境に対する操作は通常、参照権限などの最小限のアクセス権で十分になります。ただし、インシデント対応などの特別な状況では、本番環境で一時的に管理者権限が必要になる場合があります。
そのため、事前に「ブレイクグラス（緊急時用）」のロールを定義しておき、承認と監査のプロセスを経て有効化できるようにしておくことが推奨されます。
Datadogでクラウド上の手動操作を可視化・追跡する
クラウド環境で手動による変更が発生した際に、即座に通知を受け取ることは非常に重要です。Datadog Cloud SIEM では、以下のクエリを使用することで、AWS コンソール経由で実行された手動操作を検出し、アラートを自動で発生させることができます (Arkadiy Tetelman 氏の手法をもとに調整したものです) 。
source:cloudtrail @http.useragent:("console.amazonaws.com" OR "Coral/Jakarta" OR "Coral/Netty4" OR "AWS CloudWatch Console" OR S3Console/* OR \[S3Console* OR Mozilla/* OR onsole.*.amazonaws.com OR aws-internal*AWSLambdaConsole/*) -@evt.name:(Get* OR Describe* OR List* OR Head* OR DownloadDBLogFilePortion OR TestScheduleExpression OR TestEventPattern OR LookupEvents OR listDnssec OR Decrypt OR REST.GET.OBJECT_LOCK_CONFIGURATION OR ConsoleLogin) -@userIdentity.invokedBy:"AWS Internal"さらに Datadog は、アプリケーション層や API 層だけでなく、ワークロード層（稼働中のサービス）に対しても、リアルタイムの監視と高度なセキュリティ機能を提供します。 Datadog Workload Protectionは、Linuxカーネル内部で直接動作するeBPF技術を使い、本番環境に負荷をかけずにシステム内部の挙動を高度に可視化します。これには、機密ファイルへのアクセス、ネットワーク接続、プロセスの実行などが含まれます。収集されたアクティビティのシグナルは相関分析され、不審な動作や不正な操作を検出し、実行時における脅威検知、設定ドリフトの防止、インシデント対応といった一連のセキュリティ機能を包括的にサポートします。
DatadogでSDLC全体のセキュリティを可視化・強化する
アプリケーションのリリース頻度を高く保ちながら、システムやアプリケーションを脅威から守るためには、コードに含まれる脆弱性やクラウドリソース全体の設定ミスをエンドツーエンドで可視化し、どのリスクを優先して修正すべきかを判断できる十分なコンテキスト（背景情報）を得ることが重要です。Datadogでは、こうしたリスク情報をシステムの健全性やパフォーマンスを監視するのと同じプラットフォーム上で可視化できるため、チーム間の情報の断絶（サイロ）を解消し、DevSecOps の実践を加速しながら、より高いセキュリティ成果を実現できます。
詳細についてはドキュメント（英語）をご覧ください。Datadogをまだご利用でない場合は、14 日間の無料トライアルを今すぐお試しいただけます。
