AI-enhanced Static Code Analysis (SAST) features help automate security decision-making across the entire static analysis lifecycle, from identifying malicious intent, to improving detection, reducing noise, and accelerating response.

This document describes each of the AI-enhanced SAST features.

Summary of AI features

Malicious PR protection

Datadog Static Code Analysis (SAST) Malicious PR protection uses LLMs to detect and prevent malicious code changes at scale. By scanning code for known vulnerabilities and detecting potentially malicious intent in the pull requests (PRs) submitted to your repositories, this functionality helps you to:

• Scale your code reviews as the volume of AI-assisted code changes increases
• Secure code changes from both internal and external contributors
• Embed code security into your security incident response workflows

Repository support

Malicious PR protection is supported for default branches and GitHub repositories only.

Detection coverage

Malicious code changes come in many different forms. Datadog SAST covers attack vectors such as:

• Malicious code injection
• Attempted secret exfiltration
• Pushing of malicious packages
• CI workflow compromise

Examples include the tj-actions/changed-files breach (March 2025) and obfuscation of malicious code in npm packages (September 2025). Read more in the blog post here.

Search and filter results

Detections from Datadog SAST on potentially malicious PRs can be found in Security Signals from the rule ID def-000-wnp.

There are two potential verdicts: malicious and benign. They can be filtered for using:

• @malicious_pr_protection.scan.verdict:malicious
• @malicious_pr_protection.scan.verdict:benign.

Signals can be triaged directly in Datadog (assign, create a case, or declare an incident), or routed externally using Datadog Workflow Automation.

Validation and false-positive filtering

For a subset of SAST vulnerabilities, Bits AI can review the context of the finding and assess whether it is more likely to be a true or false positive, along with a short explanation of the reasoning.

To narrow down your initial list for triage, in Vulnerabilities, select Filter out false positives. This option uses the -bitsAssessment:"False Positive" query.

Each finding includes a This vulnerability was assessed by Bits AI section with an explanation of the assessment.

For each finding, you can provide Bits AI with feedback on its assessment using 👍 or 👎.

AI-powered remediation

AI-powered remediation saves time by replacing the filing of individual pull requests to fix vulnerabilities with bulk-remediation campaigns that can fix multiple vulnerabilities at once.

AI-powered remediation uses the Bits AI Dev Agent to power single and multiple vulnerability fixes in Code Security. You create campaigns to fix a subset of vulnerabilities, and each campaign can automatically create pull requests to fix those vulnerabilities.

Bulk remediation: Campaigns

The Campaign is how you operationalize AI-powered remediation in Datadog. It connects SAST findings to automated fixes through customizable PR workflows with human-tunable AI behavior.

When you create a campaign, the Bits AI Dev Campaign tool initiates a batched remediation to fix a subset of matching vulnerabilities.

A campaign defines the following:

Campaign in progress

When you click Create Campaign, Bits AI Dev Agent does the following:

1. Loads SAST findings for the selected repo(s), path(s), and rule.
2. Generates patches for each group of findings.
3. Creates PRs according to your session rules.
4. If Bits AI Dev notifications are turned on, PRs are automatically sent through Slack to relevant stakeholders.
5. Lets you review, edit, and merge fixes using GitHub.

The campaign page shows whether the AI is actively remediating real findings, and how many have been remediated or pending.

You can click a session to view the code changes in more detail and chat with the Bits AI Dev Agent to ask for changes.

Session details

A remediation session shows the full lifecycle of an AI-generated fix. It includes the original security finding, a proposed code change, an explanation of how and why the AI made the fix, and if enabled, CI results from applying the patch.

Session details make each remediation transparent, reviewable, and auditable, helping you safely adopt AI in your secure development workflow.

Session details include the following:

• Header: Identifies the campaign, time of session creation, and affected branch, file, or PR.
• Title: Summarizes the remediation goal based on the vulnerability being fixed.
• Dev Agent Campaign, Model name, PR ID: Indicates the AI model used, campaign source, and related PR metadata.
• Right panel:
  • Suggested code change: Displays a side-by-side comparison of the vulnerable code and the AI-generated patch.
  • View Pull Request: Opens the linked GitHub PR to review or merge the proposed changes.
• Left panel displays the chat message history, for example:
  • Fix the following static analysis violation: Explains the triggered rule, the security risk, and why the original code is unsafe.
  • Fixing process recap: Shows exactly how the AI read the code, understood the context, chose its approach, and applied the fix. This is helpful for auditability, compliance, and trust. You can confirm that the AI isn’t rewriting code blindly, but applying defensible and explainable patterns.
  • CI via GitHub: Describes whether the AI-generated patch breaks anything downstream, and includes full error logs. This helps you validate that a fix is not only secure but also safe to deploy, without needing to leave the platform.
  • Summary: Recaps the impact of the fix and provides next steps or guidance if tests failed or PR needs to be rebased.
  • Bits AI chat field: Lets you interactively refine the fix or ask the AI follow-up questions. This makes remediation collaborative and tunable, giving security engineers control without needing to write the patch themselves.

Scope

AI-powered remediation is limited to SAST only for vulnerabilities within the OWASP Top 10 across all languages. It only applies to findings on the default branch.

Further reading

Documentation, liens et articles supplémentaires utiles:

Log processing pipelinesDOCUMENTATION Using LLMs to filter out false positives from static code analysisBLOG