What Is a Vulnerability Scan? A Clear Explanation for Developers
A vulnerability scan checks systems and applications against known weaknesses. Here's what it is, how it works, and where it fits in a security program.
A vulnerability scan is often described as if it's a single, well-defined thing. It isn't. The term covers a range of automated checks that vary widely in depth, accuracy and scope — and knowing which kind you're getting changes how much you should trust the result.
The basic definition
A vulnerability scan is an automated process that checks systems, applications or infrastructure against a database of known weaknesses — misconfigurations, outdated software, exposed services, common code-level flaws — and reports what it finds, usually ranked by severity.
The key word is known. A vulnerability scan is fundamentally a matching exercise: it compares what it observes against a catalogue of previously identified issues. It is not designed to reason about novel or context-specific problems.
What a vulnerability scan checks
Depending on the tool and scope, a vulnerability scan typically covers:
- Software versions — checked against CVE databases for known exploits
- Configuration — headers, permissions, exposed services, default credentials
- Network exposure — open ports, reachable internal services
- Application-layer patterns — common injection points, known framework vulnerabilities
- Certificates and encryption — expired or weak TLS configuration
How a vulnerability scan actually works
Most scanners follow a similar process:
- Discovery — identify live hosts, open ports, running services or application endpoints
- Fingerprinting — determine software, versions and technologies in use
- Matching — compare fingerprinted data against a vulnerability database
- Verification (in better tools) — attempt to confirm a match is actually exploitable, rather than just theoretically present
- Reporting — output findings, typically with a severity score such as CVSS
The verification step is where scanners differ most in quality. A scanner that only fingerprint-matches will report every instance of an outdated library version as a finding, regardless of whether the specific vulnerable code path is even reachable. A scanner that verifies exploitability produces a shorter, more trustworthy list.
Types of vulnerability scans
- External scans — test what's visible from outside the network, simulating an internet-based attacker
- Internal scans — test what's reachable from inside the network, relevant for insider-threat or lateral-movement scenarios
- Authenticated scans — log in first, testing what a real user (or attacker with stolen credentials) could reach
- Unauthenticated scans — test only what's visible without credentials
Authenticated and external scans are the most commonly run pair for web applications, since most business logic sits behind a login and most attackers start from outside.
Vulnerability scan vs. penetration test
This distinction gets blurred in marketing material, but it matters:
A vulnerability scan is automated pattern-matching against known issues. A penetration test is a human tester actively trying to break into a system, using judgment, chained exploits and creativity a scanner doesn't have.
Vulnerability scans are cheap and repeatable — you can run them weekly or on every deploy. Penetration tests are more expensive and typically run periodically. A mature security program uses both: scanning for continuous coverage, penetration testing for depth.
What a vulnerability scan won't tell you
- Whether a finding is actually exploitable in your specific context
- Business logic flaws that don't match a known signature
- Access control issues that depend on understanding what a user should be allowed to do
- The severity of a finding once it's combined with other, individually minor issues
This is why a scan report is a starting point for triage, not a final verdict on how secure an application is.
How does Averto fit in?
Averto's platform is built around this distinction directly: continuous automated scanning for coverage, combined with verification and deeper testing so findings reflect actual exploitability rather than a raw signature match. A shorter, accurate list of real issues is worth more than a long list of theoretical ones.
Frequently asked questions
Is a vulnerability scan the same as a security audit?
No. A security audit is typically broader and includes policy, process and compliance review, not just technical scanning.
How accurate are vulnerability scans?
It depends on the tool. Basic scanners produce a meaningful rate of false positives; scanners that verify exploitability are more accurate but slower.
Do I need a vulnerability scan if I already do code review?
Yes — code review catches different issues than scanning, particularly around configuration, infrastructure and third-party dependencies that aren't visible in your own codebase.
How often should a vulnerability scan run?
Continuously or on every significant change is ideal. Quarterly or annual scanning leaves long windows where new vulnerabilities go undetected.