Vulnerability scan
A vulnerability scan is an automated check of systems against a database of known weaknesses. What scanners find, what they miss, and how to use them well.
Updated This page as Markdown
In short
A vulnerability scan is an automated test in which a tool probes hosts, services or applications and compares what it sees against a database of known vulnerabilities (CVEs) and insecure configurations. It is fast, repeatable and cheap, which makes it the right tool for continuous monitoring of large estates. It cannot find logic flaws, authorisation errors or anything unknown to its database, and it produces false positives that need triage.
What is a vulnerability scan?
A vulnerability scan is an automated test: a tool connects to hosts, services, containers or web applications, identifies software and versions, and matches them against a database of known vulnerabilities (CVEs) and insecure configurations. The output is a list of findings with a CVSS score, usually hundreds or thousands of them on a first run. NIST SP 800-115 describes vulnerability scanning as a target identification and analysis technique: it tells you what is there and what is publicly known to be wrong with it.
Scans come in several forms. Unauthenticated network scans see what an outsider sees. Authenticated scans log in to the host and read installed packages, which is far more accurate. Web application scanners crawl and fuzz HTTP parameters for injection and configuration bugs. Container and dependency scanners read manifests and SBOMs rather than running systems.
Where is it defined?
Scanning is a technique, not a standard, but several frameworks require it. NIST SP 800-115 (Section 4.3) describes the method and its limits. NIST SP 800-40 Revision 4 places scanning inside enterprise patch management. NIS2 Article 21(2)(e) asks for “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”, which in practice means knowing your vulnerabilities continuously. The Cyber Resilience Act obliges manufacturers to identify and document vulnerabilities and components in their products (Annex I, Part II, point 1), and a dependency scan against the SBOM is how most do it. CISA’s Known Exploited Vulnerabilities catalogue is the common filter for what to fix first.
What it means in practice
A scan is the baseline, not the test. What we see when customers hand us their scan results before a penetration test:
- Volume hides priority. A first scan of a mid-sized network returns thousands of findings. Most are duplicates, informational or unreachable. Triage by exposure and by exploitation in the wild (KEV) before you sort by CVSS.
- False positives and false negatives both exist. Version-based detection flags a backported fix as vulnerable and misses a vulnerable service on a non-standard port. Authenticated scans fix most of the first problem and none of the second.
- Scanners do not understand your application. An IDOR that leaks another customer’s invoice, a missing authorisation check on an admin endpoint, a weak password-reset flow: none of these is in a database. The same applies to embedded devices. A scanner sees an open port 502; it does not know that the PLC behind it accepts unauthenticated writes.
Used well, scanning runs weekly or on every build, feeds a vulnerability-management process with owners and deadlines, and tells you when a known bug appears in your estate. The penetration test then looks for what the scanner cannot see.
Common misunderstandings
A scan report is not a penetration test, even with a consultant’s cover page on it. The difference is not the tool, it is the human who reads the responses, chains findings and exploits them. A clean scan also does not mean a secure system; it means no known vulnerability was detected by that scanner on that day. And “vulnerability assessment” is used by vendors both for a plain scan and for a scan with manual verification, so ask what you are buying.
FAQ
Frequently asked questions
How often should I run vulnerability scans?
Internet-facing systems at least weekly and after every change, internal infrastructure monthly, and software dependencies on every build in the CI pipeline. The scan interval matters less than the process behind it: every finding needs an owner and a deadline.
Can a vulnerability scan damage production systems?
In office IT very rarely. In OT environments yes: older PLCs, controllers and network devices can crash or reboot on malformed or unexpected packets. For industrial networks we use passive discovery and run active scans only in agreed maintenance windows, device by device.
Which scanner should I use?
Zyberum does not sell or resell scanners. Open-source tools such as Greenbone/OpenVAS, Nuclei and Trivy cover most needs; commercial products add asset management, authenticated scanning at scale and reporting. Choose by the assets you have, then make sure someone actually reads the results.
Sources
Related pages
- GlossaryPenetration testA penetration test is an authorised, mostly manual attack on a system to find and prove exploitable vulnerabilities. Definition, types, process and the report.
- GlossaryCVECVE (Common Vulnerabilities and Exposures) gives every public vulnerability one ID. How CVE records are created, what they contain and how to use them.
- GlossaryCVSSCVSS, the Common Vulnerability Scoring System, rates how severe a vulnerability is from 0 to 10. What it measures, what it does not, and how to use it in a report.
- ComparisonsPenetration Test vs Vulnerability Scan: What Each Finds and When to Use WhichA vulnerability scan finds known weaknesses automatically; a penetration test finds what a scanner cannot. Differences in depth and cost, and when to use which.
- InsightsVulnerability Management: A Process That Works in PracticeHow to set up vulnerability management that holds: sources, triage with CVSS and exploit data, SLAs by severity, SBOM, coordinated disclosure and the duties the CRA adds.
- ServicesWe break in. You get the proof and the fix.Hands-on penetration testing by OSCP-certified engineers: IoT devices, ECUs, industrial systems, web, cloud and networks. Fixed-price offer after a 15-min call.
