Vulnerability scanning is the automated process of inspecting software, dependencies, containers, and infrastructure for known security weaknesses — missing patches, insecure configurations, and code matching entries in databases like the National Vulnerability Database (NVD) or CISA's Known Exploited Vulnerabilities (KEV) catalog. A scanner doesn't guess; it fingerprints what's actually running (a package version, an open port, an OS build) and checks it against a list of documented flaws, each typically scored with a CVSS number from 0 to 10. The NVD published 40,009 new CVE records in 2024, up from roughly 29,000 in 2023, which is why manual review stopped being viable years ago. Vulnerability scanning spans several distinct disciplines — SAST for source code, SCA for open-source dependencies, DAST for running web apps, and container/infrastructure scanning for deployed workloads — and most security programs run several of these tools in parallel rather than relying on one.
What Does a Vulnerability Scanner Actually Do?
A vulnerability scanner enumerates the assets in scope, fingerprints their exact versions or configurations, and cross-references those fingerprints against a database of known flaws to produce a list of matches with severity scores. For a dependency scanner, that means parsing a lockfile like package-lock.json or pom.xml, resolving the full tree including transitive packages, and checking each resolved version against sources such as the NVD, the GitHub Advisory Database, and OSV.dev. For a network or infrastructure scanner, it means probing open ports and banner-grabbing service versions, then matching against tools like OpenVAS's or Qualys's signature sets. The output is a report of CVE IDs, each with a CVSS base score (0.1-10.0) and often an EPSS score estimating real-world exploitation probability within the next 30 days — a distinction that matters because CVSS measures theoretical severity, not the likelihood anyone will actually use a given flaw against you.
What Are the Main Types of Vulnerability Scanning?
There are four main types of vulnerability scanning, distinguished by what they inspect and when in the software lifecycle they run. Static application security testing (SAST) analyzes your own source code before it ever runs, looking for patterns like SQL string concatenation or hardcoded credentials. Software composition analysis (SCA) scans open-source and third-party dependencies for known CVEs — a real concern given that Synopsys's 2024 OSSRA report found open-source code in 96% of the 1,067 commercial codebases it audited. Dynamic application security testing (DAST) probes a running application from the outside, sending malformed requests to see how it responds, the way a remote attacker would. Container and infrastructure scanning inspects built images and cloud configurations for outdated base image layers, exposed secrets, and misconfigured IAM policies — Palo Alto Networks' Unit 42 found in its 2023 cloud threat report that 76% of organizations don't enforce MFA on cloud console users, a class of finding infrastructure scanners are built to catch.
How Often Should You Run a Vulnerability Scan?
Most compliance frameworks set a floor of quarterly external scans, but that cadence is far too slow for modern software delivery, where scanning needs to run on every commit and every build. PCI DSS Requirement 11.3 explicitly mandates internal and external vulnerability scans at least once every three months and after any significant network change; HIPAA and SOC 2 auditors typically expect the same minimum. But those requirements were written for infrastructure that changes quarterly, not codebases that ship dozens of times a day. A 2023 GitLab DevSecOps survey found that 41% of respondents want security scanning integrated directly into the CI/CD pipeline rather than run as a periodic, separate exercise, and teams that scan on every pull request catch a vulnerable dependency before it merges rather than months later during an audit. The practical answer: scan continuously in CI/CD, and treat the quarterly compliance scan as a floor, not a target.
What's the Difference Between Vulnerability Scanning and Penetration Testing?
Vulnerability scanning is automated and broad — it checks everything against known signatures in minutes to hours — while penetration testing is manual and narrow, with a human tester actively trying to chain flaws into a working exploit over days or weeks. A scanner will tell you that a server is running an Apache version with a published CVE; a penetration tester will try to actually use that CVE, combined with a misconfigured file share and a weak service account password, to get a shell and move laterally. Because manual pentests are expensive — typical engagements run $10,000-$50,000 and cover a fixed scope for a fixed window — most organizations run vulnerability scans continuously and reserve pentests for periodic point-in-time validation, often once or twice a year or ahead of a specific compliance milestone. Neither replaces the other: scanning catches the 95% of issues that are simple version or configuration mismatches, while pentesting validates the exploit chains a scanner can't reason about.
Why Do Vulnerability Scans Generate So Many False Positives?
Vulnerability scans generate high false-positive volume because most scanners match on package name and version alone, flagging a CVE even when the vulnerable function is never called by your application. Endor Labs' 2023 research on real-world Java and JavaScript projects found that only about 15-20% of dependencies flagged as vulnerable were actually reachable — meaning application code invokes the flawed function, directly or transitively. Container scanners have the same problem at a different layer: a base image might ship a vulnerable OpenSSL binary that's present on disk but never linked into the running process. The result is alert fatigue at scale — a 2022 ESG survey found the median enterprise carried a backlog of over 100,000 unresolved vulnerability findings across tool categories — and teams that can't distinguish reachable from theoretical risk end up either ignoring the backlog entirely or burning engineering hours chasing CVEs that were never exploitable in their environment.
What Should You Look for in a Vulnerability Scanner in 2026?
The capabilities that separate a modern scanner from a 2015-era signature matcher are reachability analysis, SBOM support, and automated remediation, in that order of impact on your actual fix rate. Reachability analysis traces call paths from your application entry points down into flagged dependencies, so a report of 400 CVEs becomes a report of the 30-60 that are genuinely callable — the difference between a backlog nobody touches and a queue engineers can clear in a sprint. SBOM support matters because Executive Order 14028 and the NTIA's minimum-elements guidance pushed CycloneDX and SPDX bill-of-materials delivery into U.S. federal software procurement starting in 2022, and that requirement has since spread into commercial vendor security questionnaires. Automated remediation — a scanner that can open a pull request with a tested version bump rather than just a ticket — is what actually moves the mean time to remediate, which the 2024 Verizon DBIR still measured in the range of weeks to months for internet-facing vulnerabilities at the median organization.
How Safeguard Helps
Safeguard runs reachability analysis on every vulnerability finding across your SAST, SCA, and container scans, so instead of a raw CVE list you get a ranked view of what's actually exploitable in your specific application — typically cutting alert volume by 80% or more. Griffin AI, Safeguard's reasoning engine, investigates each reachable finding against your real usage pattern, explains the exploit path in plain language, and drafts the fix, including transitive dependency conflicts that would break a naive version bump. Safeguard generates CycloneDX and SPDX SBOMs automatically on every build and can ingest SBOMs from vendors and upstream suppliers, so you have one inventory instead of a spreadsheet per supplier. When a fix exists, Safeguard opens an auto-fix pull request with the minimum safe change and a passing build, so scanning results in merged fixes instead of another row in a backlog nobody has time to clear.