A vuln scan — short for vulnerability scan — is an automated check of code, dependencies, containers, or running systems against known weaknesses and misconfigurations, producing a list of findings ranked roughly by severity. That's the one-sentence version. The rest of this is the reference sheet: which scan type checks what, how often to run each, and where teams most often get the setup wrong.
What does a vuln scan actually check?
It depends entirely on scan type, which is the single most common point of confusion. A vulnerability scan is not one thing — it's a category that includes static code analysis, dependency analysis, container image analysis, and live application testing, each of which looks at a completely different artifact:
| Scan type | What it checks | Common tools |
|---|---|---|
| SAST (static) | Source code, without running it | Semgrep, CodeQL, Checkmarx |
| SCA (composition) | Open-source dependencies and their known CVEs | Snyk, Safeguard, OWASP Dependency-Check |
| DAST (dynamic) | A running application, from the outside | OWASP ZAP, Burp Suite |
| Container scanning | OS packages and layers in an image | Trivy, Grype |
| Infrastructure scanning | Cloud config and IaC templates | Checkov, tfsec |
A team that runs SAST and calls it "we do vulnerability scanning" is covering roughly a fifth of the actual attack surface.
How often should each type run?
As close to continuously as your pipeline allows, but with different practical cadences:
- SCA and container scanning should run on every build and ideally also on a daily cron against what's already deployed, since new CVEs get disclosed against packages you already shipped, not just ones you're about to ship.
- SAST should run on every pull request, since catching an issue at diff-review time is cheaper than catching it after merge.
- DAST typically runs on a schedule (nightly or per-deploy to staging) because it requires a live target and takes longer than a static check.
- Infrastructure/IaC scanning should gate the merge itself — a misconfigured S3 bucket policy or overly permissive security group is cheaper to catch in a pull request than in a cloud audit.
What's the difference between a vulnerability and a finding you can ignore?
Not every scan result needs a fix, and treating them as equally urgent is how alert fatigue kills a scanning program. A scanner reports a "finding" whenever a pattern matches — a known-vulnerable package version, a risky code construct, an open port. Whether that finding is exploitable in your specific deployment depends on context the scanner usually doesn't have: is the vulnerable function actually reachable from user input, is the package even loaded at runtime, is the port exposed to anything untrusted. Reachability analysis and runtime context are what separate a useful scan output from a backlog nobody triages.
What should you actually do with scan results?
Triage by exploitability and exposure, not raw CVSS score alone:
- Prioritize anything with a known public exploit or that's in CISA's Known Exploited Vulnerabilities catalog — that's a different risk tier from "critical but no exploit exists."
- Deprioritize findings in code paths that are genuinely unreachable, but document why rather than silently dismissing them.
- Set a policy gate (fail the build on new critical/high findings with an available fix) so triage happens before merge, not in a quarterly cleanup sprint.
Safeguard combines SCA and SAST/DAST scanning with reachability analysis, so a vuln scan produces a ranked, exploitability-aware list rather than a flat CVE dump.
FAQ
What's the difference between a vulnerability scan and a penetration test?
A vulnerability scan is automated and broad — it checks for known patterns across code, dependencies, and infrastructure. A penetration test is manual (or semi-manual) and narrow — a tester actively tries to exploit a specific target, often going deeper than any automated scan can.
Do free vuln scanners exist?
Yes — many SAST, SCA, and container scanning tools have usable free or open-source tiers (OWASP Dependency-Check, Trivy, Semgrep's free rule set), though most cap depth, integrations, or team features behind a paid tier.
How long should a vuln scan take?
SCA and container scans typically complete in seconds to low minutes per build. SAST scales with codebase size and can take longer on very large monorepos. DAST scans against a full application can take anywhere from minutes to hours depending on scope.
Does a clean vuln scan mean the application is secure?
No — it means no known issues were found by that scan type, on that day, against that scan's rule set. New CVEs are disclosed daily, and no scanner catches every class of vulnerability, which is why scanning is one layer of a broader security program, not the whole program.