Vulnerability scanning is an automated check that finds assets, identifies the software and settings on them, compares what it finds with databases of known flaws and reports matches. It tells you what is probably wrong. It does not prove that an attacker can exploit it, and it misses what it cannot see.
What are the steps?
- Discovery. The scanner finds hosts, services or code to examine: IP ranges, cloud accounts, container images, repositories.
- Identification. It works out what is running: operating system, service versions, libraries, configuration. Network scanners probe ports and read banners. Code and dependency scanners read manifests and lockfiles.
- Matching. It compares versions and settings with known vulnerability records and configuration rules.
- Verification, where supported. Some checks try a safe probe to confirm the flaw, others rely only on the version number.
- Reporting. Findings are scored, grouped and assigned for remediation.
- Rescan. After fixes, a new run confirms the problem is gone.
NIST SP 800-115, the technical guide to security testing and assessment, describes this kind of testing as a way to find vulnerabilities in a system or network and to verify compliance with a policy or other requirements, and it discusses the benefits and limitations of each technique.
What are the main kinds?
Network scans probe running services from the outside or inside. Host or authenticated scans log in and read the installed software and settings, which gives more accurate results than guessing from outside. Application scans test web apps and APIs. Dependency and container scans read the software inventory in code and images. Configuration scans compare settings with a baseline.
They answer different questions, so a program usually needs more than one.
Why do scanners get things wrong?
False positives happen when a version looks vulnerable but the vendor backported a fix without changing the version string, or the vulnerable feature is turned off. False negatives happen when the scanner cannot see the asset, cannot log in, or the flaw is too new to have a record.
Context is missing too. A scanner usually does not know whether a service is internet-facing, whether the vulnerable function is ever called, or whether a compensating control sits in front of it. That context decides priority.
A constructed example
A scan of a web server reports an old library version with a high severity flaw. A reviewer looks at the report and finds the library is a build tool dependency, not shipped in the final image, and the vulnerable function is never reached. Another finding on the same server, a medium-rated misconfiguration that exposes a management page to the internet, matters more.
The sorted list, not the raw one, drives the work.
How to check or apply this
- Start with an inventory. A scan of the wrong range gives a clean report on the wrong things.
- Prefer authenticated scans for hosts. Give the scanner a least-privilege read account.
- Scan on a schedule that matches change: after each build for code, weekly or daily for exposed services.
- Scan internet-facing systems more often. CISA's ransomware guidance advises regular vulnerability scanning, especially on internet-facing devices, to limit the attack surface.
- Triage with context: exposure, exploitation evidence, whether the code path is reached, and asset value.
- Assign each finding an owner and a due date based on risk.
- Rescan to confirm fixes and record the result.
- Track mean time to remediate and aged findings, and review them monthly.
Take care with scheduling. Some network checks can disturb fragile devices such as old industrial or medical equipment. Test on those with agreement from their owners.
Where does Safeguard fit?
Safeguard scans dependencies and builds an SBOM through the CLI or the web app, and reachability analysis shows whether your code calls the vulnerable path, which cuts the noise in dependency findings. The free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies if you want a quick look at one project.
Quick check
Is a vulnerability scan the same as a penetration test?
No. A scan is automated and broad, and reports likely issues. A penetration test uses human skill to chain weaknesses and prove impact. Many programs use both.
How often should we scan?
Match the pace of change. Code and dependencies on every build, exposed services at least weekly, and everything else on a regular schedule, then after any major change.
Sources
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- CISA StopRansomware: tips and guidance
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
Last reviewed: 18 October 2026.
