Turn a scanner alert into a defensible finding
Check applicability, reachability, evidence, and impact before treating an automated alert as a confirmed vulnerability in your application.
A scanner alert is a signal to investigate. A defensible finding connects that signal to the affected system, version, reachable behavior, and supported impact. Do not dismiss every automated alert as noise, but do not treat every package-name match as proof of a customer-facing defect.
The right next step depends on the alert. A known-exploited component in an exposed production path may need urgent action while evidence is refined. A mismatched package identifier may require correction before any code change. Keep urgency and confidence visible rather than collapsing them into one score.
What questions turn an alert into a review record?
| Question | Useful evidence |
|---|---|
| Is this the correct component? | Ecosystem, package name, version, and source |
| Is the affected condition present? | Vendor advisory and relevant configuration |
| Is this deployed? | Build inventory or runtime evidence |
| Can the application reach the behavior? | Approved source trace or controlled test |
| What limits the impact? | Permissions, isolation, configuration, or mitigations |
| What remains unknown? | Missing facts with a named owner |
| What should change? | Supported update, configuration fix, or removal |
The OWASP vulnerable dependency guidance discusses handling dependency findings in context. The worksheet above is a suggested triage record, not a requirement to demonstrate exploitation before fixing a known problem.
How do you avoid two common mistakes?
First, do not call an alert false merely because a quick test failed. The test may not reproduce the necessary configuration or execution path. Record “not reproduced under these conditions” unless you have evidence that the alert is inapplicable.
Second, do not broaden a confirmed observation beyond the evidence. An issue in one permitted test endpoint does not establish that every environment or customer is affected. State the deployment and conditions you actually reviewed.
Prefer official vendor fixes and documented mitigations. Avoid an improvised workaround that hides the scanner result while leaving the relevant behavior unchanged.
What does a useful outcome look like?
Assign one of several clear outcomes: applicable and scheduled for repair, mitigated with evidence, inapplicable with a reason, or unresolved pending specific information. Keep the original alert and the reasoning connected.
After the repair, verify the deployed version and the relevant behavior. A green dashboard may reflect a changed scanner rule rather than a repaired system.
Ask Sourced about a focused review when your team needs to separate actionable application risk from an unqualified list of alerts.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.