vulnetix ignore, from the CLI
The vulnetix ignore command (aliased suppress) manages rules with add, list, remove and sync. A rule is anchored by at least one of a rego rule id (--rule), a finding id such as a CVE (--finding), or a file path (--file), and can be scoped by scanner category (--category sast|secrets|iac|container|sca|license|malware). Give it a --type and a --reason, optionally a --line-range, and --expires-in days so a temporary exception cannot outlive its justification. Credentials are optional: with none, the rule lives locally; authenticated, it also syncs to your organisation.
The finding is not real in this context.
Acknowledged, but a fix is not planned.
The risk is understood and accepted, with a reason on record.
A compensating control is already in place.
Not now; revisit later (pair with an expiry).
Machine source: raised because a rego rule id was suppressed.
Machine source: raised from an inline nosec comment in code.
nosec, in the code itself
For suppressions that belong next to the line they describe, Vulnetix reads gosec-compatible nosec comments in #, //, -- and ; comment styles. A bare nosec on a finding's line drops every finding on that line; nosec vnx-315,vnx-320 drops only those rule ids; and a nosec on the first line of a file applies to the whole file (bare for all rules, or with ids for just those). The scan reports how many findings each pass suppressed, so nothing disappears silently.
Local memory, and org-wide policy
Rules are written to .vulnetix/memory.yaml under a suppressions: block, so they work fully offline and travel with the repo. When you authenticate, vulnetix ignore sync pulls the organisation's rules into local memory and pushes yours up, so the whole org shares one policy. In the console, the Suppression Policies page is the central registry: every rule grouped by repository and category, with extend, deactivate and delete actions, and per-finding "Ignore this finding" flows on the finding pages themselves.
Every anchor must match
Suppression is deliberately conservative. A rule silences a finding only when every anchor it specifies matches: the rego rule id (compared case-insensitively), the finding id, the category, and the file path (suffix-tolerant, so src/app.go covers repo/src/app.go). An anchorless rule matches nothing. That is what makes a ruleId-specific rule safe: --rule vnx-sec-001 suppresses that weakness class and leaves everything else reporting.