Inline Ignore Comments

Overview

The cybedefend-ignore directive lets you silence a specific SAST, IaC or CI/CD finding by adding a comment in your source code, on the flagged line or on the line directly above it. It is the right tool for confirmed false positives: the directive lives next to the code, is reviewed in pull requests, and keeps the finding silenced on every subsequent scan. It never silences a secret: see Secret Findings. A scoped directive names the rule it silences by its CybeDefend rule code, for example cybedefend-ignore[CD-IAC-0123]: <reason>. The detail of a SAST, IaC or CI/CD finding shows the code, and the dashboard copies a ready-to-paste directive for you. Use the .cybeignore exclusion file when you want to exclude whole files or directories. Use an inline comment when you want to exclude one precise line.

Supported Findings

The directive applies to SAST, IaC and CI/CD findings. Each rule has a code of the form CD-<TYPE>-<NNNN>, where the type matches the finding type:

Finding type	Rule code	Example
SAST	`CD-SAST-<NNNN>`	`CD-SAST-0042`
IaC	`CD-IAC-<NNNN>`	`CD-IAC-0123`
CI/CD	`CD-CICD-<NNNN>`	`CD-CICD-0007`

The number has four digits or more. The codes on this page are examples: always use the code shown on your finding.

SCA, container and AI-BOM findings are not attached to a source line and cannot be suppressed with an inline comment.

Secret Findings

A cybedefend-ignore directive never silences a secret finding, whether it is bare or scoped. On a line that also holds a secret, the directive still applies to the other findings of that line, never to the secret. Handle a secret finding this way instead:

The secret is	What to do
A false positive, such as a test fixture	Set the finding to Ignored in the dashboard, with a reason. To stop scanning a whole path, exclude it with `.cybeignore`: every finding in that path is hidden, including secrets committed there later.
Real	Rotate it, then use Mark as rotated on the finding.

Syntax

cybedefend-ignore[<code>]: <reason>
cybedefend-ignore[<code>,<code>]: <reason>
cybedefend-ignore: <reason>

Form	Effect
`cybedefend-ignore[CD-IAC-0123]`	Scoped ignore, recommended: silences only the findings of the listed rule. Findings of other rules on the same line stay visible
`cybedefend-ignore[CD-IAC-0123,CD-IAC-0456]`	Scoped to several rules: separate the codes with commas. Spaces around a code are allowed
`cybedefend-ignore`	Bare ignore: silences every SAST, IaC and CI/CD finding reported on that line, whatever the rule
`: <reason>`	Optional free text. Always add one so reviewers know why the finding is a false positive

Case does not matter, neither for the directive nor for the codes: CYBEDEFEND-IGNORE[cd-iac-0123] is valid.
Only rule codes count between the brackets. Any other identifier matches no rule, and the finding is still reported. See Migrate Existing Directives.
One directive per line. To silence several rules on the same line, list all their codes in the same brackets.
Any comment syntax works: #, //, --, /* */, , template comments. See Examples by Comment Style.

Find the Rule Code

Where	How
Dashboard	Open a SAST, IaC or CI/CD finding: its detail shows the rule code. Copy directive copies a ready-to-paste directive in the comment syntax of the finding’s file, with a `<reason>` placeholder. Paste it on the flagged line or on the line above, then replace `<reason>` with your justification.
Cybe MCP	`get_vulnerability_` and `list_vulnerabilities_` return the code in the `ruleCode` field for SAST, IaC and CI/CD findings. `cybe_scan_findings` returns it for the SAST, IaC and CI/CD findings of a diff scan.

A code identifies a CybeDefend rule, not a single finding: every finding of that rule carries the same code.

Placement

Put the directive on the flagged line, the line the finding points to, or on the line directly above it. For a finding that spans several lines, the flagged line is the first one.

On the same line

const query = `SELECT * FROM users WHERE id = ${id}`; // cybedefend-ignore[CD-SAST-0042]: id is validated as an integer upstream

On the line above

# cybedefend-ignore[CD-SAST-0137]: table name comes from a static allowlist
cursor.execute(f"SELECT * FROM {table} WHERE id = %s", (user_id,))

Only the line directly above counts. A directive two lines above the finding, or separated from it by a blank line, has no effect.

Examples by Comment Style

Write the directive in a comment of the file’s own syntax:

