BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity | Serving organizations across Canada, the US, and beyond | Last updated August 21, 2026

Quick answer: Vulnerability scanners are excellent at finding known weaknesses quickly across a large environment. They are poor at telling you which of those weaknesses you should actually fix first, which ones do not exist in your specific environment, and which ones matter to your business. The gap between a scanner finding and an actionable vulnerability is filled with false positives, context-free severity scores, findings on unreachable systems, and no connection to the assets and business processes that make a vulnerability consequential. Organizations that manage their security program from raw scanner dashboards are spending remediation effort in the wrong places and missing the vulnerabilities that actually expose them to material risk.

Key Takeaways

• Modern vulnerability scanners in a mid-sized environment routinely produce thousands of findings per scan cycle. Research consistently shows that a significant proportion of findings in any scanner report are false positives, duplicates, or vulnerabilities that are not exploitable in the specific environment. An engineering team that attempts to work from raw scanner output spends a substantial fraction of its capacity on vulnerabilities that do not require remediation.
• CVSS severity scores are assigned based on the characteristics of the vulnerability itself, not the characteristics of the environment it is found in. A critical CVSS score on a system with no network path to sensitive data is not a critical priority in your remediation queue. Context-free severity scores systematically misallocate remediation effort toward technically severe but operationally irrelevant findings and away from lower-severity findings that are actually exploitable and consequential in the specific environment.
• Scanner findings from different tools covering overlapping scope produce duplicates: the same vulnerability flagged multiple times by different scanners, each with slightly different finding identifiers, severity scores, and remediation guidance. Without correlation across scanner sources, the remediation team tracks the same vulnerability multiple times, inflating the apparent finding count and creating confusion about remediation status.
• Scanners cannot assess business context. A vulnerability on a server holding customer financial data is not the same priority as the same vulnerability on a test server with no sensitive data, even if the CVSS scores are identical. Only a human analyst who understands the organization’s asset inventory, data classification, and business processes can apply the business context that makes a severity score meaningful.
• The remediation capacity of most engineering teams is fixed. When that capacity is directed at false positives and low-impact findings because the scanner dashboard presents them with the same visual weight as genuinely critical issues, the vulnerabilities that actually matter to the organization’s risk posture wait longer than they should.

The False Positive Problem

False positives are findings that the scanner identifies as vulnerabilities but that are not actually present or exploitable in the scanned environment. They occur for several reasons. Scanners identify vulnerabilities based on version strings and service banners, which can be misleading: a vendor may backport a security fix to an older software version without updating the version string, causing the scanner to flag the vulnerability as present when it has actually been patched. A software component may be installed on a system but not executing in any way that exposes the vulnerability, because the vulnerable code path is never reached in the system’s actual operation. A network service may be flagged as vulnerable based on its exposed port and service banner, but the specific vulnerable feature may be disabled in the configuration.

The false positive rate in enterprise scanner environments is not a marginal problem. Security research consistently finds that a meaningful fraction of findings in large scanner reports are false positives, and this fraction is higher for certain vulnerability classes and certain scanner tools than for others. An organization that remediates 500 findings per quarter based on raw scanner output may be spending a substantial number of engineering hours per quarter on vulnerabilities that do not exist. That capacity redirected to genuine, validated vulnerabilities would produce significantly more risk reduction.

Removing false positives requires manual analysis: an analyst reviews the finding in the context of the specific system’s configuration, confirms that the vulnerability conditions are actually present, and documents the evidence for the decision. This analysis cannot be automated because the determination that a finding is a false positive requires contextual judgment that automated tools cannot reliably apply. It is the work that separates a validated assessment from a raw scanner report, and it is the same manual-versus-automated distinction that separates penetration testing from vulnerability scanning as security disciplines.

The Context Gap

Asset criticality is not in the scanner

A vulnerability scanner knows that a system is running a specific software version with a specific vulnerability. It does not know whether that system is a production server holding the organization’s entire customer database or a developer workstation used for testing with no sensitive data and no network connectivity to production systems. These two scenarios have radically different remediation urgency for the same vulnerability and the same CVSS score. Asset criticality, the organization’s own assessment of how important each system is to business operations and what data it holds, is information that lives in the organization’s asset inventory and security risk register, not in the scanner. Applying it to prioritize scanner findings requires connecting the scanner output to the asset inventory, which is an analytical step that no automated tool performs reliably.

Network reachability is not in the scanner

A scanner identifies vulnerabilities based on what it can see from its scanning position in the network. It does not model the full network topology to determine whether the vulnerable system is reachable from a realistic attack path. A server with a critical vulnerability that sits behind multiple layers of network segmentation, accessible only from a specific subnet used by a small number of administrators, presents a materially different risk than the same vulnerability on an internet-facing web server accessible to any external attacker. Reachability analysis requires understanding the network architecture and the access controls between network segments, which requires human analysis of the network topology rather than automated scanner logic.

Active exploitation context is not in the scanner

Not all vulnerabilities are equally likely to be exploited in practice, even among those with the same CVSS score and the same reachability profile. Some vulnerabilities have public proof-of-concept exploit code available that dramatically lowers the skill bar for exploitation. Some are listed in CISA’s Known Exploited Vulnerabilities catalog, meaning they have been confirmed as actively exploited in real-world attacks. Some are being targeted by ransomware groups or specific threat actors that are relevant to the organization’s industry. The Exploit Prediction Scoring System (EPSS), a probability model for the likelihood that a specific vulnerability will be exploited in the next 30 days, provides a data-driven way to incorporate active exploitation context into prioritization. These factors are external intelligence inputs that are not embedded in scanner output but that dramatically affect which vulnerabilities deserve immediate attention versus which can be addressed on a standard remediation timeline.

