If you experience issues setting up or configuring Datadog Code Security, use this page to start troubleshooting. If you continue to have trouble, contact Datadog Support.

Static Code Analysis (SAST)

For issues with the Datadog static analyzer, include the following information in a bug report to Datadog Support.

• Your code-security.datadog.yaml (or legacy static-analysis.datadog.yml) file
• The output of your static analysis tool (such as a CLI) that is run locally or in a CI/CD pipeline
• The SARIF file produced (if there are any available)
• The URL of your repository (public or private)
• The name of the branch you ran the analysis on
• The exact command line used to run the Datadog Static Analyzer

Performance issues

If you are experiencing performance issues, you can enable the --performance-statistics flag when running the static analysis tool from the command line.

For performance issues, include the following information:

• Your code-security.datadog.yaml (or legacy static-analysis.datadog.yml) file
• The output of your static analysis tool (such as a CLI) that is run locally or in a CI/CD pipeline
• The URL of your repository (public or private)

Note: If you are using Static Analysis and GitHub Actions, set the enable_performance_statistics parameter to true.

Blocking issues

If you are experiencing issues unrelated to performance or if the Datadog Static Analyzer fails to exit, run the Datadog Static Analyzer with the --debug true --performance-statistics flag.

Getting a 403 error when running the analyzer

Ensure that the following variables are correctly specified: DD_APP_KEY, DD_API_KEY, and DD_SITE when running the analyzer and datadog-ci.

Issues with SARIF uploads

When uploading results from third-party static analysis tools to Datadog, ensure that they are in the interoperable Static Analysis Results Interchange Format (SARIF) Format. Node.js version 14 or later is required.

To upload a SARIF report, follow the steps below:

1. Ensure the DD_API_KEY and DD_APP_KEY variables are defined.

