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.


Static Analysis is in private beta. Python, JavaScript, TypeScript, and Docker are the only supported languages. To request access, contact Support.

Static Analysis is not available for the site.

Static Analysis is a clear-box software testing technique that analyzes a program’s pre-production code without the need to execute the program, meaning that the program is static because it isn’t running. Static Analysis helps you identify maintainability issues and security vulnerabilities early in the Software Development Life Cycle (SDLC) to ensure only the highest quality, most secure code makes it to production. Static Analysis tools that scan for security vulnerabilities are also commonly referred to as Static Application Security Testing (SAST) tools.

Using Static Analysis provides organizations with the following benefits:

  • Static Analysis takes the guesswork out of adhering to an organization’s code standards, enabling your development team to ship compliant code without significant impacts to developer velocity.
  • An organization’s applications are less vulnerable to security breaches over time, due to new vulnerabilities being caught through SAST scans before code reaches production.
  • New developers to an organization are able to onboard faster because Static Analysis enables an organization to maintain a more readable codebase over time.
  • An organization’s software becomes reliable over time by virtue of the code being more maintainable because the risk of a developer introducing new defects to the code is minimized.


CI Providers

With Static Analysis, you can integrate feedback on code reviews for various languages in any CI platform provider of choice. See the documentation for information about the following integrations:


With Static Analysis, you can get real-time feedback as you edit a file in your Integrated Development Environment (IDE). See the documentation for information about the following integrations:


To use Datadog Static Analysis, add a static-analysis.datadog.yml file to your repository’s root directory to specify which rulesets to use.

For example, for Python rules:

  - python-best-practices
  - python-security
  - python-code-style
  - python-inclusive
  - "path/to/ignore"
  - "**.js"

A static-analysis.datadog.yml file supports the following:

rulesetsA list of ruleset names. View all available rulesets.true
ignore-pathsA list of relative paths to ignore. It supports using globbing patterns.false
ignore-gitignoreDetermines whether Datadog Static Analysis analyzes the content in a .gitignore file.falsefalse

Configure your Datadog API and application keys and run Static Analysis in the respective CI provider.

To run Static Analysis with CircleCI, follow these instructions for setting up a CircleCI Orb.

If you don’t use CircleCI Orbs or GitHub Actions, you can run the Datadog CLI directly in your CI pipeline platform.


  • unzip
  • Node.js 14 or later

Configure the following environment variables:

DD_API_KEYYour Datadog API key. This key is created by your Datadog organization and should be stored as a secret.Yes
DD_APP_KEYYour Datadog application key. This key is created by your Datadog organization and should be stored as a secret.Yes
DD_SITEThe Datadog site to send information to. Your Datadog site is .Nodatadoghq.com

Provide the following inputs:

serviceThe name of the service to tag the results with.Yes
envThe environment to tag the results with. ci is a helpful value for this input.Nonone
cpu_countSet the number of CPUs used by the analyzer. Defaults to the number of CPUs available.No
subdirectoryThe subdirectory path the analysis should be limited to. The path is relative to the root directory of the repository.No
Add a `--performance-statistics` flag to your static analysis command to get execution time statistics for analyzed files.

Select an analyzer for your architecture and OS:


Add the following to your CI pipeline:

The following example uses the x86_64 Linux version of Datadog's static analyzer. If you're using a different OS or architecture, you should select it from the table above and update the DATADOG_STATIC_ANALYZER_URL value below. You can view all releases on our GitHub Releases page.
# Install dependencies
npm install -g @datadog/datadog-ci 

# Download the latest Datadog static analyzer:
# https://github.com/DataDog/datadog-static-analyzer/releases
curl -L $DATADOG_STATIC_ANALYZER_URL > /tmp/ddog-static-analyzer.zip
unzip /tmp/ddog-static-analyzer.zip -d /tmp
mv /tmp/datadog-static-analyzer /usr/local/datadog-static-analyzer

# Run Static Analysis
/usr/local/datadog-static-analyzer -i . -o /tmp/report.sarif -f sarif

# Upload results
datadog-ci sarif upload /tmp/report.sarif --service <service> --env <env>

Upload third-party static analysis results to Datadog

SARIF importing has been tested for Snyk, CodeQL, Semgrep, Checkov, Gitleaks, and Sysdig. Please reach out to Datadog Support if you experience any issues with other SARIF-compliant tools.

You can send results from third-party static analysis tools to Datadog, provided they are in the interoperable Static Analysis Results Interchange Format (SARIF) Format.

To upload a SARIF report:

  1. Ensure the DD_API_KEY and DD_APP_KEY variables are defined.

  2. Optional: Set a DD_SITE variable (default: datadoghq.com).

  3. Install the datadog-ci utility:

    npm install -g @datadog/datadog-ci
  4. Run the third-party static analysis tool on your code and output the results in the SARIF format.

  5. Upload the results to Datadog:

    datadog-ci sarif upload $OUTPUT_LOCATION --service <datadog-service> --env <datadog-env>

Run Static Analysis in a CI pipeline

Datadog Static Analysis runs in your CI pipelines using the datadog-ci CLI and checks your code against Datadog’s default rulesets.

Search and filter results

After you configure your CI pipelines to run the Datadog Static Analyzer, violations appear on the Static Analysis Results page. To filter your results, use the facets to the left of the list, or search.

Each violation is associated with a specific commit and branch from your repository on which the CI pipeline ran. The rows represent every violation per commit.

Click on a violation to open a side panel that contains information about the scope of the violation and where it originated.

Side panel for a static analysis violation

The content of the violation is shown in tabs:

  • Source Code: A description of the violation and the lines of code that caused it. To see the offending code snippet, configure the Datadog GitHub App.
  • Fixes: One or more code fixes that can resolve the violation, which you can copy and paste.
  • Event: JSON metadata regarding the Static Analysis violation event.

Using suggested fixes

Fixes tab of a static analysis violation

In Datadog Static Analysis, there are two types of suggested fixes:

  1. Default Suggested Fix: For simple violations like linting issues, the rule analyzer automatically provides templated fixes.
  2. AI Suggested Fix: For complex violations, fixes are typically not available beforehand. Instead, you can use AI Suggested Fixes, which use OpenAI’s GPT-4 to generate a suggested fix. You can choose between “Text” and “Unified Diff” fixes, which outputs plain text instructions or a code change for resolving the violation, respectively.

The two types of fixes are distinguished visually in the UI with different labels.

Default Suggested Fixes:

Visual indicator of a default static analysis suggested fix

AI Suggested Fixes:

Visual indicator of an AI static analysis suggested fix

Ignoring violations

You can ignore a specific instance of a violation by commenting no-dd-sa above the line of code to ignore. This prevents that line from ever producing a violation. For example, in the following Python code snippet, the line foo = 1 would be ignored by Static Analysis scans.

foo = 1
bar = 2

Further Reading