Code Security Configuration Reference

Ce produit n'est pas pris en charge par le site Datadog que vous avez sélectionné. ().
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.

Datadog Code Security can be configured in Datadog, in a file at the root of your repository, or in both locations.

Configuration schema

The configuration file must begin with a schema-version key, followed by top-level keys for each product you want to configure. Use the schema version that matches the products you want to configure:

Schema versionSupported products
v1.0SAST
v1.1SAST, SCA
v1.2SAST, SCA, IaC Security
v1.3SAST, SCA, IaC Security

Use schema-version: v1.3 for all new configurations. It supports the same products as v1.2 and adds IaC configuration options such as per-rule path scoping, per-rule severity overrides, and platform filters. See Infrastructure as Code (IaC) Security Configuration for IaC-specific fields.

The following example shows the top-level structure:

schema-version: v1.3
sast:
  # Static Code Analysis (SAST) configuration
sca:
  # Software Composition Analysis (SCA) configuration
iac:
  # Infrastructure as Code (IaC) Security configuration

The sast, sca, and iac sections are optional. Any configuration location, including the org level, repository level, or repository file, can include one or more sections. For the full schema for each section, see Static Code Analysis (SAST) Configuration, Software Composition Analysis (SCA) Configuration, and Infrastructure as Code (IaC) Security Configuration.

Where to define configurations

There are three levels of configuration:

  • Org-level configuration (Datadog)
  • Repository-level configuration (Datadog)
  • Repository-level configuration (repo file)

All three locations use the same YAML schema and are merged in order (see How configurations merge).

Org-level configuration

The Datadog Code Security org-level configuration editor.

Org-level configurations apply to all repositories in your org. Use org-level configurations to define org-wide rules and specify global paths or files to ignore.

Repository-level configuration

The Datadog Code Security repository-level configuration editor.

Repository-level configurations apply only to the selected repository and take precedence over org-level configurations. They are merged with the org configuration, with repository settings overriding org defaults. Use repository-level configurations to define repository-specific overrides or add rules that apply only to that repository.

Repository-level configuration (file)

The code-security.datadog.yaml file stores configuration at the root of a repository. It takes precedence over org-level and repository-level configurations defined in Datadog.

How configurations merge

Configurations are merged in the following order, from lowest to highest precedence:

  1. Org-level
  2. Repo-level
  3. Repo-level file (code-security.datadog.yaml)

For each field in a configuration, merge behavior depends on the field type:

Field typeMerge behaviorExample fields
ListsConcatenated, with duplicates removeduse-rulesets, ignore-rulesets, ignore-rules, ignore-paths, only-paths, ignore-platforms, only-platforms
Scalar values (strings, numbers, booleans)The value from the highest-precedence configuration is useduse-default-rulesets, use-gitignore, max-file-size-kb, category
MapsRecursively mergedruleset-configs, rule-configs, arguments

For the full list of fields, see Static Code Analysis (SAST) Configuration, Software Composition Analysis (SCA) Configuration, and Infrastructure as Code (IaC) Security Configuration.

The following example shows how configurations are merged:

Org-level

schema-version: v1.3
sast:
  use-default-rulesets: false
  use-rulesets:
    - A
  ruleset-configs:
    A:
      rule-configs:
        foo:
          ignore-paths:
            - "path/to/ignore"
          arguments:
            maxCount: 10
sca:
  ignore-paths:
    - "vendor/"
iac:
  ignore-rules:
    - A
  global-config:
    ignore-paths:
      - "examples/"

Repo-level

schema-version: v1.3
sast:
  use-rulesets:
    - B
  ignore-rulesets:
    - C
  ruleset-configs:
    A:
      rule-configs:
        foo:
          arguments:
            maxCount: 22
        bar:
          only-paths:
            - "src"
sca:
  ignore-paths:
    - "third_party/"
iac:
  ignore-rules:
    - B
  global-config:
    ignore-paths:
      - "generated/"

Merged result

schema-version: v1.3
sast:
  use-default-rulesets: false
  use-rulesets:
    - A
    - B
  ignore-rulesets:
    - C
  ruleset-configs:
    A:
      rule-configs:
        foo:
          ignore-paths:
            - "path/to/ignore"
          arguments:
            maxCount: 22
        bar:
          only-paths:
            - "src"
sca:
  ignore-paths:
    - "vendor/"
    - "third_party/"
iac:
  ignore-rules:
    - A
    - B
  global-config:
    ignore-paths:
      - "examples/"
      - "generated/"

The example demonstrates each merge rule from the table above:

  • Lists concatenate: use-rulesets merges to [A, B]; the SCA ignore-paths merges to ["vendor/", "third_party/"]; the IaC ignore-rules merges to [A, B].
  • Scalars use the highest-precedence value: maxCount: 22 (repo-level) overrides maxCount: 10 (org-level).
  • Maps merge recursively: The foo rule config keeps ignore-paths from the org level while applying maxCount: 22 from the repo level. New entries like bar are added from the repo level.

Further reading