Home / Knowledge hub / Vulnerability scanning
Knowledge hub
Vulnerability scanning
Automated checks that look for known weaknesses without proving they can be used.
What it means
Vulnerability scanning is the use of automated tools to check systems and applications for known weaknesses. A scanner probes your servers, services or website, compares what it sees to a database of known issues and misconfigurations, and lists likely matches.
It is quick, repeatable and cheap to run often. It generally reports what looks vulnerable, but it does not prove that anyone can use the weakness. That is why scanner output needs review, and why it is not the same thing as a penetration test.
Why it matters
Scanning finds the routine problems early: outdated software, missing patches, exposed services, weak settings. Fixing those quickly removes the easy targets that automated attacks look for, and it costs little when done regularly, since the tool does the repetitive work for you.
It also supports compliance. For example, PCI DSS expects regular external scans by an approved scanning vendor. But a clean scan is not proof of safety. A scanner has a poor view of business logic, so it can miss flaws that cost real money, such as one customer reading another's data.
How it shows up
You meet scanning as an infrastructure scan, a web application scan, or a check inside the build pipeline. Results often arrive as a long list, ranked by a generic score, with many false positives mixed in. Someone has to triage it.
Scan on a schedule and after major changes. Cover the systems you forgot about as well as the ones you remember. Sort by exploitability, not only by score, and track items to closure. Pair scanning with testing that proves impact, such as a penetration test.
Questions people ask
Vulnerability scanning, answered
Is vulnerability scanning the same as penetration testing?
No. A scan finds possible weaknesses automatically. A penetration test tries to use them, chains them together and shows the real impact. A scan lists what might be wrong; a test shows what is.
How often should we scan?
At least monthly for most systems, and after any significant change. External-facing systems under PCI DSS need scans at least quarterly. More often is better where the cost is low.
Why does a scanner report things that are not real?
It matches signs, such as a version number, without confirming that the weakness can be used. The server may be patched in a way the scanner does not detect, or protected elsewhere.
Can a scanner find business-logic flaws?
Rarely. Logic flaws, such as a coupon that can be used twice or one customer reading another's record, depend on how your app is meant to work. A scanner does not know the intent.
Is a clean scan enough for an audit?
It depends on the audit. Some require scan reports, and some also require a penetration test. A clean scan alone does not show that logic and access flaws are absent.
Sources
Where this comes from
Related
Terms that sit next to this one
Authenticated scan
A scan that signs in first so it can see behind the login.
Penetration test
A time-boxed engagement where skilled people attack your systems by hand.
False positive
A reported issue that turns out not to be real.
DAST
Tools that attack a running application from the outside.
Vulnerability management
The loop of finding, prioritising, fixing and checking the fix held.
Is it real, or just reported?
A scanner reports what looks vulnerable; we report what we exploited. Each finding carries the request, the response and, where a person can see it, a screenshot. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.