When you dismiss an SCA finding, write down why, what evidence supports it, who decided, and when it will be reviewed. A dismissal with no reason is indistinguishable from neglect. A short, specific note lets a new teammate or an auditor understand the decision in under a minute.
Why the note matters more than the dismissal
Tools make dismissing easy. Months later nobody remembers why a finding was closed, whether the reasoning still holds, or who agreed. The dismissal itself is a one click action. The note is what makes it a decision.
Reason categories
Use a small fixed set so notes are comparable. These mirror the justifications in the CISA VEX minimum requirements, which list five reasons a product is not affected: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by an adversary, and inline mitigations already exist. Two more cover common SCA cases that are not "not affected": accepted risk and false match.
| Category | Meaning | Evidence to attach |
|---|---|---|
| Component not present | Package is not in the shipped artifact | Build output or SBOM excerpt |
| Vulnerable code not present | Flawed code was removed or never included | Version check, advisory text |
| Not in execute path | No call path to the function | Reachability result or code search |
| Not attacker controlled | Input cannot be influenced by an outsider | Code reference, architecture note |
| Inline mitigation | A control already blocks exploitation | Config reference, test |
| Accepted risk | Exposed but accepted for a period | Approver, expiry |
| False match | Report matched the wrong package | Package identity check |
The template
Finding: vulnerability ID, package, version
Reason: category from the list above
Evidence: link or short description
Decided by: name or role
Date: when decided
Review by: date, or event such as next major upgrade
Examples of good and bad notes
Bad: "Not an issue."
Good: "Not in execute path. The function is used by the XML import module, which is not included in our build. Confirmed by searching the production bundle. Decided by the platform lead. Review at the next framework upgrade."
Review rules
- Reasons based on analysis, such as not in execute path, should be reviewed when the code changes, since a new call path can invalidate them.
- Accepted risks need a hard expiry date.
- Dismissals of known exploited findings should need a second approver.
Static analysis has known limits. The govulncheck documentation notes that calls through reflection are not visible and that unsafe code can cause false negatives, so a not-in-execute-path dismissal should state how it was checked beyond the tool.
Try it yourself
Click through it at your own pace, or open it full screen. Note the questions asked before a finding is called not exploitable.
Where Safeguard fits
Safeguard's policies and compliance evidence automation keep decisions and their evidence attached to findings for later review.
Quick check
Is "false positive" enough as a reason?
No. Say what was wrong, such as the package identity not matching, and attach how you checked.
How long should a dismissal last?
Tie it to a review date or an event like an upgrade. Open ended dismissals go stale.
Sources
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
- Go, govulncheck documentation
Last reviewed: 19 October 2026.
