Overview

Datadog Code Security helps you secure and maintain your applications’ first-party code and open source libraries from development to production.

It offers a suite of tools to help you secure your code throughout the software development lifecycle:

• Static Code Analysis (SAST) uses a Static Application Security Testing method to scan your repositories for security and quality issues in first-party code, providing suggested fixes to prevent these issues from reaching production.
• Software Composition Analysis (SCA) detects vulnerable open source libraries present in your repositories and affecting your services at runtime, helping you secure and maintain your software supply chain.
• Runtime Code Analysis (IAST) uses an Interactive Application Security Testing method to detect vulnerabilities affecting your services at runtime.

Set up Code Security

Open source libraries

Datadog Software Composition Analysis detects library vulnerabilities and catalogs dependencies within your codebase and running services.

See Software Composition Analysis to set up static and/or runtime library vulnerability detection.

First-party code

Developer tool integrations

Enable pull request comments

Datadog can act as an automatic code reviewer to flag vulnerabilities and quality violations in GitHub pull requests. For more information, see GitHub Pull Requests.

Install IDE integrations

Install the Datadog IDE plugins to run Static Code Analysis (SAST) scans locally and see results directly in your code editor. You can detect and fix problems such as security vulnerabilities, maintainability issues, or bugs in your code before you commit your changes.

To start running code scans in your IDE, see the respective documentation for your code editor of choice.

Customize your repository settings

In Code Security Settings, you can manage which repositories have PR comments enabled, as well as customize the configuration of which Static Code Analysis (SAST) rules are applied across or within repositories. For all the default rules provided by Datadog, see the SAST Rules.

Set up PR Gates

Datadog provides PR Gates as a platform capability to help you maintain and enforce security and quality standards for changes introduced to your codebase. For more information, see PR Gate setup.

Prioritize vulnerabilities with runtime context

Code Security offers vulnerability-centric views of all library and code vulnerabilities detected from both static repository scanning and runtime service detection.

Explore vulnerabilities

For library vulnerabilities, each row in the table represents a specific vulnerability affecting a library version. Based on if you have static or runtime detection enabled, the Detected In column displays the specific repositories and/or services affected by this vulnerability.

In the side panel for a single library vulnerability in SCA, in addition to details about the vulnerability, Datadog shows:

• A Severity breakdown of the highest severity instance of this vulnerability seen across your repositories and your services. For each detected location of the vulnerability in your repositories and/or services, Datadog adjusts the base severity score of the vulnerability based on environmental factors. To learn more, see Datadog severity score.
• A Repositories table of all instances where the vulnerability was detected in your repositories. For each instance, Datadog shows whether the dependency is classified as direct or transitive, the remediation status of the vulnerability, as well as specific remediation steps.
• An Impacted Services table of all running services affected by this library vulnerability. A service is affected by a library vulnerability if the library was loaded at runtime and detected by Datadog’s application tracing libraries.

Severities are scored by the following:

Explore results per repository

Code Security also offers repository-centric views of static scan results, supporting granular filtering across all branches and commits for scanned repositories.

Click on a repository on the Repositories page to access a more detailed view where you can customize the search query by branch (with the default branch appearing first) and by commit (starting with the latest).

You can use the following out-of-the-box facets to create a search query for identifying and resolving poor coding practices in the Code Quality tab or security risks in the Code Vulnerabilities tab.

Facet Name	Description
Result Status	Filters results based on the completion status of the analysis.
Rule ID	Specific rules that triggered the findings.
Tool Name	Determines which tools contributed to the analysis.
CWE (Common Weakness Enumeration)	Filters findings by recognized vulnerability categories.
Has Fixes	Filters issues for which suggested fixes are available.
Result Message	Contains concise descriptions or messages associated with the findings.
Rule Description	Contains the rationale behind each rule.
Source File	Contains the files where issues were detected.
Tool Version	Filters results by the version of the tools used.

You can access suggested fixes directly from the results to address security vulnerabilities or improve code quality practices.

You can use the following out-of-the-box facets to create a search query for identifying and addressing security risks in third-party libraries in the Library Vulnerabilities tab or reviewing your library inventory in the Library Catalog tab.

Facet Name	Description
Dependency Name	Identifies the libraries by name.
Dependency Version	Filters by specific versions of libraries.
Language	Sorts libraries by the programming language.
Score	Sorts the risk or quality score of the dependencies.
Severity	Filters vulnerabilities based on their severity rating.
Platform	Distinguishes libraries by the platform they are intended for.