Comment	File types	Directive
`#`	Terraform, YAML (Kubernetes manifests, CI/CD workflows), Dockerfile, Python, Ruby, shell	`# cybedefend-ignore[CD-IAC-0123]: <reason>`
`//`	JavaScript, TypeScript, Go, Java, C, C++, C#, PHP	`// cybedefend-ignore[CD-SAST-0108]: <reason>`
`--`	SQL	`-- cybedefend-ignore[CD-SAST-0633]: <reason>`
`<!-- -->`	HTML, XML	`<!-- cybedefend-ignore[CD-SAST-0512]: <reason> -->`
Template comment	Helm templates	`{{- /* cybedefend-ignore[CD-IAC-0456]: <reason> */}}`

Terraform, YAML, Dockerfile, Python (`#`)

resource "aws_s3_bucket" "public_assets" {
  bucket = "my-public-assets"
  # cybedefend-ignore[CD-IAC-0123]: this bucket intentionally serves public static assets
  acl    = "public-read"
}

containers:
  - name: app
    securityContext:
      # cybedefend-ignore[CD-IAC-0456]: dev-only manifest, never deployed to production
      privileged: true

steps:
  # cybedefend-ignore[CD-CICD-0007]: first-party action, its tags are protected in our organization
  - uses: our-org/deploy-action@v2

# cybedefend-ignore[CD-IAC-0789]: internal base image, rebuilt and scanned nightly by the platform team
FROM registry.example.com/base-images/node:latest

subprocess.run(cmd, shell=True)  # cybedefend-ignore[CD-SAST-0215]: cmd is a hard-coded constant

JavaScript, TypeScript, Go, Java (`//`)

// cybedefend-ignore[CD-SAST-0108]: content is escaped by the template engine
res.send(renderedHtml);

// cybedefend-ignore[CD-SAST-0311]: file path is built from an internal enum, not user input
data, err := os.ReadFile(path)

// cybedefend-ignore[CD-SAST-0420]: the digest is a cache key, not a security control
MessageDigest md = MessageDigest.getInstance("MD5");

SQL (`--`)

-- cybedefend-ignore[CD-SAST-0633]: @table_name is checked against sys.tables before this statement
EXEC('SELECT * FROM ' + @table_name);

HTML and XML (``)

<!-- cybedefend-ignore[CD-SAST-0512]: the link only targets our own documentation site -->
<a href="https://docs.example.com" target="_blank">Documentation</a>

Helm Templates

In a Helm template, write the directive as a template comment. Helm drops it when it renders the chart, so your rendered manifests stay unchanged.

securityContext:
  {{- /* cybedefend-ignore[CD-IAC-0456]: the node agent needs host access, reviewed by the platform team */}}
  privileged: true

Behaviour

Every scan: the directive applies the same way to full scans, to diff scans (including the ones an AI agent runs with cybe_scan_diff), and to scans started from the CLI or a CI pipeline.
One code per rule: a code covers its rule whichever analyzer reports the finding.
Silent: a silenced finding is not created. It does not appear in the platform, in reports, in project metrics, or in diff scan results.
Already open: when you add a directive for a finding that is already open, the next full scan of that branch marks it Resolved. A diff scan leaves the project’s findings as they are.
Never on secrets: no directive, bare or scoped, silences a secret finding. See Secret Findings.
Persistent: because the directive is committed with the code, the finding stays silenced on all later scans until the comment is removed.
Safe by default: a malformed directive has no effect, and the finding is reported. A broken scoped directive is never read as a bare one.

Migrate Existing Directives

Breaking change. Between the brackets, CybeDefend recognises only rule codes (CD-<TYPE>-<NNNN>). A directive that lists another identifier, such as a UUID, a CKV_… or BC_… identifier, or a dotted rule name, silences nothing: the finding it targets is reported. Replace each identifier with the rule code.A directive on a secret silences nothing either, bare or scoped: the secret is reported. Handle it as described in Secret Findings.

List the directives to update

From the root of your repository, list the scoped directives whose brackets do not start with a rule code:

git grep -niE 'cybedefend-ignore[[:space:]]*\[' | grep -viE 'cybedefend-ignore[[:space:]]*\[[[:space:]]*cd-'

Get the rule codes