What Risk-Based Prioritization Actually Looks Like

Risk-based vulnerability prioritization combines four inputs for each finding: the CVSS base score (the vulnerability’s inherent severity), the asset criticality score (how important the affected system is to the business), the environmental exploitability (is the vulnerability reachable given the network architecture and compensating controls), and the active exploitation context (is this vulnerability being exploited in the wild and is the organization in a sector or profile that makes it a likely target). The combination of these four factors produces a priority score that reflects what matters in the organization’s specific environment rather than what matters to a generic organization.

The practical output of risk-based prioritization is a remediation queue sequenced by priority score, with the findings that combine high asset criticality, high reachability, and active exploitation context at the top regardless of whether their raw CVSS scores are the highest in the environment. In practice, this often means that medium-CVSS findings on critical internet-facing systems with active exploitation in the wild outrank critical-CVSS findings on isolated internal systems with no public exploit code. The prioritization reflects the actual risk to the business, which is what makes the remediation effort efficient. This validated, prioritized output is the core of what a professional vulnerability assessment delivers that a raw scan cannot.

Armour Cybersecurity applies this multi-factor prioritization methodology to every vulnerability assessment engagement, delivering a remediation roadmap that sequences work by real risk reduction rather than raw scanner severity. It builds directly on the foundational validation work described in what a vulnerability assessment actually tells you, turning a raw finding list into an owned, prioritized program.

Frequently Asked Questions

How do we know how many of our current scanner findings are false positives?

Without manual validation, you do not know with certainty, but you can estimate. Vulnerability research and industry benchmarks generally place false positive rates in enterprise scanner environments somewhere in the range of 10 to 50 percent depending on the scanner tool, the environment, and the vulnerability classes being flagged. The most reliable way to measure the false positive rate in your specific environment is to manually validate a sample of findings, particularly in the highest-severity categories where remediation effort is most concentrated. If the validation exercise reveals that a significant fraction of critical findings are false positives, the case for professional validation before acting on scanner output becomes concrete and quantifiable in terms of engineering hours saved.

What is EPSS and should we use it for prioritization?

EPSS stands for Exploit Prediction Scoring System, a machine-learning model developed and maintained by FIRST (the Forum of Incident Response and Security Teams) that estimates the probability that a specific CVE will be exploited in the wild within the next 30 days. It is updated daily based on threat intelligence data and provides a probability score between 0 and 1 for each published CVE. EPSS is a valuable complement to CVSS for prioritization because it incorporates real-world exploitation intelligence that CVSS does not: a vulnerability with a moderate CVSS score but a high EPSS score is being actively exploited and warrants faster remediation than a critical CVSS score with near-zero EPSS probability. EPSS provides the exploitation-likelihood signal only, so the combination of CVSS base score, EPSS probability, and asset criticality produces a more accurate prioritization than any single scoring system alone.

Why do different scanners produce different findings for the same system?

Different vulnerability scanners use different detection methods, different vulnerability databases, and different logic for matching observed system characteristics to known vulnerabilities. One scanner may identify a vulnerability based on the installed package version reported by the operating system package manager; another may use a network service banner to infer the software version; a third may use a direct probe of the service to confirm the vulnerability condition. These different methods produce different results because they access different information about the target system. The coverage and accuracy of each scanner also varies by operating system, software category, and vulnerability class: some scanners are more comprehensive for Windows environments, others for Linux; some have stronger coverage of network infrastructure, others of web applications. Using multiple scanners with overlapping scope and correlating their findings produces more comprehensive and more accurate results than relying on a single scanner, at the cost of requiring correlation work to remove duplicates.

Our remediation team is already overwhelmed. How does better prioritization help?

Better prioritization helps precisely because the remediation team is overwhelmed: it directs limited capacity toward the vulnerabilities that produce the most risk reduction per hour of remediation effort. A team working from a deprioritized list of thousands of findings will make progress through the list by severity score, but severity score alone does not correlate well with the actual risk reduction the organization achieves as each finding is closed. A team working from a risk-prioritized list closes the vulnerabilities that matter most first, which means the organization’s actual exposure decreases faster even if the total finding count decreases at the same pace. The prioritization work does not create more remediation capacity; it makes the existing capacity more effective by directing it at the right problems first.

How often do we need to re-scan after remediating findings?

Re-scanning after a remediation cycle serves two purposes: confirming that the remediations implemented are technically complete and not just administratively closed, and identifying any new vulnerabilities introduced since the last scan. For critical and high-severity findings, re-scanning the specific affected assets after remediation is applied, before the next scheduled full-cycle scan, confirms closure and produces the evidence record that auditors and governance stakeholders expect. For the full finding inventory, the re-scan cadence should match the assessment frequency: quarterly assessments include a re-scan of the prior cycle’s findings as the first step of the new cycle. Organizations that close findings in their tracking system without verifying closure through re-scanning consistently find that some apparent remediations are incomplete when the next assessment confirms the finding is still present.

The Bottom Line

A vulnerability scanner is a data-collection tool, not a risk-management program, and treating its raw output as a remediation plan is how security teams end up busy without getting safer. The scanner cannot tell you which findings are false positives, which sit on systems that hold nothing an attacker wants, which are unreachable behind segmentation, or which are being actively exploited in the wild right now. Those judgments require validation, asset context, reachability analysis, and active-exploitation intelligence layered on top of the scan, which is exactly what turns a list of thousands of findings into a short, ordered queue of the ones that actually reduce risk. That is the difference between running a scanner and managing vulnerability risk. Armour Cybersecurity’s vulnerability assessment delivers the validated, risk-prioritized remediation roadmap that raw scanner output cannot, sequenced by real risk reduction rather than context-free severity.