You can access vulnerability reports and locate the source files where the vulnerability was discovered in your projects, along with information about the file’s code owners.

Notify, remediate, and report

Code Security helps you set up workflows to track and manage remediation of findings:

• Set up notification rules to notify your team(s) of new findings via Slack, Jira, email, and more
• Track vulnerabilities by service and team in the Code Security Summary page.

Link findings to Datadog services and teams

Datadog associates code and library scan results with Datadog services and teams to automatically route findings to the appropriate owners. This enables service-level visibility, ownership-based workflows, and faster remediation.

To determine the service where a vulnerability belongs, Datadog evaluates several mapping mechanisms in the order listed in this section.

Each vulnerability is mapped with one method only: if a mapping mechanism succeeds for a particular finding, Datadog does not attempt the remaining mechanisms for that finding.

Mapping using the Software Catalog (recommended)

Services in the Software Catalog identify their codebase content using the codeLocations field. This field is available in the Software Catalog [schema version v3][101] and allows a service to specify:

• a repository URL

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git

• one or more code paths inside that repository

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**

If you want all the files in a repository to be associated with a service, you can use the glob ** as follows:

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

The schema for this field is described in the [Software Catalog entity model][102].

Datadog goes through all Software Catalog definitions and checks whether the finding’s file path matches. For a finding to be mapped to a service through codeLocations, it must contain a file path.

Some findings might not contain a file path. In those cases, Datadog cannot evaluate codeLocations for that finding, and this mechanism is skipped.

Example (v3 schema)

apiVersion: v3
kind: service
metadata:
  name: billing-service
  owner: billing-team
datadog:
  codeLocations:
    - repositoryURL: https://github.com/org/myrepo.git
      paths:
        - path/to/service/code/**
    - repositoryURL: https://github.com/org/billing-service.git
      paths:
        - "**"

SAST finding

If a vulnerability appeared in github.com/org/myrepo at /src/billing/models/payment.py, then using the codeLocations for billing-service Datadog would add billing-service as an owning service. If your service defines an owner (see above), then Datadog links that team to the finding too. In this case, the finding would be linked to the billing-team.

SCA finding

If a library was declared in github.com/org/myrepo at /go.mod, then Datadog would not match it to billing-service.

Instead, if it was declared in github.com/org/billing-service at /go.mod, then Datadog would match it to billing-service due to the “**” catch-all glob. Consequently, Datadog would link the finding to the billing-team.

When the Software Catalog cannot determine the service

If the Software Catalog does not provide a match, either because the finding’s file path does not match any codeLocations, or because the service uses the v2.x schema, Datadog evaluates whether Error Tracking can identify the service associated with the code. Datadog uses only the last 30 days of Error Tracking data due to product [data-retention limits][103].

When Error Tracking processes stack traces, the traces often include file paths. For example, if an error occurs in: /foo/bar/baz.py, Datadog inspects the directory: /foo/bar. Datadog then checks whether the finding’s file path resides under that directory.

If the finding file is under the same directory:

• Datadog treats this as a strong indication that the vulnerability belongs to the same service.
• The finding inherits the service and team associated with that error in Error Tracking.

If this mapping succeeds, Datadog stops here.

Service inference from file paths or repository names

When neither of the above strategies can determine the service, Datadog inspects naming patterns in the repository and file paths.

Datadog evaluates whether:

• The file path contains identifiers matching a known service.
• The repository name corresponds to a service name.

When using the finding’s file path, Datadog performs a reverse search on each path segment until it finds a matching service or exhausts all options.

For example, if a finding occurs in github.com/org/checkout-service at /foo/bar/baz/main.go, Datadog takes the last path segment, main, and sees if any Software Catalog service uses that name. If there is a match, the finding is attributed to that service. If not, the process continues with baz, then bar, and so on.

When all options have been tried, Datadog checks whether the repository name, checkout-service, matches a Software Catalog service name. If no match is found, Datadog is unsuccessful at linking your finding using Software Catalog.

This mechanism ensures that findings receive meaningful service attribution when no explicit metadata exists.

Link findings to teams through Code Owners

If Datadog is able to link your finding to a service using the above strategies, then the team that owns that service (if defined) is associated with that finding automatically.

Regardless of whether Datadog successfully links a finding to a service (and a Datadog team), Datadog uses the CODEOWNERS information from your finding’s repository to link Datadog and GitHub teams to your findings.