Runtime Code Analysis (IAST)

This product is not supported for your selected Datadog site. ().
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、お気軽にご連絡ください

Overview

Datadog Runtime Code Analysis (IAST) identifies code-level vulnerabilities in your services, using an Interactive Application Security Testing (IAST) approach to find vulnerabilities within your application code based on your Datadog application instrumentation. IAST enables Datadog to identify vulnerabilities using legitimate application traffic instead of relying on external tests that could require extra configuration or periodic scheduling. It also monitors your code’s interactions with other components of your stack, such as libraries and infrastructure, providing an up-to-date view of your attack surface area.

How it works

Runtime Code Analysis (IAST) uses the Datadog tracing library to follow user-controlled data as it flows through your application at runtime. A vulnerability is only reported when IAST can confirm that tainted input reaches a vulnerable point in the code, which keeps findings actionable.

  • Tracking data sources: IAST observes data entering your application from external sources such as request URLs, bodies, or headers. These inputs are tagged and tracked throughout their lifecycle.
  • Analyzing data flow: The Datadog tracing library tracks how input data moves through the application, even when it is transformed, split, or combined. This allows IAST to understand if and how the original input reaches sensitive parts of the code.
  • Identifying vulnerable points: IAST detects code locations where user-controlled inputs are used in potentially insecure ways—for example, in SQL queries, dynamic code execution, or HTML rendering.
  • Confirming the vulnerability: A vulnerability is only reported when IAST can confirm that tainted input actually reaches a vulnerable point in the code. This approach minimizes false positives and keeps findings actionable.

Supported vulnerability types

Datadog IAST detects the following code-level vulnerability types across supported languages. Coverage may vary by language and framework; for framework-level support, see Compatibility Requirements.

SeverityDetection RuleJava.NETNode.jsPython
CriticalNoSQL InjectionFALSETRUETRUEFALSE
CriticalSQL InjectionTRUETRUETRUETRUE
CriticalServer-Side Request Forgery (SSRF)TRUETRUETRUETRUE
CriticalCode InjectionFALSEFALSETRUEFALSE
CriticalCommand InjectionTRUETRUETRUETRUE
HighLDAP InjectionTRUETRUETRUEFALSE
HighEmail HTML InjectionTRUETRUETRUEFALSE
HighHardcoded SecretsTRUETRUETRUEFALSE
HighHardcoded PasswordsFALSEFALSETRUEFALSE
HighPath TraversalTRUETRUETRUETRUE
HighTrust Boundary ViolationTRUETRUEFALSEFALSE
HighCross-Site Scripting (XSS)TRUETRUEFALSEFALSE
HighUntrusted DeserializationTRUEFALSEFALSEFALSE
HighUnvalidated RedirectTRUETRUETRUEFALSE
HighXPath InjectionTRUETRUEFALSEFALSE
HighHeader InjectionTRUETRUETRUETRUE
HighDirectory Listing LeakTRUEFALSEFALSEFALSE
HighDefault HTML Escape InvalidTRUEFALSEFALSEFALSE
HighVerb TamperingTRUEFALSEFALSEFALSE
MediumNo SameSite CookieTRUETRUETRUETRUE
MediumInsecure CookieTRUETRUETRUETRUE
MediumNo HttpOnly CookieTRUETRUETRUETRUE
MediumWeak HashingTRUETRUETRUETRUE
MediumWeak CipherTRUETRUETRUETRUE
MediumStacktrace LeakTRUETRUEFALSEFALSE
MediumReflection InjectionTRUETRUEFALSEFALSE
MediumInsecure Authentication ProtocolTRUETRUEFALSEFALSE
MediumHardcoded KeyFALSETRUEFALSEFALSE
MediumInsecure JSP LayoutTRUEFALSEFALSEFALSE
LowHSTS Header MissingTRUETRUETRUEFALSE
LowX-Content-Type-Options Header MissingTRUETRUETRUEFALSE
LowWeak RandomnessTRUETRUETRUETRUE
LowAdmin Console ActiveTRUEFALSEFALSEFALSE
LowSession TimeoutTRUEFALSEFALSEFALSE
LowSession RewritingTRUEFALSEFALSEFALSE

Key capabilities

Review and prioritize vulnerabilities

The Vulnerabilities Explorer for IAST provides a dedicated, vulnerability-centric view of the code-level vulnerabilities detected by IAST. All findings in this explorer correspond to vulnerabilities confirmed in services running with the Datadog tracing library and IAST enabled. Each Code Security capability has its own explorer (SAST, SCA, IAST, Secrets Scanning, and IaC), so IAST findings are not mixed with other types in this view.

Each finding includes a short description, the impacted services, the vulnerability type, the first and last detection times, and the exact file, method, and line number where the issue was confirmed. You can filter results by service, team, environment, severity, and other facets to focus on the work that matters to your group.

Datadog severity score