2. Optionally, set a DD_SITE variable (this defaults to 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
   

If reports are missing in Datadog, please define the following environment variables before invoking datadog-ci:

• DD_GIT_REPOSITORY_URL: URL of the repository
• DD_GIT_BRANCH: branch being committed to
• DD_GIT_COMMIT_SHA: commit sha

SARIF file too large

We are filtering SARIF files that are too large. If your code is not being scanned because your SARIF file is too large, consider the following options:

• Update your configuration to scan only specific directories.
• Configure the analyzer to run only the rulesets necessary for your codebase.

Update the configuration either through the Datadog application or by modifying the code-security.datadog.yaml file.

No PR comments or PR gates for third-party SARIF uploads

PR comments and PR gates are only supported for results produced by Datadog’s official static analysis tools:

• datadog-static-analyzer
• datadog-saist

If you upload SARIF results from a third-party tool, findings appear in the Datadog UI but do not trigger PR comments or PR gate evaluations.

GLIBC_X.YY not found error message

If you run the static analyzer in your CI pipeline and get an error message similar to the following line:

version `GLIBC_X.YY' not found

It means that you are either:

• running your CI pipeline with a Linux distribution that contains an old version of the glibc. In this case, Datadog recommends upgrading to the latest version. The analyzer always runs with the latest of Ubuntu/Debian based-systems.
• running your CI pipeline with a Linux distribution that does not rely on the glibc (such as Alpine Linux). Instead, run your CI pipeline with a distribution that supports the latest version of the glibc (such as the stable version of Ubuntu).

Services or teams in the SAST explorer or Repositories view are not updating

Results for services and teams in Static Code Analysis (SAST) are based on the entity.datadog.yml or CODEOWNERS files from your repository’s default branch. If you’ve made changes to these files in a feature branch, those updates are not reflected in the vulnerability for that branch.

After updating either file on your default branch, it may take up to six hours for the changes to appear in subsequent scan results.

Results are not being surfaced in the Datadog UI

If you are running Code Security on a non-GitHub repository, ensure that the first scan is ran on your default branch. If your default branch is not one of master, main, default, stable, source, prod, or develop, you must attempt a SARIF upload for your repository and then manually override the default branch in-app under Repository Settings. Afterwards, uploads from your non-default branches will succeed.

If you are using Datadog’s analyzer, diff-aware scanning is enabled by default. If you are running the tool within your CI pipeline, make sure that datadog-ci runs at the root of the repository being analyzed.

Diff-aware is not working

If diff-aware is not working with the Static Analyzer, ensure that:

1. The default branch is specific to your repository.
2. At least one revision with the same configuration (for example, same rulesets, same arguments, or only/ignore flags) has been pushed to the repository’s default branch.
3. The current user can read the repository metadata. If they do not have the correct permissions, run this command: git config --global --add safe.directory <repo-path>.

You can also run datadog-static-analyzer with the --debug option to get more information.

Note: Diff-aware works only on feature branches. For more information, learn about the implementation details of diff-aware.

Software Composition Analysis (SCA)

For issues with Datadog Software Composition Analysis (SCA), include the following information in a bug report to Datadog Support.

• The output of your SCA tool (such as CLI) that is run locally or in a CI/CD pipeline
• The SBOM file produced (if there are any available)
• The URL of your repository (public or private)
• The name of the branch you ran the analysis on
• The list of dependency files in your repository (such as package-lock.json, requirements.txt, or pom.xml)

Scan Java JAR directories

Some Java projects rely on third-party JAR files checked into the repository — for example, in a lib/ directory — rather than a complete Maven or Gradle manifest. When your build pulls dependencies straight from those JARs, or when your dependency manifests are incomplete or out of sync with what your build actually uses, you can scan the JAR files directly and treat them as the source of truth.

Datadog SBOM generator includes an opt-in parser that extracts Maven metadata embedded in each JAR and reports every detected artifact as a Maven component in the resulting SBOM. Use this approach when the JARs on disk are the most reliable record of what your build depends on. For projects with standard Maven or Gradle manifests, scan the supported manifests instead — they give you transitive dependencies and source-file matching that the JAR parser cannot.

Requirements

• datadog-sbom-generator version 1.10.2 or later. See the releases page on GitHub.
• Each JAR must include Maven metadata at META-INF/maven/<groupId>/<artifactId>/pom.properties. JARs without this metadata are skipped with a warning, and scanning continues.

To confirm the JAR parser is available in your installed version, run:

datadog-sbom-generator parsers list

Look for jar in the output.

Enable the JAR parser

The JAR parser is not part of the default parser set. Enable it explicitly with --enable-parsers jar:

datadog-sbom-generator scan --enable-parsers jar /path/to/lib

Replace /path/to/lib with the directory that contains your JAR files. The scanner walks the directory and reads metadata from every file with a .jar extension.

To scan JAR files and Maven manifests together:

datadog-sbom-generator scan --enable-parsers jar,maven /path/to/repository

Upload the SBOM to Datadog

Save the SBOM to a file, then upload it with datadog-ci:

datadog-sbom-generator scan \
    --enable-parsers jar \
    --output sbom.json \
    /path/to/lib

datadog-ci sbom upload sbom.json

Set DD_API_KEY, DD_APP_KEY, and DD_SITE in your CI environment before you run the upload.

How the JAR parser identifies components

When Maven packages a JAR, it embeds a pom.properties file at:

META-INF/maven/<groupId>/<artifactId>/pom.properties

The parser reads the groupId, artifactId, and version from that file and emits one Maven component per detected entry. A single JAR can contain more than one pom.properties entry — the parser emits one component for each.

Components detected this way carry two SBOM properties:

Limitations

The JAR parser is intentionally narrow. Use it with these constraints in mind:

• Only files with a .jar extension are scanned. Other ZIP-based archives, including .war and .ear, are not scanned.
• JARs without META-INF/maven/.../pom.properties are skipped. Components without embedded Maven metadata are not reported.
• Transitive dependencies are not resolved. Each detected JAR is reported as a direct dependency.
• Source-file matching is not available for components detected through the JAR parser.

If you need transitive resolution, source matching, or richer dependency context, scan the standard Maven or Gradle manifests instead. The JAR parser is the right tool when your build does not have a trustworthy manifest to scan.

Issues with SBOM uploads

While the Datadog SBOM generator is recommended, Datadog supports the ingestion of any SBOM files. Please ensure your files adhere to either the Cyclone-DX 1.4 or Cyclone-DX 1.5 formats.

Ingestion of SBOM files is verified for the following third-party tools:

• trivy

To ingest your SBOM file into Datadog, follow the steps below:

1. Install the datadog-ci CLI (requires that Node.js is installed).
2. Ensure that your DD_SITE, DD_API_KEY and DD_APP_KEY environment variables are set.
3. Invoke the tool to upload the file to Datadog. Installing and invoking the tool can be done using these two commands:

# Install datadog-ci
npm install -g @datadog/datadog-ci

# Upload SBOM file
datadog-ci sbom upload /path/to/sbom-file.json

Services or teams in SCA libraries are not updating

Results for services and teams in SCA are based on the entity.datadog.yml or CODEOWNERS files from your repository’s default branch. If you’ve made changes to these files in a feature branch, those updates are not reflected in the vulnerability or library data for that branch.

After updating either file on your default branch, it may take up to six hours for the changes to appear in subsequent scan results.

Results are not being surfaced in the Datadog UI

If you are running Code Security on a non-GitHub repository, ensure that the first scan is ran on your default branch. If your default branch is not one of master, main, default, stable, source, prod, or develop, you must attempt an SBOM upload for your repository and then manually override the default branch in-app under Repository Settings. Afterwards, uploads from your non-default branches will succeed.

No package detected for C# projects

The Datadog SBOM generator, (datadog-sbom-generator), extracts dependencies from a packages.lock.json file. If you do not have this file, you can update your project definition to generate it. Follow these instructions to update your project definition to generate a packages.lock.json file.

The generated lock file is used by datadog-sbom-generator to extract dependencies and generate an SBOM.

No results from Datadog-hosted scans

Datadog-hosted SCA scans do not support repositories that:

• Use Git Large File Storage (git-lfs)
• Contain invalid or reserved file paths (such as / or \\)
• Contain file paths with parent directory traversal (..)
• Contain file names longer than 255 characters

If any of these conditions apply to your repository, and you cannot update your repository to account for these constraints, set up the analysis in a CI pipeline to run SCA and upload results to Datadog.

Missing libraries

To ensure data quality, Datadog applies validation rules during SBOM processing. Libraries that meet any of the following criteria are excluded:

• Missing version: The library does not specify a version.
• Non-ASCII name: The library name contains characters outside the ASCII character set.
• Empty purl: The package URL (purl) field is missing or blank.
• Invalid purl: The package URL is present but not in a valid purl format.
• Unsupported language: The library is associated with a programming language that Datadog does not support.

No vulnerabilities detected by Software Composition Analysis

There are a series of steps that must run successfully for vulnerability information to appear either in the Catalog Security view or in the Vulnerabilities explorer. It is important to check each step when investigating this issue.

Confirming runtime detection is enabled

If you have enabled Runtime Software Composition Analysis (SCA) on your services, you can use the metric datadog.appsec.risk_management.sca.host_instance to check if it is running.

1. Go to Metrics > Summary in Datadog.
2. Search for the metric datadog.appsec.risk_management.sca.host_instance. If the metric doesn’t exist, then there are no services running Runtime Software Composition Analysis (SCA). If the metric exists, the services are reported with the metric tags host and service.
3. Select the metric, and in the Tags section, search for service to see which services are running AAP.

If you are not seeing datadog.appsec.risk_management.sca.host_instance, check the in-app instructions to confirm that all steps for the initial setup are complete.

Runtime application security data is sent with APM traces. See APM troubleshooting to confirm APM setup and check for connection errors.

Confirm tracer versions are updated

See the Application Security product set up documentation to validate you you are using the right version of the SDK. These minimum versions are required to start sending telemetry data that includes library information.

Ensure the communication of telemetry data

Ensure the DD_INSTRUMENTATION_TELEMETRY_ENABLED environment variable (DD_TRACE_TELEMETRY_ENABLED for Node.js) is set to true, or the corresponding system property for your language is enabled. For example in Java: -Ddd.instrumentation.telemetry.enabled=true.

Bits Code remediation fails or produces incomplete fixes

Bits Code requires internet access to apply library upgrades when remediating SCA findings. If Bits Code fails to generate a fix or produces an incomplete patch, confirm that your internet access policy allows Bits Code to reach the package registries required for your language (for example, registry.npmjs.org for JavaScript or pypi.org for Python). See Configure internet access for more information.

Runtime Code Analysis (IAST)

Confirm IAST is enabled

Ensure the DD_IAST_ENABLED environment variable is set to true or the corresponding system property for your language is enabled.

If you have enabled Runtime Code Analysis (IAST) on your services, you can use the metric datadog.appsec.risk_management.iast.host_instance to check if it is running.

1. Go to Metrics > Summary in Datadog.
2. Search for the metric datadog.appsec.risk_management.iast.host_instance. If the metric doesn’t exist, then there are no services running Runtime Code Analysis (IAST). If the metric exists, the services are reported with the metric tags host and service.
3. Select the metric, and in the Tags section, search for service to see which services are running AAP.

If you are not seeing datadog.appsec.risk_management.iast.host_instance, check the in-app instructions to confirm that all steps for the initial setup are complete.

Runtime application security data is sent with APM traces. See APM troubleshooting to confirm APM setup and check for connection errors.

Issues with Python and Flask instrumentation

If you’re running a Flask application, ensure that you are calling the ddtrace_iast_flask_patch() function at the top level of the module and before calling app.run(). For more information, see the Flask integration documentation.

How committers are calculated for Code Security

A committer is an active Git contributor identified by the author_email field in Git commit metadata.

A committer is counted toward billing if they make at least three commits in a calendar month in repositories where Code Security is enabled.

Multiple commits with the same author_email count as one committer. By default, commits with different email addresses count separately. For GitHub repositories that meet the requirements in Deduplicating committers across email addresses, multiple emails belonging to the same GitHub user are counted as one committer.

How email addresses are counted as committers

Committers are identified based on the normalized author_email value in Git commit metadata.

Commits finalized by known GitHub system accounts such as [email protected] and [email protected] are not counted.

Commits using @users.noreply.github.com are not automatically excluded. These addresses are commonly used by developers who choose to hide their public email in GitHub. If the commit can be attributed to an individual developer, it is counted.

For clarification on how committers are counted in your environment, contact Datadog Support.

Deduplicating committers across email addresses

In some cases, a single developer’s commits can be split across multiple Git author emails. For example, a developer might set a different email with git config user.email in different repositories. If more than one of those emails passes the three-commit billing threshold, each counts as a separate committer.

For repositories hosted on GitHub, Datadog can map each Git author email to the underlying GitHub user so that the developer is counted once, even when they push under different emails. This requires a Datadog GitHub App installed on the affected repositories with the Contents: Read permission.

This mapping is available for GitHub repositories only. Repositories hosted on GitLab, Azure DevOps, or Bitbucket are not deduplicated.

If your committer count looks higher than expected for GitHub repositories, check that the Datadog GitHub App is installed on those repositories with the Contents: Read permission. You can review your installation from the GitHub integration tile.

Disabling Code Security capabilities

Disabling static repository scanning

To disable scanning Static Code Analysis (SAST) or static Software Composition Analysis:

• If you are scanning your repositories through Datadog-hosted scanning, navigate to Code Security Setup, click Enable scanning for your repositories, and disable the toggles previously enabled for scanning either all connected repositories or each repository.
• If you are scanning source code repositories through your CI pipelines, remove the relevant job(s) from your CI pipelines.

Disabling runtime SCA on your services

SCA can be enabled on your running services using one of the following two methods:

• From the Datadog UI.
• Manually, using the DD_APPSEC_SCA_ENABLED environment variable.

To disable SCA, you must use the same method you used to enable SCA.

Disabling Runtime Code Analysis (IAST)

To disable IAST, remove the DD_IAST_ENABLED=true environment variable from your application configuration or set it to false as DD_IAST_ENABLED=false, and restart your service.