Code Security Configuration Reference
This product is not supported for your selected
Datadog site. (
).
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、
お気軽にご連絡ください。
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 version | Supported products |
|---|
v1.0 | SAST |
v1.1 | SAST, SCA |
v1.2 | SAST, SCA, IaC Security |
v1.3 | SAST, 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
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:
- Org-level
- Repo-level
- Repo-level file (
code-security.datadog.yaml)
For each field in a configuration, merge behavior depends on the field type:
| Field type | Merge behavior | Example fields |
|---|
| Lists | Concatenated, with duplicates removed | use-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 used | use-default-rulesets, use-gitignore, max-file-size-kb, category |
| Maps | Recursively merged | ruleset-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