A high-volume vulnerability scan returns a high-severity finding on an application server. The analyst suspects a false positive because the banner and installed package do not match the scanner’s assumption. What should the analyst do before assigning remediation effort?
Select an answer to reveal the explanation.
Short Explanation
Think of a scanner like a nosy neighbor: it guesses from what it can see, and guesses can be wrong. Before you send a team off to patch, you validate the finding so effort isn’t wasted on a phantom. If the target doesn’t actually have the vulnerable version, the ticket shouldn’t exist.
Full Explanation
False positives are common in high-volume scanning because scanners infer versions from banners, package metadata, or weak checks that may not reflect the actual deployed state. The correct action is to validate the finding against authoritative asset data, installed package details, configuration, or a safe manual confirmation before opening a remediation ticket. This prevents wasted effort on a non-existent risk and keeps remediation queues credible. Creating a compensating control ticket is premature because controls should address a confirmed exposure, not an unverified scanner assertion. Lowering the CVSS score is also wrong; CVSS describes the vulnerability’s severity, not the confidence in the finding, and scoring adjustments based on suspicion undermine prioritization. Suppressing the scanner rule reduces noise but can hide true positives in the same class of checks and removes a detection signal before the root cause is understood. Exam caveat: when a scanner report is noisy, validate the specific finding first, then tune the scan only after evidence shows the check is unreliable. Operational check: compare the scanner’s reported version to the server package database or inventory record, then document the evidence used to confirm or dismiss the finding.