How Application Security Monitoring Works in Datadog

Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.


Datadog Application Security Monitoring (ASM) provides observability into application-level attacks that aim to exploit code-level vulnerabilities.

APM records information about each HTTP request, referred to as traces. Datadog ASM uses the information APM is already collecting, and flags attack attempts based on suspicious requests that match known attack patterns. Security signals are an aggregation of suspicious requests. Depending on your security signal settings, you can receive notifications from Slack, email, or PagerDuty.

Traditional Web Application Firewalls (WAFs) are usually deployed at the perimeter and have no context of the application behavior. For ASM to be effective, it must be embedded in the application to get access to the data. Datadog ASM leverages known attack patterns, similar to a Web Application Firewall (WAF) but with additional application context to increase the signal to noise ratio, lowering false positives.


For Datadog ASM to be compatible with your Datadog configuration, you must have APM enabled, and send traces to Datadog. ASM uses the same libraries used by APM, so you don’t need to deploy and maintain another library. Steps to enable Datadog ASM are specific to runtime language. Check to see if your language is supported in the ASM prerequisites.


Datadog ASM uses processes already contained in the Agent and APM, so there are negligible performance implications when using it. When APM is enabled, the Datadog Library generates distributed traces. Datadog ASM flags security activity in traces by using known attack patterns. Correlation between the attack patterns and the execution context provided by the distributed trace triggers security signals based on detection rules.

A diagram illustrates that the Datadog tracer library operates at the application service level and sends traces to the Datadog backend. The Datadog backend flags actionable security signals and sends a notification to the relevant application, such as PagerDuty, Jira or Slack.

Data privacy

There are multiple methods used to avoid your sensitive information being indexed. To take further action, you can set up custom and static scrubbers, and use exclusion filters.

Note: Datadog ASM does not automatically obfuscate sensitive information or PII. To keep this sensitive data from being sent to Datadog, configure the Datadog Agent or Tracer for data security.

Contact Support to delete sensitive data that may have been indexed.

Threat detection methods

Datadog uses multiple pattern sources, including the OWASP ModSecurity Core Rule Set to detect known threats and vulnerabilities in HTTP requests. When an HTTP request matches one of the OOTB detection rules, a security signal is generated in Datadog.

Security Signals are automatically created when Datadog detects meaningful attacks targeting your production services. It provides you with visibility on the attackers and the targeted services. You can set custom detection rules with thresholds to determine which attacks you want to be notified about.


Datadog ASM categorizes attack attempts into different threat types:

  • Unqualified attacks match inbound HTTP requests with known attack patterns. For example, no correlation with the service’s business-logic is found after correlating with the execution context provided by the trace.
  • Contextualized attacks correlate the attack attempts performed on the service with a matching business-logic. For example, SQL injection patterns on a service performing SQL statements.
  • A Vulnerability is triggered when an attack attempt gives evidence that a vulnerability has been successfully exploited, after matching known attack patterns.

Datadog ASM includes over 100 attack patterns that help protect against many different kinds of attacks, including the following vulnerabilities:

  • SQL injections
  • Code injections
  • Shell injections
  • NoSQL injections
  • Cross-Site Scripting (XSS)
  • Sever-side Request Forgery (SSRF)

How Datadog ASM protects against Log4Shell

Datadog ASM identifies Log4j Log4Shell attack payloads and provides visibility into vulnerable apps that attempt to remotely load malicious code. When used in tandem with the rest of Datadog’s Cloud SIEM, you can investigate to identify common post-exploitation activity, and proactively remediate potentially vulnerable Java web services acting as an attack vector.

Further Reading