Because IAST detects vulnerabilities in your first-party code, findings do not have a public CVE or CVSS score. Datadog assigns a base severity for each vulnerability type (for example, Command Injection or SQL Injection), and then adjusts that base into the Datadog Severity Score based on runtime context and exploitability signals observed in your environment. These factors help distinguish theoretical risk from vulnerabilities that are more likely to be exploited in real-world environments. The table below describes how each factor influences the final score.

Risk factorHow it is evaluatedImpact on the score
Base severityDefined by Datadog based on the vulnerability type (for example, Command Injection, SQL Injection).Starting point for the severity score.
Production runtime contextWhether the affected service is running in a production environment.Decreased if the service is not running in production.
Under attackEvidence of active attack activity targeting the service.Decreased if there is no observed attack activity.

Remediate a code vulnerability

Click any finding in the Vulnerabilities Explorer for IAST to open the vulnerability side panel, which gives developers and security engineers the full context needed to fix the issue.

The panel summarizes the finding’s severity, vulnerability type, due date, and runtime indicators (such as Exposed to Attacks and Service In Production), and shows where the vulnerability was confirmed in your code, when it was first and last detected, which service, environment, and team it impacts, and relevant standards references like the CWE. When the GitHub, GitLab, or Azure DevOps integration is enabled, Datadog also surfaces the commit that introduced the vulnerability and a snippet of the vulnerable code.

The side panel includes tabs for Data Flow (how tainted input reaches the vulnerable sink), Remediation (step-by-step guidance and example code for your framework), Datadog Severity Breakdown (how runtime context shaped the score), and More Information (related references). From the Next Steps panel on the right, you can change the finding’s status, mute it, create a Jira or ServiceNow ticket, or jump straight to the remediation steps.

For repeatable workflows, use Set up Automation to apply the same actions automatically to new and existing findings that match your criteria. See Automate triage and remediation for details.

Create tickets from findings

You can create a bidirectional ticket in Jira or ServiceNow directly from any IAST finding to track and remediate issues in your existing workflows. Ticket status remains synced between Datadog and your ticketing tool, so updates made in either system stay aligned. For more information, see Ticketing integrations.

To create tickets in bulk or as part of a repeatable process, use Automation Pipelines to automatically open tickets for findings that match conditions such as severity, service, environment, or team.

Mute findings

To suppress a finding, click Mute in the finding details panel. This opens a workflow where you can create an Automation Rule for context-aware filtering by tag values (for example, by service or env). Muting a finding hides it from active triage and excludes it from reports.

To restore a muted finding, click Unmute in the details panel. You can also use the Status filter on the Vulnerabilities Explorer for IAST to review muted findings.

Notify on new findings

Route new IAST findings to the right team as soon as they are detected. Datadog notifications support Slack, Microsoft Teams, email, PagerDuty, webhooks, and more, so each team can receive findings where they already work. For setup details, see Security Notifications.

Automate triage and remediation

Use Automation Pipelines to apply consistent triage and remediation actions to new and existing IAST findings, without manual intervention. From the Set up Automation menu in the finding side panel—or from the Automation Pipelines settings page—you can:

  • Mute findings that match conditions such as service, environment, or vulnerability type.
  • Set a due date based on severity and runtime context, so remediation SLAs are enforced automatically.
  • Add findings to the Security Inbox to focus your team on the highest-priority work.
  • Create tickets in Jira or ServiceNow for matching findings.
  • Notify the right team in Slack, Microsoft Teams, email, or other channels.

Automation Pipelines apply to both newly detected findings and findings that already exist in Datadog, so policy changes are enforced retroactively across your environment.

Code-level vulnerability context in APM

IAST enriches the information that Application Performance Monitoring (APM) already collects by flagging services where code-level vulnerabilities have been confirmed. Vulnerable services are highlighted directly in the Security view in the APM Software Catalog, so you can pivot from a vulnerable service to its traces, logs, and infrastructure context in a single click.

Vulnerability lifecycle

Datadog tracks IAST vulnerabilities at the service level, based on what the Datadog tracing libraries confirm in your running applications. A vulnerability is opened when IAST confirms a code-level vulnerability in a running service. A vulnerability is closed when Datadog no longer detects it according to the life cycle rules below.

ProductScopeScenarioWhen a vulnerability is openedWhen a vulnerability is closed
IASTServiceRunning serviceDatadog confirms a code-level vulnerability in a running service.After 14 days, if the vulnerability is not detected again during that period.
IASTServiceNew service version deployedDatadog confirms a code-level vulnerability in a running service.24 hours after the vulnerability is no longer detected in the new version, in the environment where it was originally detected.

If a previously closed vulnerability is detected again within 15 months, Datadog automatically reopens it so that recurring issues are not lost.

Set up Runtime Code Analysis (IAST)

To enable IAST, configure the Datadog Tracing Library for your service. Detailed, language-specific instructions are available in Set up Runtime Code Analysis (IAST). If you need additional help, contact Datadog support.

For information on disabling IAST, see Disabling Code Security.

Further Reading