Vulnerability assessment tools discover assets, identify the software running on them, and match that against databases of known vulnerabilities, misconfigurations and policy deviations. They are good at known flaws at scale. They miss business logic bugs and cannot tell you alone which findings matter most.
How does a scanner find vulnerabilities?
NIST SP 800-115, its guide to security testing and assessment, describes the method. Scanners identify the operating systems and major software applications running on hosts and match them with information on known vulnerabilities stored in the scanner's database. This can reveal outdated software versions, missing patches and misconfigurations, and can check compliance with or deviation from a security policy. Some scanners perform their own network discovery and port and service identification.
That description explains both the strength and the weakness. A scanner is only as good as its identification of what is running and the currency of its database. If it guesses the version wrong, it reports flaws that are not there or misses ones that are.
What types of tools exist?
The categories differ in what they look at, not in quality.
Network and host scanners probe addresses and services, and with credentials can inspect installed packages and settings.
Web application scanners test a running application from the outside, as in dynamic testing. They find issues like missing headers or injection points reachable through the interface.
Dependency and software composition scanners read manifests, lockfiles and built artifacts to identify third-party components and match them to known vulnerabilities. They work on code before it runs.
Container and image scanners look at the layers of an image and the packages inside.
Cloud configuration scanners compare resource settings with a policy.
Most programs need more than one, because each sees a different layer.
What do they miss?
Assessment is not penetration testing. NIST separates target identification and analysis techniques, which include scanning, from target vulnerability validation techniques, which include penetration testing and password cracking, used to confirm that a weakness can actually be exploited. A scan lists possible weaknesses. A validation step shows which are real.
Scanners also have no understanding of your business logic. A flaw such as letting one customer read another's invoice by changing a number in a URL has no signature in a database.
How do you rank what the scan finds?
A severity score alone gives long lists. Two public signals help. The CISA Known Exploited Vulnerabilities Catalog names flaws seen exploited in real attacks. FIRST's Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days, with a score published daily. Add your own context: is the vulnerable code reachable, is the asset exposed, what does it hold.
A constructed example
A scan of 400 hosts reports 3,200 findings. The team filters to internet-facing hosts, then to findings in the KEV catalog or with a high EPSS score, which leaves 14. Of those, a credentialed check shows nine are false positives because a vendor backported the fix without changing the version string. Five are real, three of them on one load balancer. Patching that device removes most of the real risk. Without filtering, the team would have started at the top of a 3,200 line list.
How to check or apply this
- Inventory first. You cannot assess assets you do not know about.
- Match tool types to layers: hosts, web apps, dependencies, images and cloud settings.
- Use authenticated scans where possible. They see installed packages and settings and generate fewer false positives.
- Test any candidate on a known environment and count what it finds, misses and gets wrong.
- Rank with exploitation signals and exposure, then assign owners and dates.
- Retest after fixes, and track time to fix.
- Schedule penetration testing for what scanners cannot see, such as logic flaws.
For application code, Safeguard provides dependency and SBOM scanning, reachability analysis to show which flagged components your code actually calls, and a free in-browser scan at gold.safeguard.sh/scan that checks up to 100 dependencies. It covers the software composition layer, not network or cloud scanning.
Quick check
How often should we run vulnerability scans?
Often enough that new issues are caught before attackers use them. Many teams scan continuously for dependencies and weekly or monthly for infrastructure. Some regulations set minimums, such as every six months for certain financial institutions in the US.
Is a clean scan proof of security?
No. It means the scanner found no known issues in what it could see. Unknown flaws and logic errors are outside its reach.
Sources
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- FIRST, Exploit Prediction Scoring System
- CISA Known Exploited Vulnerabilities Catalog
- 16 CFR Part 314, Standards for Safeguarding Customer Information
Last reviewed: 18 October 2026.
