Static Code Analysis (SAST) Configuration

By default, Datadog Static Code Analysis (SAST) scans your repositories with Datadog’s default rulesets for each programming language. You can customize which rulesets and rules run, along with severities, paths, and other parameters. Configure these settings under the sast key in the Code Security configuration, either in Datadog or in a code-security.datadog.yaml file.

For information on configuration locations, precedence, and merging, see Code Security Configuration Reference.

Default rulesets

By default, Datadog enables the default rulesets for your repository’s programming languages (use-default-rulesets: true). To modify the enabled rulesets:

• Add rulesets: List them under use-rulesets
• Disable specific rulesets: List them under ignore-rulesets
• Disable all default rulesets: Set use-default-rulesets: false, then list the desired rulesets under use-rulesets

For the full list of default rulesets, see Static Code Analysis (SAST) Rules.

Configuration format

The following configuration format applies to all configuration locations: org-level, repository-level, and repository-level (file).

The configuration file must begin with a supported schema-version (v1.0, v1.1, or v1.2), followed by a sast key containing the analysis configuration, structured as shown below:

schema-version:v1.0sast:use-default-rulesets:trueuse-rulesets:- ruleset-nameignore-rulesets:# Always ignore these rulesets (even if it is a default ruleset or listed in `use-rulesets`)- ignored-ruleset-nameruleset-configs:ruleset-name:# Only apply this ruleset to the following paths/filesonly-paths:- "path/example"- "**/*.file"# Do not apply this ruleset in the following paths/filesignore-paths:- "path/example/directory"- "**/config.file"rule-configs:rule-name:# Only apply this rule to the following paths/filesonly-paths:- "path/example"- "**/*.file"# Do not apply this rule to the following paths/filesignore-paths:- "path/example/directory"- "**/config.file"arguments:# Set the rule's argument to value.argument-name:valueseverity:ERRORcategory:CODE_STYLErule-name:arguments:# Set different argument values in different subtreesargument-name:# Set the rule's argument to value_1 by default (root path of the repo)/:value_1# Set the rule's argument to value_2 for specific pathspath/example:value_2global-config:# Only analyze the following paths/filesonly-paths:- "path/example"- "**/*.file"# Do not analyze the following paths/filesignore-paths:- "path/example/directory"- "**/config.file"use-gitignore:trueignore-generated-files:truemax-file-size-kb:200

The sast key supports the following fields:

Ruleset configuration

Each entry in the ruleset-configs map configures a specific ruleset. A ruleset does not need to be listed in use-rulesets for its configuration to apply; the configuration is used whenever the ruleset is enabled, including through use-default-rulesets.

Rule configuration

Each entry in a ruleset’s rule-configs map configures a specific rule:

Argument and severity configuration

Arguments and severity can be defined in one of two formats:

1. Single value: Applies to the whole repository.

   arguments:argument-name:valueseverity:ERROR

2. Per-path mapping: Different values for different subtrees. The longest matching path prefix applies. Use / as a catch-all default.

   arguments:argument-name:/:value_defaultpath/example:value_specificseverity:/:WARNINGpath/example:ERROR

   Key	Type	Description	Default
   /	Any	The default value when no specific path is matched.	None
   specific path	Any	The value for files matching the specified path or glob pattern.	None

The category field takes a single string value for the whole repository.

Global configuration

The global-config object controls repository-wide settings:

Example configuration:

schema-version:v1.0sast:use-default-rulesets:falseuse-rulesets:- python-best-practices- python-security- python-code-style- python-inclusive- python-django- custom-python-rulesetruleset-configs:python-code-style:rule-configs:max-function-lines:# Do not apply the rule max-function-lines to the following filesignore-paths:- "src/main/util/process.py"- "src/main/util/datetime.py"arguments:# Set the max-function-lines rule's threshold to 150 linesmax-lines:150# Override this rule's severityseverity:NOTICEmax-class-lines:arguments:# Set different thresholds for the max-class-lines rule in different subtreesmax-lines:# Set the rule's threshold to 200 lines by default (root path of the repo)/:200# Set the rule's threshold to 100 lines in src/main/backendsrc/main/backend:100# Override this rule's severity with different values in different subtreesseverity:# Set the rule's severity to NOTICE by default/:NOTICE# Set the rule's severity to NONE in tests/tests:NONEpython-django:# Only apply the python-django ruleset to the following pathsonly-paths:- "src/main/backend"- "src/main/django"# Do not apply the python-django ruleset in files matching the following patternignore-paths:- "src/main/backend/util/*.py"global-config:# Only analyze source filesonly-paths:- "src/main"- "src/tests"- "**/*.py"# Do not analyze third-party filesignore-paths:- "lib/third_party"

Legacy configuration

Datadog Static Code Analysis (SAST) previously used a different configuration file (static-analysis.datadog.yml) and schema. This schema is deprecated and does not receive new updates, but it is documented in the datadog-static-analyzer repository.

If both files are present, code-security.datadog.yaml takes precedence over static-analysis.datadog.yml.

Ignoring violations

Ignore for a repository

Add a rule configuration in your code-security.datadog.yaml file. The following example ignores the rule javascript-express/reduce-server-fingerprinting for all directories.

schema-version:v1.0sast:ruleset-configs:javascript-express:rule-configs:reduce-server-fingerprinting:ignore-paths:- "**"

Ignore for a file or directory

Add a rule configuration in your code-security.datadog.yaml file. The following example ignores the rule javascript-express/reduce-server-fingerprinting for a specific file. For more information on how to ignore by path, see Customize your configuration.

schema-version:v1.0sast:ruleset-configs:javascript-express:rule-configs:reduce-server-fingerprinting:ignore-paths:- "ad-server/src/app.js"

Ignore for a specific instance

To ignore a specific instance of a violation, comment no-dd-sa above the line of code. Violations suppressed with no-dd-sa are shown as suppressed, rather than omitted entirely, so you can search and audit them.

On the Repositories page, suppressed violations appear with is_suppressed: true. In the Vulnerabilities explorer, they appear with status: muted and workflow.mute.reason: muted_in_code.

For example, in the following Python code snippet, the line foo = 1 would be suppressed in Static Code Analysis scans.

#no-dd-sa
foo = 1
bar = 2

You can also use no-dd-sa to only suppress a particular rule, rather than suppressing all rules. To do so, specify the name of the rule you wish to suppress in place of <rule-name> using this template:

no-dd-sa:<rule-name>

For example, in the following JavaScript code snippet, the line my_foo = 1 is suppressed only for the javascript-code-style/assignment-name rule, but all other rules still analyze it.

// no-dd-sa:javascript-code-style/assignment-name
my_foo = 1
myBar = 2

Request a personalized demo