Skip to main content

​
Overview

The cybedefend-ignore directive lets you silence a specific finding by adding a comment in your source code, on the vulnerable 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. 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 Scanners

The directive is applied to every finding produced by the code scanners: Use the rule identifier displayed on the finding when writing a scoped directive.
SCA, container and AI-BOM findings are not attached to a source line and cannot be suppressed with an inline comment.

​
Syntax

The directive is matched as a plain token, so it works with any comment style: //, #, /* */, <!-- -->, --, etc. Matching is case-insensitive.

​
Placement

The scanner checks two lines for each finding: the vulnerable line itself and the line directly above it.

​
On the same line

​
On the line above

Only the line directly above is checked. A directive two lines above the finding, or a directive followed by a blank line, has no effect.

​
Examples by Language

​
JavaScript / TypeScript

​
Python

​
Go

​
Terraform (IaC)

​
YAML / Kubernetes (IaC)

​
Secrets

​
Behaviour

  • Every scan type: the directive is honoured on both full scans and diff scans.
  • Persistent: because the directive is committed with the code, the finding stays suppressed on all later scans until the comment is removed.
  • Silent: suppressed findings do not appear in the platform, in reports, or in project metrics.
  • Safe by default: if the scanner cannot read the source file, the finding is kept and reported.
Scan logs record how many findings were dropped:

​
Best Practices

Prefer a scoped directive (cybedefend-ignore[RULE]) over a blanket one. A blanket ignore also hides any new rule that later fires on the same line.
  • Always give a reason. A bare cybedefend-ignore 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 directives that no longer apply.
  • Do not use it to hide real issues. For findings that are true positives but accepted, mark them as such in the platform instead so they remain visible.

​
Other Ignore Comments

Ignore comments from other security tools have no effect on CybeDefend scans. Only cybedefend-ignore is honoured, so suppressions are consistent across all scanner types.

​
Troubleshooting

​
The finding is still reported

  • Check that the comment is on the vulnerable line or the line directly above it.
  • If you used a scoped form, verify the rule ID matches exactly the one shown on the finding.
  • Confirm the change was committed and included in the scanned branch.

​
Another finding disappeared unexpectedly

A blanket cybedefend-ignore suppresses every rule on that line. Switch to the scoped form to keep other findings visible.