summaryrefslogtreecommitdiff
path: root/doc/user/application_security/sast/customize_rulesets.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/application_security/sast/customize_rulesets.md')
-rw-r--r--doc/user/application_security/sast/customize_rulesets.md15
1 files changed, 7 insertions, 8 deletions
diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md
index aec7158d2e4..d070883df9a 100644
--- a/doc/user/application_security/sast/customize_rulesets.md
+++ b/doc/user/application_security/sast/customize_rulesets.md
@@ -23,7 +23,7 @@ repository being scanned. There are two kinds of customization:
## Disable predefined rules
-You can disable predefined rules for any SAST analyzer. Disabled rules won't appear
+You can disable predefined rules for any SAST analyzer. Disabled rules don't appear
on the [Pipeline Security](../index.md#view-security-scan-information-in-the-pipeline-security-tab)
tab or the [Vulnerability Report](../index.md#view-security-scan-information-in-the-vulnerability-report).
@@ -103,7 +103,7 @@ differ based on the kind of configuration you're making.
| `[[$analyzer.ruleset]]` | Predefined rules | Defines modifications to an existing rule. |
| `interpolate` | All | If set to `true`, you can use `$VAR` in the configuration to evaluate environment variables. Use this feature with caution, so you don't leak secrets or tokens. (Default: `false`) |
| `description` | Passthroughs | Description of the custom ruleset. |
-| `targetdir` | Passthroughs | The directory where the final configuration should be persisted. If empty, a directory with a random name is created. The directory can contain up to 100MB of files. |
+| `targetdir` | Passthroughs | The directory where the final configuration should be persisted. If empty, a directory with a random name is created. The directory can contain up to 100 MB of files. |
| `validate` | Passthroughs | If set to `true`, the content of each passthrough is validated. The validation works for `yaml`, `xml`, `json` and `toml` content. The proper validator is identified based on the extension used in the `target` parameter of the `[[$analyzer.passthrough]]` section. (Default: `false`) |
| `timeout` | Passthroughs | The maximum time to spend to evaluate the passthrough chain, before timing out. The timeout cannot exceed 300 seconds. (Default: 60) |
@@ -249,13 +249,13 @@ a higher precedence and can overwrite or append to data yielded by previous
passthroughs (depending on the `mode`). This is useful for cases where you need
to use or modify an existing configuration.
-The amount of data generated by a single passthrough is limited to 1MB.
+The amount of data generated by a single passthrough is limited to 1 MB.
| Setting | Applies to | Description |
| ------- | ---------- | ----------- |
| `type` | All | One of `file`, `raw`, `git` or `url`. |
| `target` | All | The target file to contain the data written by the passthrough evaluation. If empty, a random filename is used. |
-| `mode` | All | If `overwrite`, the `target` file is overwritten. If `append`, new content is appended to the `target` file. Note that the `git` type only supports `overwrite`. (Default: `overwrite`) |
+| `mode` | All | If `overwrite`, the `target` file is overwritten. If `append`, new content is appended to the `target` file. The `git` type only supports `overwrite`. (Default: `overwrite`) |
| `ref` | `type = "git"` | Contains the name of the branch or the SHA to pull. When using a branch name, specify it in the form `refs/heads/<branch>`, not `refs/remotes/<remote_name>/<branch>`. |
| `subdir` | `type = "git"` | Used to select a subdirectory of the Git repository as the configuration source. |
| `value` | All | For the `file`, `url`, and `git` types, defines the location of the file or Git repository. For the `raw` type, contains the inline configuration. |
@@ -273,7 +273,7 @@ The amount of data generated by a single passthrough is limited to 1MB.
WARNING:
When using the `raw` passthrough with a YAML snippet, it's recommended to format all indentation
in the `sast-ruleset.toml` file as spaces. The YAML specification mandates spaces over tabs, and the
-analyzer will fail to parse your custom ruleset unless the indentation is represented accordingly.
+analyzer fails to parse your custom ruleset unless the indentation is represented accordingly.
## Examples
@@ -317,8 +317,7 @@ With the following custom ruleset configuration, the following rules are omitted
### Override predefined rules of SAST analyzers
With the following custom ruleset configuration, vulnerabilities found with
-`semgrep` with a type `CWE` and a value `322` will have their severity
-overridden to `Critical`.
+`semgrep` with a type `CWE` and a value `322` have their severity overridden to `Critical`.
```toml
[semgrep]
@@ -416,7 +415,7 @@ Different passthrough types are demonstrated in this example:
- The `sast-rules` entry has a higher precedence because it appears later in
the configuration.
- If there's a filename collision between the two checkouts, files
- from the `sast-rules` repository will overwrite files from the
+ from the `sast-rules` repository overwrite files from the
`myrules` repository.
- A `raw` passthrough, which writes its `value` to `/sgrules/insecure.yml`.
- A `url` passthrough, which fetches a configuration hosted at a URL and