Triage a finding you are not going to fix

The difference between hiding a finding and deciding about it.

Not every finding gets fixed. Some are not exploitable in your application, some are in test code, some are accepted risk. That is normal, and a tool that cannot express it gets ignored wholesale.

What matters is that the decision is recorded rather than silently disappearing.

Suppress, or triage?

Suppress hides the finding. Use it when the finding is wrong: a false positive, or a credential in a fixture.

Triage records what the vulnerability means for you and keeps it visible. Use it when the finding is correct but does not require action here.

The difference matters at audit time. A suppressed finding says “we did not want to see this”. A triaged one says “we assessed this and here is the reasoning”, which is what a customer’s security questionnaire is actually asking for.

Triaging

1. Open the finding, or right-click it in the Findings view.
2. Triage.
3. Choose a status:
   • Not affected, with a justification
   • Affected, with an action statement and a plan
   • Fixed
   • Under investigation
4. Add the reasoning. This is the part someone reads in six months.

Justifications for “not affected” are the standard VEX set: the component is not present, the vulnerable code is not present, it is not in the execute path, it cannot be controlled by an adversary, or mitigations already exist.

Why the justification matters

Triage decisions export as VEX documents, which is the machine-readable form of “we looked at this and it does not apply to us”.

That turns a recurring manual questionnaire into a generated artefact. A customer asking whether you are affected by a widely-publicised CVE gets an answer with reasoning attached, produced from decisions your engineers already made.

Suppressing instead

Three scopes:

• This line. A nosec comment on the line.
• This file. A nosec on line 1.
• This repository. Recorded in .vulnetix/memory.yaml, and synced to your organisation when signed in.

For anything beyond a one-off, prefer the recorded form over a bare comment. It carries who, when, why, and optionally an expiry, and it is reviewable. A comment is invisible to everyone not reading that file.

Suppressions follow the code

When a suppressed finding moves because lines were added above it, the suppression is relocated using git history rather than going stale and re-firing. Refactoring does not undo your triage.

Expiring a suppression

Give it an expiry when the reasoning is temporary. “Not exploitable until we enable that endpoint” is true right up until someone enables the endpoint.