Inline Suppression

Two mechanisms suppress individual findings without disabling the underlying rule for the whole project: inline novygl comments in source, or in-dashboard triage to false_positive / ignored / suppressed. They behave very differently — pick the one that matches whether you want the suppression visible or invisible to the dashboard.

Inline `novygl` comments

Add a comment on the finding’s line or the line directly above it to suppress it.

# Suppress a specific rule on this line
password = "test123"  # novygl: secrets.generic.password-assignment

# Suppress all Vygl findings on this line
api_key = "AKIAIOSFODNN7EXAMPLE"  # novygl

# Multi-rule suppression in one comment
# novygl: secrets.aws.access-key-id, secrets.generic.password-assignment
ARTIFACT = build_artifact(...)

The form is # novygl: <rule-id> (specific), # novygl: rule-a, rule-b (multiple), or # novygl (all rules on this line). The marker is case-insensitive — NOVYGL works the same. Supported comment styles are //, #, /* ... */, and --:

/* novygl: secrets.aws.access-key-id */

-- novygl: secrets.generic.connection-string

HTML / XML / template-style comments () are not currently recognized.

The rule ID matches the one shown in the finding detail view. Findings suppressed inline are dropped at scan time — they never reach the dashboard, never appear in finding lists, and never show up in compliance exports. If you need the suppression to be auditable, use in-dashboard triage instead.

In-dashboard triage (auditable suppression)

When you want the suppression visible alongside other triage state, set the finding’s status to one of:

false_positive — the rule fired incorrectly. Sticky across rescans; appears in dashboard filters.
ignored — accepted risk. Sticky, but supports an optional snooze (see Triage).
suppressed — finding-specific suppression with a full audit trail. Used heavily by CVE Watch but available to any caller.

Each transition emits an audit-log entry (finding.triage or finding.bulk_triage) with actor, prior status, new status, and reason. Compliance reviews can reconstruct exactly who suppressed what and when.

When to use which

Inline novygl — the suppression should travel with the code (e.g. test fixtures with deliberately-insecure values, documented hardcoded examples in tutorials). Trade-off: the finding never appears anywhere in Vygl, so compliance reviewers can’t see it without reading source.
In-dashboard false_positive / ignored / suppressed — when you want the suppression visible and auditable, when modifying source isn’t appropriate (vendored code, generated files), or when reviewers expect to see the decision in the platform.

What “stable fingerprint” really means

Fingerprints normalize whitespace — spaces and tabs are stripped from the snippet before hashing — but they’re sensitive to other edits:

✅ Reformatting (whitespace-only changes) preserves the fingerprint.
❌ Adding or removing lines above the finding shifts start_line and changes the fingerprint.
❌ Renaming a variable, splitting a long expression across lines, or otherwise changing the snippet’s content changes the fingerprint.
❌ Moving the file changes the fingerprint.

Use the audit-trail path (false_positive / ignored / suppressed) when you expect the surrounding code to keep evolving — sticky triage migrates across branches automatically and survives the kind of refactors that would invalidate a hard-coded fingerprint.