Run a scan of the branch. The findings those directives target are reported: open each SAST, IaC or CI/CD one in the dashboard and use Copy directive, or read its ruleCode through the Cybe MCP. Secrets are covered in the last step.

Replace the identifiers

Put the code between the brackets and keep your reason:

# Before: the identifier matches no rule, so the finding is reported
# cybedefend-ignore[CKV_AWS_20]: this bucket intentionally serves public static assets

# After
# cybedefend-ignore[CD-IAC-0123]: this bucket intentionally serves public static assets

Handle the secrets

If the scan reports secrets on lines that carry a directive, handle each one as described in Secret Findings. The directive has no effect on the secret: keep it only if it silences another finding of that line.

Best Practices

Prefer a scoped directive (cybedefend-ignore[CD-IAC-0123]) over the bare form. The bare form also hides any other rule that later fires on the same line.

Always give a reason. A directive without one tells a reviewer nothing. Explain why the finding does not apply.
Review in pull requests. Treat a new ignore directive like a security decision. Reviewers should be able to verify the justification.
Audit periodically. Search your codebase for cybedefend-ignore and remove the directives whose reason is out of date.
Do not use it to hide real issues. For findings that are true positives but accepted, set their status to Ignored with a reason in the platform instead, so they remain visible and audited.

Other Ignore Comments

CybeDefend supports one suppression directive: cybedefend-ignore. Do not rely on the suppression comments of other security tools to silence CybeDefend findings. cybedefend-ignore is the one directive that applies the same way to SAST, IaC and CI/CD findings, in every scan.

Troubleshooting

The finding is still reported

Check the finding type. A directive never applies to a secret finding. See Secret Findings.
Check the code. It must be the rule code shown on the finding. Another tool’s rule identifier, a typo, or the code of a different rule matches nothing.
Check the line. The directive must be on the flagged line or on the line directly above it, with no blank line in between. For a finding that spans several lines, use its first line.
Check the brackets. An unclosed bracket (cybedefend-ignore[CD-IAC-0123: …), empty brackets (cybedefend-ignore[]: …), or a directive glued to another word (cybedefend-ignored, cybedefend-ignore-next-line) is not a directive.
Check the scanned code. Confirm the change was committed and included in the scanned branch.

The finding is still listed as open

A directive keeps a finding from being created. A finding that was already open is marked Resolved by the next full scan of its branch, not by a diff scan.

Another finding disappeared unexpectedly

The bare form suppresses every SAST, IaC and CI/CD rule on that line. Switch to the scoped form to keep other findings visible.

CybeDefend

Platform Overview

Getting Started

Agent & AI Integration

IDE Integrations

Code Scanning

Container Scanning

Managing Vulnerabilities

Issue Tracker Integrations

Notifications

Overview

Supported Findings

Secret Findings

Syntax

Find the Rule Code

Placement

On the same line

On the line above

Examples by Comment Style

Terraform, YAML, Dockerfile, Python (`#`)

JavaScript, TypeScript, Go, Java (`//`)

SQL (`--`)

HTML and XML (``)

Helm Templates

Behaviour

Migrate Existing Directives

Best Practices

Other Ignore Comments

Troubleshooting

The finding is still reported

The finding is still listed as open

Another finding disappeared unexpectedly

​Overview

​Supported Findings

​Secret Findings

​Syntax

​Find the Rule Code

​Placement

​On the same line

​On the line above

​Examples by Comment Style

​Terraform, YAML, Dockerfile, Python (#)

​JavaScript, TypeScript, Go, Java (//)

​SQL (--)

​HTML and XML ()

​Helm Templates

​Behaviour

​Migrate Existing Directives

​Best Practices

​Other Ignore Comments

​Troubleshooting

​The finding is still reported

​The finding is still listed as open

​Another finding disappeared unexpectedly

Overview

Supported Findings

Secret Findings

Syntax

Find the Rule Code

Placement

On the same line

On the line above

Examples by Comment Style

Terraform, YAML, Dockerfile, Python (`#`)

JavaScript, TypeScript, Go, Java (`//`)

SQL (`--`)

HTML and XML (``)

Helm Templates

Behaviour

Migrate Existing Directives

Best Practices

Other Ignore Comments

Troubleshooting

The finding is still reported

The finding is still listed as open

Another finding disappeared unexpectedly