Overview

SCA can scan dependency management files in your repositories to statically detect open source libraries used in your codebase. SCA supports scanning for libraries in the following languages and lockfiles below:

You can set up Datadog Static Software Composition Analysis (SCA) in-app through Security > Code Security.

1. Navigate to the Security Settings page.
2. In Activate scanning for your repositories, click Manage Repositories.
3. Select where to run static SCA scans.
4. Complete the remaining steps for your provider.

Select where to run static SCA scans

Scan with Datadog-hosted scanning

For GitHub repositories, you can run Datadog SCA scans directly on Datadog’s infrastructure. To get started, navigate to the Code Security page.

Scan in CI pipelines

First, configure your Datadog API and application keys by adding DD_APP_KEY and DD_API_KEY as secrets. Please ensure your Datadog application key has the code_analysis_read scope.

Next, run SCA by following instructions for your chosen CI provider below.

GitHub Actions

SCA can run as a job in your GitHub Actions workflows. The action provided below invokes Datadog osv-scanner, our recommended SBOM generator, on your codebase and uploads the results into Datadog.

Add the following code snippet in .github/workflows/datadog-sca.yml. Make sure to replace the dd_site attribute with the Datadog site you are using.

on: [push]

name: Datadog Software Composition Analysis

jobs:
  software-composition-analysis:
    runs-on: ubuntu-latest
    name: Datadog SBOM Generation and Upload
    steps:
    - name: Checkout
      uses: actions/checkout@v3
    - name: Check imported libraries are secure and compliant
      id: datadog-software-composition-analysis
      uses: DataDog/datadog-sca-github-action@main
      with:
        dd_api_key: ${{ secrets.DD_API_KEY }}
        dd_app_key: ${{ secrets.DD_APP_KEY }}
        dd_site: "datadoghq.com"

Related GitHub Actions

Datadog Static Code Analysis (SAST) analyzes your first-party code. Static Code Analysis can be set up using the datadog-static-analyzer-github-action GitHub action.

Generic CI Providers

If you don’t use GitHub Actions, you can run the datadog-ci CLI directly in your CI pipeline platform and upload your SBOM to Datadog.

If you are running Code Security on a non-GitHub repository, ensure that the first scan is ran on your default branch (for example, a branch name like master, main, prod, or production). After you commit on your default branch, non-default branches are analyzed. You can always configure your default branch in-app under Repository Settings.

Prerequisites:

• unzip
• Node.js 14 or later

Configure the following environment variables:

Provide the following inputs:

# Set the Datadog site to send information to
export DD_SITE=""

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

# Download the latest Datadog OSV Scanner:
# https://github.com/DataDog/osv-scanner/releases
DATADOG_OSV_SCANNER_URL=https://github.com/DataDog/osv-scanner/releases/latest/download/osv-scanner_linux_amd64.zip

# Install OSV Scanner
mkdir /osv-scanner
curl -L -o /osv-scanner/osv-scanner.zip $DATADOG_OSV_SCANNER_URL
unzip /osv-scanner/osv-scanner.zip -d /osv-scanner
chmod 755 /osv-scanner/osv-scanner

# Run OSV Scanner and scan your dependencies
/osv-scanner/osv-scanner --skip-git -r --experimental-only-packages --format=cyclonedx-1-5 --paths-relative-to-scan-dir  --output=/tmp/sbom.json /path/to/repository

# Upload results to Datadog
datadog-ci sbom upload /tmp/sbom.json

Select your source code management provider

Datadog SCA supports all source code management providers, with native support for GitHub, GitLab, and Azure DevOps.

TODO

Upload third-party SBOM to Datadog

While Datadog preferred SBOM generator is our own osv-scanner fork, it is possible to ingest a third-party SBOM.

Our tooling supports the following SBOM standards:

• CycloneDX 1.4
• CycloneDX 1.5
• CycloneDX 1.6

When ingesting a third-party SBOM, ensure that the following constraints are met:

• The file checks the SBOM JSON schema
• SBOM components have the type library
• SBOM components have a valid purl attribute

Third-party SBOM files are uploaded to Datadog using the datadog-ci command. You can use the following command to upload your third-party SBOM. Ensure the environment variables DD_API_KEY, DD_APP_KEY and DD_SITE are set to your API key, APP key, and Datadog site, respectively.

datadog-ci sbom upload /path/to/third-party-sbom.json

Link results to Datadog services and teams

Link results to services

Datadog associates static code and library scan results with relevant services by using the following mechanisms:

1. Identifying the code location associated with a service using the Software Catalog.
2. Detecting usage patterns of files within additional Datadog products.
3. Searching for the service name in the file path or repository.

If one method succeeds, no further mapping attempts are made. Each mapping method is detailed below.

Identifying the code location in the Software Catalog

The schema version v3 and later of the Software Catalog allows you to add the mapping of your code location for your service. The codeLocations section specifies the location of the repository containing the code and its associated paths.

The paths attribute is a list of globs that should match paths in the repository.

apiVersion: v3
kind: service
metadata:
  name: my-service
datadog:
  codeLocations:
    - repositoryURL: https://github.com/myorganization/myrepo.git
      paths:
        - path/to/service/code/**

Detecting file usage patterns

Datadog detects file usage in additional products such as Error Tracking and associate files with the runtime service. For example, if a service called foo has a log entry or a stack trace containing a file with a path /modules/foo/bar.py, it associates files /modules/foo/bar.py to service foo.

Detecting service name in paths and repository names

Datadog detects service names in paths and repository names, and associates the file with the service if a match is found.

For a repository match, if there is a service called myservice and the repository URL is https://github.com/myorganization/myservice.git, then, it associates myservice to all files in the repository.

If no repository match is found, Datadog attempts to find a match in the path of the file. If there is a service named myservice, and the path is /path/to/myservice/foo.py, the file is associated with myservice because the service name is part of the path. If two services are present in the path, the service name closest to the filename is selected.

Link results to teams

Datadog automatically associates the team attached to a service when a violation or vulnerability is detected. For example, if the file domains/ecommerce/apps/myservice/foo.py is associated with myservice, then the team myservice will be associated to any violation detected in this file.

If no services or teams are found, Datadog uses the CODEOWNERS file in your repository. The CODEOWNERS file determines which team owns a file in your Git provider.

Note: You must accurately map your Git provider teams to your Datadog teams for this feature to function properly.