What Is Vulnerability Scanning and How Does It Actually Work?

Vulnerability scanning is the security equivalent of a health checkup. It probes your systems for known weaknesses, misconfigurations, and deviations from best practices. Most organisations use some form of scanning, yet few understand what actually happens when a scanner runs. That gap between expectation and reality leads to both false confidence and missed opportunities. Here's what vulnerability scanning actually does — and what it doesn't.

The Anatomy of a Scan

A vulnerability scanner follows a structured process, regardless of the specific tool:

• Target enumeration: The scanner identifies what's in scope — IP addresses, domain names, ports, and services. This often starts with DNS resolution and port scanning to discover what's running and where.
• Service detection: For each open port, the scanner determines what software is running. It reads banners, analyses response patterns, and fingerprints protocol behaviour to identify specific software versions.
• Vulnerability matching: The scanner compares discovered software versions and configurations against a database of known vulnerabilities (CVEs). If you're running nginx 1.18.0 and there's a CVE affecting versions below 1.19.0, it flags it.
• Configuration analysis: Beyond known CVEs, the scanner tests for misconfigurations — weak TLS ciphers, missing security headers, default credentials, exposed admin panels, and permissive CORS policies.
• Reporting: Results are compiled with severity ratings, typically mapped to CVSS scores, along with remediation guidance.

The entire process can take seconds for a lightweight external scan or hours for a comprehensive internal network assessment.

What Scanners Actually Detect

Modern vulnerability scanners are effective at finding a specific class of problems — the ones that have deterministic, testable signatures:

• Known CVEs: If a vulnerability has a published advisory with affected version numbers, a scanner can match it. This is the scanner's strongest capability.
• Missing patches: Software running versions older than the latest security patch is flagged. This requires accurate version detection, which isn't always straightforward.
• Configuration weaknesses: Missing HTTP security headers, weak TLS configurations, permissive CORS, insecure cookie attributes, and exposed server information. These are measurable against established baselines.
• Default credentials: Many scanners test for default username-password combinations on common services and admin panels.
• Information disclosure: Verbose error pages, directory listings, exposed .git directories, and publicly accessible configuration files.

What Scanners Cannot Detect

Understanding scanner limitations is as important as understanding their capabilities. Scanners consistently struggle with:

• Business logic flaws: A scanner can't determine that "a regular user shouldn't be able to view another user's invoice." It doesn't understand your application's business rules.
• Authentication and authorisation flaws: BOLA, privilege escalation, and insecure direct object references require understanding of user roles and data ownership that scanners lack.
• Complex injection: While basic SQL injection and XSS are detectable, second-order injection (where the payload is stored and triggered elsewhere) evades automated scanning.
• Race conditions: Time-of-check-to-time-of-use (TOCTOU) vulnerabilities require concurrent request testing that most scanners don't perform.
• Chained vulnerabilities: The most damaging attacks combine multiple low-severity findings into a high-severity chain. Scanners report individual findings but don't chain them.

The CVE Database: Your Scanner's Brain

A vulnerability scanner is only as good as its vulnerability database. The Common Vulnerabilities and Exposures (CVE) system assigns unique identifiers to publicly disclosed vulnerabilities. When a scanner checks for CVEs, it's checking against a database that's updated as new vulnerabilities are disclosed.

The critical implication: scanners cannot detect zero-day vulnerabilities. If a vulnerability hasn't been publicly disclosed and assigned a CVE, no scanner will find it. This is the fundamental reason vulnerability scanning and penetration testing serve different, complementary purposes.

Database update frequency matters significantly. A scanner using a database that's two weeks old might miss critical vulnerabilities disclosed in that window — vulnerabilities that attackers are already exploiting. The best scanning solutions update their databases continuously.

External vs. Internal Scanning

External scanning examines your systems from the internet — the same perspective an attacker has. It tests what's publicly exposed: web servers, email infrastructure, DNS configuration, and TLS setup. This is the minimum viable security assessment because it covers what every threat actor in the world can probe without any special access.

Internal scanning runs from inside your network, testing systems that aren't internet-facing. It typically finds more vulnerabilities because internal systems are often less hardened — the assumption being that network-level access control provides sufficient protection. That assumption breaks down when an attacker gains initial access through phishing, credential theft, or a web application vulnerability.

Both perspectives are necessary, but if you're doing nothing today, external scanning provides the highest-impact starting point because it addresses the attack surface that's continuously probed by automated tools worldwide.

Scan Frequency and the Window of Exposure

A vulnerability scan is a snapshot. The moment it completes, your environment starts drifting — new deployments, configuration changes, newly disclosed CVEs. The window between scans is a window of exposure. Industry best practice is continuous or at least weekly scanning for internet-facing assets, with on-demand scanning triggered by deployments and infrastructure changes.

Organisations that scan quarterly are operating with three months of blind spots. Given that the average time from CVE disclosure to active exploitation is now measured in days, not weeks, quarterly scanning is insufficient for any serious security program.

ShieldReport provides instant external vulnerability scanning of your domain, checking TLS configuration, security headers, DNS records, and information disclosure against current security baselines — so you can see your exposure as attackers see it, without waiting for a scheduled assessment.