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:

Use schema-version: v1.5 for all new configurations. It supports the same products as v1.4 and adds Secret Scanning. Version v1.4 added per-rule arguments for IaC rules, and v1.3 added 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 and Secret Scanning Configuration for secrets-specific fields.

The following example shows the top-level structure:

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

The sast, sca, iac, and secrets sections are optional. Any configuration location, including the org level, repository level, or repository file, can include one or more sections. The sast section also controls AI-native SAST rulesets for Datadog-hosted scans. The secrets section controls which files are scanned for secrets; the rules themselves are configured in Datadog. For the full schema for each section, see Static Code Analysis (SAST) Configuration, Software Composition Analysis (SCA) Configuration, Infrastructure as Code (IaC) Security Configuration, and Secret Scanning Configuration. The SAST page also lists the AI-native SAST ruleset names.

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

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

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:

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.4
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.4
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.4
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

Additional helpful documentation, links, and articles:

Static Code Analysis (SAST) ConfigurationDOCUMENTATION Software Composition Analysis (SCA) ConfigurationDOCUMENTATION Infrastructure as Code (IaC) Security ConfigurationDOCUMENTATION Secret Scanning ConfigurationDOCUMENTATION