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.

The Empirical Case Against Scanning

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.]

A Potential Logical Paradox

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:

• You could be compromised very soon if you don’t act immediately (due to automated exploitation)
• You might already be compromised (and an attacker may or may not have covered their tracks)
• The reported vulnerability might not actually be exploitable in your environment (due to configurations, compensating controls, etc.)
• The available exploit code might need customization for your specific configuration
• The scanner could be generating a false positive

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.

Exploring A New Security Paradigm: Security Hygiene and Intelligence-Driven Discovery

Security Hygiene: A Potential Foundation

Instead of primarily chasing vulnerabilities, perhaps modern security could focus more on fundamental engineering practices that build and maintain systems to known good standards:

• Implementing proven security standards during system design and development
• Maintaining known good states through rigorous configuration management
• Verifying security properties continuously
• Following established best practices across the development lifecycle
• Creating repeatable security processes that scale with system growth

This approach emphasizes security as a core engineering concern rather than treating it as an external validation exercise.

The Intelligence-Driven Discovery Loop

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:

• Have been manually verified in your specific environment
• Include proof of exploitability
• Demonstrate actual impact
• Account for your specific configurations and controls

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.

Pattern Analysis

• Identifying common vulnerability patterns that bypass existing controls
• Understanding successful attacker methodologies in your environment
• Mapping actual, proven attack surfaces and entry points
• Recognizing where security controls are failing in practice

Process Improvement

• Feeding verified vulnerability patterns back into engineering practices
• Building custom security verifiers based on confirmed bug findings
• Improving security architecture based on demonstrated attack patterns
• Strengthening security controls based on documented bypass techniques

Custom Verification

• Developing targeted security tests based on proven bug patterns
• Building automated checks for previously-confirmed issue classes
• Creating custom security assertions based on successful bypass techniques
• Implementing continuous verification of fixed issues

Managing the Compliance Reality

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:

• Develop clear processes for triaging scanner findings based on likelihood of exploitability
• Build documentation templates for common false positives and compensating controls
• Create automated verification tests that can quickly validate or invalidate certain classes of findings
• Maintain strong relationships with compliance teams to help them understand the limitations of scanning
• Focus remediation efforts on findings that correlate with patterns seen in real-world testing
• Use data from confirmed exploitable issues to help prioritize scanner findings

The goal isn’t to ignore scanner findings entirely - that’s typically not possible in practice. Rather, the aim is to:

1. Handle them efficiently through systematic processes
2. Prioritize based on real-world validation where possible
3. Build institutional knowledge about which types of findings matter most in your environment
4. Focus most of your security engineering effort on building better systems rather than chasing alerts

A Possible Path Forward

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:

1. Build systems with strong security hygiene
2. Verify security state continuously
3. Use validated findings from real-world testing to improve both hygiene and verification
4. Repeat with better practices and controls

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.

References

1. Log4Shell (CVE-2021-44228)
   • NIST: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
   • Apache Foundation Advisory: https://logging.apache.org/log4j/2.x/security.html
   • CISA Alert: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
   • Check Point Research (Exploitation Statistics): https://research.checkpoint.com/2021/the-numbers-behind-a-cyber-pandemic-detailed-analysis-of-log4j-exploitation/
   • Microsoft Threat Intelligence Center: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
2. ProxyLogon (CVE-2021-26855)
   • Microsoft Security Response Center: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855
   • MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26855
   • CISA Alert: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-062a
   • ESET Research (Exploitation Timeline): https://www.welivesecurity.com/2021/03/10/exchange-servers-under-siege-10-apt-groups/
   • Volexity (Initial Discovery & Exploitation): https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/
3. Citrix ADC/Gateway (CVE-2019-19781)
   • Citrix Security Advisory: https://support.citrix.com/article/CTX267027/citrix-adc-and-gateway-security-update-for-cve201919781
   • NIST: https://nvd.nist.gov/vuln/detail/CVE-2019-19781
   • MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19781
   • FireEye Threat Research: https://www.mandiant.com/resources/blog/cve-2019-19781-exploitation
   • Bad Packets Report (Mass Scanning): https://badpackets.net/over-25000-citrix-endpoints-vulnerable-to-cve-2019-19781/