Traditional vulnerability scanning has been a cornerstone of enterprise security programs for decades. However, some fundamental aspects of how these tools operate - and how quickly vulnerabilities are exploited in the wild - suggest we might need to reconsider this approach. This analysis explores why scanning might be problematic as a primary security measure, particularly for Internet-facing systems, and considers what alternatives might look like.
I’d like to explore some observations about how traditional network and web vulnerability scanners work and why their core premises might be problematic, particularly when assessing Internet-facing systems. While this analysis focuses primarily on Internet-exposed hosts, many of these fundamental limitations apply equally to internal systems that aren’t directly accessible from the Internet.
At their core, these enterprise security assessment solutions typically operate in two main ways:
Remote scanners attempt to match software versions (CPEs) to known vulnerabilities through banner grabbing, HTTP headers, or other remotely visible indicators. For web applications, they often rely on simplistic patterns like HTTP response codes or error messages. This seems inherently uncertain - version numbers can be wrong, spoofed, or meaningless due to backporting of security fixes, while application responses might not indicate actual vulnerability.
Agent-based scanners, while having deeper system access, appear to face their own fundamental limitations. They can examine files on disk but struggle with context: understanding if code is actually loaded, whether compensating controls exist, or how components truly interact in production. They often miss custom patches and can’t meaningfully assess complex dependency relationships.
[Note: This analysis isn’t intended to be comprehensive - rather, it presents a logical argument about the state of vulnerability scanning based on commonly observed limitations and core operational realities. While emerging approaches like Cloud Security Posture Management (CSPM) attempt to address some of these limitations by providing a more holistic view of the environment, realizing these benefits typically requires deep platform integration and comprehensive adoption.]
These observations suggest what might be an insurmountable paradox for vulnerability scanning, particularly for Internet-facing systems, when we consider a simple reality: The time between public exploit availability and active exploitation attempts in the wild can be remarkably short, with many well-documented cases of mass exploitation beginning within days of vulnerability disclosure. While internal systems may have some additional protection through network segmentation and access controls, they still face many of these same fundamental challenges.
Let’s consider what this means when a scanner finds a vulnerability. The possible scenarios seem to be:
This set of possibilities suggests a fundamental challenge for scanner-based security:
Findings might either represent imminent/existing compromise or could be invalid/unexploitable. There seems to be very little middle ground where scanner findings represent “actionable intelligence” with a reasonable window for response.
Instead of primarily chasing vulnerabilities, perhaps modern security could focus more on fundamental engineering practices that build and maintain systems to known good standards:
This approach emphasizes security as a core engineering concern rather than treating it as an external validation exercise.
Real-world security testing provides something particularly valuable - validated security insights based on actual exploitation attempts. Unlike scanner findings, issues discovered through bug bounties, skilled penetration testing, and red team engagements (when properly scoped) represent confirmed problems that:
This is why findings from skilled security testers (whether external bug bounty hunters, internal red teams, or professional penetration testers who go beyond automated scanning) are so valuable - they represent ground truth about what’s actually exploitable in your environment.
While this analysis suggests scanning might not be the best foundation for security, we must acknowledge the reality of compliance requirements and organizational dynamics. Many regulatory frameworks explicitly require vulnerability scanning, often with specific requirements for Internet-facing systems versus internal infrastructure. Compliance teams typically demand response to scanner findings regardless of system location.
This creates a challenging situation: we know many scanner findings may be invalid or unexploitable, but we still need to process and respond to them for compliance reasons. Some potential approaches to managing this tension:
The goal isn’t to ignore scanner findings entirely - that’s typically not possible in practice. Rather, the aim is to:
This exploration suggests that the future of security might lie at the intersection of rigorous security hygiene and intelligence-driven discovery. While the specific implementation details would need to be worked out for each organization, a basic cycle might look like:
The key insight here isn’t that this is definitely the right approach, but rather that we might need to rethink our reliance on vulnerability scanning as a primary security measure. While we need to manage scanning findings for compliance reasons, there could be better paths to genuine security improvement through focusing on system design and real-world validation.
This is just a preliminary sketch of what such an approach might look like, and there’s much work to be done in developing and validating these ideas in practice. I welcome discussion and debate on these observations and proposals.
Log4Shell (CVE-2021-44228)
ProxyLogon (CVE-2021-26855)
Citrix ADC/Gateway (CVE-2019-19781)