For the complete documentation index, see llms.txt. This page is also available as Markdown.

Developer suppressions

Developer suppressions enable you to temporarily ignore specific scan findings that are known or acceptable in your code. You can apply a suppression inline in the code using inline comments or an annotation, or manage them from supported IDEs (see IDE integrations).

When added in code, a suppression comment is placed next to the relevant line. The scanner still creates the finding, but marks it as Suppressed rather than excluding it. This ensures that the finding remains visible for audit, while removing it from active remediation workflows.

You can also create policies that use developer suppressions as a condition. For more information, refer to Unified Application Security policies.

Use suppressions only for valid exceptions (for example, a false positive or an approved design decision), and include a clear justification. Scope each suppression to the minimal code element (line or block) and review them regularly to prevent technical debt.

Guidelines

  • Default branch behavior: Suppressions on the default branch apply to both pull request (PR) comments and CI/CD runs

  • Periodic scans: When a suppression is added to a PR, it will not take effect in the periodic scan until the PR is merged

  • Merging PRs: When a PR containing a suppression is merged into the default branch, the suppression specific to that asset is applied to the default branch. As a result, subsequent pull requests and periodic scans will no longer flag the suppressed issue

Suppressing checks

The general pattern for inline suppressions is:

#cortex:skip=<rule_id>:<suppression_comment>
  • rule_id : The ID of the specific check

  • suppression_comment: An explanation included in scan output

Examples

The following examples show how to add inline suppressions to ignore specific findings. Each suppression includes a check ID and an optional comment explaining the reason, such as a false positive or an approved deviation.

Note

The check IDs and rule names are placeholders for illustration purposes and do not correspond to actual checks.

Terraform

The following comment skips the APPSEC_AWS_20 check for the foo-bucket S3 resource. This check ensures that the S3 bucket is private. It is skipped here because the bucket is intentionally public.

CloudFormation

CloudFormation checks can be suppressed either with an inline comment next to the resource or using the resource’s Metadata section.

  • Option #1 Inline Comment

    The following comment skips the APPSEC_AWS_16 check for this RDS instance, with a comment explaining that encryption at rest is intentionally handled or not required.

  • Option #2 Metadata Section

    Suppresses a check using the CloudFormation Metadata section, with a reason provided.

Dockerfile

Comments can be added to any line in the Dockerfile.

The following comment skips specific Dockerfile checks using inline comments while providing a reason for each suppression.

Kubernetes

To suppress checks in Kubernetes manifests, annotate using the following format:

Secrets

Inline suppressions for secrets can be added before, after, or next to the infringing line.

Software Composition Analysis (SCA)

Inline suppressions allow you to ignore specific CVEs, license violations, or all CVEs for a specific package directly in dependency files. Each skip includes a check ID (or package identifier) and an optional reason for the suppression. The exact syntax depends on the package manager.

  • For Python (requirements.txt), .NET (Paket), Java/Kotlin (gradle.properties), Ruby (Gemfile)

    The skip comment can be added anywhere in the file.

  • For JavaScript (package.json, bower,json)

    • Skip comments can be placed in the metadata section of the non-lock file. When scanning with lock files (for example yarn.lock), the suppression applies to related violations.

    • Single skip comment alternative:

  • For Java (pom.xml), .NET (*.csproj)

    Skip comments can be placed anywhere in the file.

  • Go (go.mod), Java/Kotlin (build.gradle)

    Skip comments can be added anywhere in the file. For Go, a skip in go.mod also applies to go.sum. The following example is for go.mod.

Last updated

Was this helpful?