Ignore rules

You may want to suppress “noisy,” low-value Code Security findings. These may be findings you have consistently resolved as “False Positive” (not actual security issues) or “Accepted Risk” (genuine issues, but low severity and not worth fixing).

To do so, you can add ignore rules for issues or files. Your ignore rules will automatically suppress future findings that match the rule. If you add ignore rules, please let us know why! We want to keep improving our Code Security product and boost signal-to-noise for all of our customers.

A word of caution: since ignore rules may hide genuine future issues, we suggest minimizing their number and scope. However, you have the final say.

Choosing the right mechanism

Ignore rules are one of several ways to deal with an unwanted finding, and not always the best one:

• If you’ve investigated a handful of findings, resolve them as False positive or Accepted risk instead. The decision is recorded per finding, which is better for your audit trail.
• If a rule is consistently wrong for a whole issue or repository, add an ignore rule on the platform.
• If you want the suppression to live in the repository itself, use a dotfile committed to its root.
• If low-confidence findings are drowning you across the board, lower the scanner sensitivity instead of ignoring rules one by one.

The scanners honor their native inline suppression comments (// nosemgrep, #nosec, gitleaks:allow), but we recommend the mechanisms above instead. An inline comment leaves no trace on the platform, while a resolution or ignore rule records who suppressed what, and why.

Ignore rules on the platform

To ignore an issue from the UI, open the issue and click the Ignore button. All of the issue’s findings must be resolved or suppressed first, so each one gets an explicit decision before the issue is silenced wholesale. You’ll be asked for a justification and which repositories the rule covers (one, several, or all).

Existing rules are managed under Code security → Configure → Ignore rules, where you can edit, temporarily disable, or delete them. Findings suppressed by a rule stay visible under the Suppressed filter, labeled with the reason.

Dotfile ignore rules

You can suppress issues in a single repository by adding an ignore rules dotfile. There are three formats to choose from: JSON (recommended), YAML, or .gitignore style.

When Code Security scans your repository, it looks for ignore rules in the following files at the root level:

• .oneleetignore.json
• .oneleetignore.yaml or .oneleetignore.yml
• .oneleetignore

If multiple dotfiles are present, Code Security will OR together the rules they define.

.oneleetignore.json

We recommend this JSON format because it’s both simple and feature-complete.

Start from the following template:

{
  "$schema": "https://docs.oneleet.com/code-security/oneleetignore.schema.json",
  "version": 1,
  "ignores": [
    <your-ignore-rules>
  ]
}

If you use VSCode or Cursor, enable the setting json.schemaDownload.enable and you should be able to code complete to victory.

For example, the following rule ignores two issues for .js files under the /examples directory:

{
  "$schema": "https://docs.oneleet.com/code-security/oneleetignore.schema.json",
  "version": 1,
  "ignores": [
    {
      "ruleIds": [
        "javascript.language.eval.dynamic-code",
        "javascript.react.dangerouslysetinnerhtml"
      ],
      "pathPatterns": ["/examples/**/*.js"],
      "reason": "Example code only"
    }
  ]
}

At least one of ruleIds and pathPatterns is required. The optional reason message ("Example code only") documents why you’ve suppressed this class of findings.

.oneleetignore.yaml

The YAML format is the same as the JSON format, but with YAML syntax. Start from the following template:

$schema: https://docs.oneleet.com/code-security/oneleetignore.schema.json
version: 1
ignores:
  - <your-ignore-rule>
  - <your-ignore-rule>
  - ...

Here’s the JSON example translated to YAML:

$schema: https://docs.oneleet.com/code-security/oneleetignore.schema.json
version: 1
ignores:
  - ruleIds:
      - javascript.language.eval.dynamic-code
      - javascript.react.dangerouslysetinnerhtml
    pathPatterns:
      - /examples/**/*.js
    reason: Example code only

.oneleetignore

This follows the .gitignore format. Unlike .gitignore, this file must be at the root of the repository.

This format is a blunt instrument. Files matching the glob patterns will be exempt from all ruleIds, and reason messages are not supported. If you need more granularity, consider using the JSON or YAML format instead.

README.md
*.txt

# Comment
dir/
/.github/**/*.yml
/.github/**/*.yaml

.gitleaksignore

To suppress Gitleaks findings, you can also use a standard .gitleaksignore file at the root of your repository:

# file:rule-id:start-line
src/config/database.yml:generic-api-key:12

# Fingerprints generated by `gitleaks git` start with a commit hash,
# but the Oneleet code security scanner will disregard the hash part.
f2ac7a8f5992e0a8c17d5238fbb2f30ec72ead43:src/config/database.yml:generic-api-key:12