diff --git a/hugo/config/_default/menus/main.en.yaml b/hugo/config/_default/menus/main.en.yaml index 50014eeef3a..e10d1328662 100644 --- a/hugo/config/_default/menus/main.en.yaml +++ b/hugo/config/_default/menus/main.en.yaml @@ -8231,7 +8231,7 @@ menu: url: /security/code_security/secret_scanning/generic_ci_providers/ parent: sec_secret_scanning weight: 2 - - name: Rule Configuration + - name: Configuration identifier: sec_secret_scanning_configuration url: /security/code_security/secret_scanning/configuration/ parent: sec_secret_scanning diff --git a/hugo/content/en/security/code_security/guides/configuration.md b/hugo/content/en/security/code_security/guides/configuration.md index 88702e7434d..bf05e769f52 100644 --- a/hugo/content/en/security/code_security/guides/configuration.md +++ b/hugo/content/en/security/code_security/guides/configuration.md @@ -12,6 +12,9 @@ further_reading: - link: /security/code_security/iac_security/configuration/ tag: Documentation text: Infrastructure as Code (IaC) Security Configuration +- link: /security/code_security/secret_scanning/configuration/ + tag: Documentation + text: Secret Scanning Configuration --- Datadog Code Security can be configured in Datadog, in a file at the root of your repository, or in both locations. @@ -27,22 +30,25 @@ The configuration file must begin with a `schema-version` key, followed by top-l | `v1.2` | SAST, SCA, IaC Security | | `v1.3` | SAST, SCA, IaC Security | | `v1.4` | SAST, SCA, IaC Security | +| `v1.5` | SAST, SCA, IaC Security, Secret Scanning | -Use `schema-version: v1.4` for all new configurations. It supports the same products as `v1.3` and adds per-rule `arguments` for IaC rules. Version `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][3] for IaC-specific fields. +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][3] for IaC-specific fields and [Secret Scanning Configuration][4] for secrets-specific fields. The following example shows the top-level structure: ```yaml -schema-version: v1.4 +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`, and `iac` 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. For the full schema for each section and AI-native SAST ruleset names, see [Static Code Analysis (SAST) Configuration][1], [Software Composition Analysis (SCA) Configuration][2], and [Infrastructure as Code (IaC) Security Configuration][3]. +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][1], [Software Composition Analysis (SCA) Configuration][2], [Infrastructure as Code (IaC) Security Configuration][3], and [Secret Scanning Configuration][4]. The SAST page also lists the AI-native SAST ruleset names. ## Where to define configurations @@ -195,3 +201,4 @@ The example demonstrates each merge rule from the table above: [1]: /security/code_security/static_analysis/configuration/ [2]: /security/code_security/software_composition_analysis/configuration/ [3]: /security/code_security/iac_security/configuration/ +[4]: /security/code_security/secret_scanning/configuration/ diff --git a/hugo/content/en/security/code_security/secret_scanning/configuration.md b/hugo/content/en/security/code_security/secret_scanning/configuration.md index 835bf1ba327..11e82bcfdc3 100644 --- a/hugo/content/en/security/code_security/secret_scanning/configuration.md +++ b/hugo/content/en/security/code_security/secret_scanning/configuration.md @@ -1,11 +1,13 @@ --- -title: Rule Configuration +title: Configuration algolia: tags: ['static analysis', 'ci pipeline', 'SAST', 'secret scanning'] -description: Configure rules for Datadog Secret Scanning, including managed default rules and custom regex rules. +description: Configure Datadog Secret Scanning rules and the files that are scanned. --- By default, Datadog Secret Scanning scans enabled repositories with all [rules in the Secrets & Credentials category of Sensitive Data Scanner][1]. You can customize which rules run, modify default rules, and create custom rules on the [{{< ui >}}Code{{< /ui >}} configuration page][2] in SDS. + +The rules, scanning groups, and custom rules described on this page are configured in Datadog. A configuration file in your repository adds separate control over which files are scanned. See [File configuration](#file-configuration). ## Scanning groups There are two scanning groups that configure Secret Scanning rules. ### Managed scanning group @@ -44,6 +46,42 @@ Disable a rule by clicking the blue toggle on the right.
After a specific rule is disabled, existing findings from that rule are auto-closed in Secret Scanning on the next commit.
+## File configuration + +Rules are configured in Datadog as described in the [Configuring rules](#configuring-rules) section. Which files Secret Scanning reads is configured under the `secrets` key in the Code Security configuration. Define it in Datadog, or in a `code-security.datadog.yaml` file at the root of your repository. + +For information on configuration locations, precedence, and merging, see [Code Security Configuration Reference][4]. + +The configuration must begin with `schema-version: v1.5`, followed by a `secrets` key containing a `global-config` object. The `global-config` object controls repository-wide settings: + +| **Property** | **Type** | **Description** | **Default** | +| --- | --- | --- | --- | +| `only-paths` | Array | File paths or glob patterns. Only matching files are analyzed. | None | +| `ignore-paths` | Array | File paths or glob patterns to exclude. Matching files are not analyzed. | None | +| `use-gitignore` | Boolean | Whether to include entries from the `.gitignore` file in `ignore-paths`. | `true` | +| `ignore-generated-files` | Boolean | Whether to include common generated file patterns in `ignore-paths`. | `true` | +| `max-file-size-kb` | Number | Maximum file size (in kB) to analyze. Larger files are ignored. | `10240` | + +### Example configuration + +{{< code-block lang="yaml" >}} +schema-version: v1.5 +secrets: + global-config: + # Only analyze the following paths/files + only-paths: + - "src" + - "**/*.py" + # Do not analyze the following paths/files + ignore-paths: + - "tests" + - "**/*.lock" + use-gitignore: true + ignore-generated-files: true + max-file-size-kb: 10240 +{{< /code-block >}} + [1]: /security/sensitive_data_scanner/scanning_rules/library_rules/?category=Secrets+and+credentials [2]: https://app.datadoghq.com/sensitive-data-scanner/configuration/code [3]: /security/sensitive_data_scanner/scanning_rules/custom_rules/ +[4]: /security/code_security/guides/configuration/