What is vulnerability scanning?
Vulnerability scanning is the automated process of discovering, inspecting, and cataloging security weaknesses across software, hardware, and cloud environments. Security teams use scanning systems to match active system states against public intelligence feeds such as the National Vulnerability Database (NVD) and vendor security advisories. This proactive verification helps organizations maintain robust security hygiene and fulfill regulatory compliance requirements.
In the modern AI era, the definition of an enterprise computing asset extends far beyond traditional servers and virtual machines. Organizations now deploy large language models, automated agentic pipelines, and machine learning inference workloads alongside containerized microservices. Vulnerability scanning has evolved to protect this expanded perimeter, inspecting machine learning frameworks, model dependencies, and training infrastructure for structural flaws and supply chain tampering.
Modern technology stacks require continuous visibility across cloud, SaaS, on-premises, and hybrid environments. Because cloud configurations, software packages, and AI services evolve through daily deployments, vulnerability scanning provides the technical baseline required to locate out-of-date components and inadvertent exposures across every operational tier.
Vulnerability Management Buyer's Guide
Compare modern scanning solutions and cut through the alert noise. Get the core evaluation criteria and key technical questions to choose the right platform for your cloud environment.
What vulnerabilities does a scan uncover?
Vulnerability scanning and penetration testing answer different questions.
The specific vulnerabilities a scan uncovers depend on which type of scan you run, and the most effective programs combine several types to cover these common areas of weakness.
Network: Open ports, weak passwords, misconfigured firewalls, and unauthorized devices or connections.
System: Missing patches, outdated software, misconfigurations, and vulnerable operating systems.
Application: Security flaws including cross-site scripting (XSS) and SQL injection, plus misconfigured settings.
Cloud-specific: Misconfigured cloud services, overprivileged identity and access management (IAM) roles, exposed object storage such as Amazon S3 buckets or Azure Blob containers, and improper authentication.
How vulnerability scanning works
Vulnerability scanning works by identifying weaknesses across code and runtime environments, then narrowing those findings to the vulnerabilities that could realistically be exploited. In modern environments, the goal isn't to produce a long list of issues, but to understand which weaknesses actually increase risk.
Here’s a snapshot of how scanning for vulnerabilities works.
Identifying what is present and in use
Accurate scanning requires knowing what actually exists in your environment. This means maintaining visibility into source code and dependencies during build, container images and workloads at deployment, and cloud resources in production. Without this foundation, vulnerability data becomes misleading, since a scanner can only report on what it sees, and incomplete asset inventory means incomplete findings.
Detecting known vulnerabilities across the stack
Once assets are identified, scanners evaluate them for known vulnerabilities across application code, open source libraries, operating systems, container images, and cloud services. Most scanners work by identifying what's installed or exposed, then matching it against vulnerability intelligence sources like the National Vulnerability Database and CVE.org, which catalog product names, impact metrics, severity ratings, and recommended mitigations.
At this stage, scanning is intentionally broad. The goal is to surface potential weaknesses wherever they exist, knowing that not all findings will represent meaningful risk on their own.
Evaluating exploitability through context
This is where modern scanning diverges from traditional approaches. A vulnerability's importance depends on whether it can actually be exploited, not just whether it exists. Exploitability depends on several factors.
Is the vulnerable asset actually running in production, or does it sit in an unused image?
Is the asset reachable from the internet, or is it isolated behind internal controls?
What access does the asset have to other systems through its permissions and identities?
Is sensitive data nearby or directly accessible from the vulnerable asset?
Could an adversary realistically chain this weakness together with other findings to form a working attack path?
Severity scores like CVSS describe how bad a vulnerability could be in theory, but they don't account for whether it's likely to be targeted. The Exploit Prediction Scoring System (EPSS), maintained by the Forum of Incident Response and Security Teams, addresses this gap by estimating the probability that a given CVE will be exploited in the next 30 days, giving you another signal alongside CVSS when context-based prioritization isn't fully available. Scanning that lacks this context produces noise, not insight.
Updating findings as environments and threats change
Both environments and vulnerability intelligence change continuously. New vulnerabilities are disclosed, code is updated, and workloads are redeployed. Effective scanning revisits exploitability as these conditions evolve. A vulnerability that was previously low risk may become exploitable due to a configuration change, while others may become irrelevant once assets are removed or updated.
Validating remediation and reducing repeat exposure
After vulnerabilities are addressed, rescanning helps confirm that fixes were effective. Over time, this feedback loop helps you understand where vulnerabilities tend to reappear and where preventive controls can reduce repeat exposure. In this way, vulnerability scanning supports not just detection, but a clearer understanding of how exploitable risk enters and exits the environment.
Types of vulnerability scanning and common use cases
Vulnerability scanning relies on two core techniques.
Active scanning sends simulated attacks, queries, or requests to targets to identify weaknesses like buffer overflows, unencrypted data, and broken authentication.
Passive scanning analyzes network traffic without actively probing, detecting vulnerabilities attackers could use to spread malware or exfiltrate data.
Beyond technique, scans also differ based on what they target and how much access they're granted. The most common use cases include the following.
Network vulnerability scanning examines the network for open ports, unpatched software, and weak network protocols.
Web application vulnerability scanning looks for security flaws like SQL injection, XSS, and other vulnerabilities unique to web applications.
Container and cloud-native scanning covers your environment across three layers: image scanning checks container images for known vulnerabilities before deployment, registry scanning monitors stored images for newly disclosed CVEs, even after they've been pushed, and runtime scanning evaluates containers and virtual machines as they actually execute. Together, these layers close the gap between what a development team builds and what's actually running in production, which is the area where legacy network scanners tend to have the largest blind spots.
Database vulnerability scanning concentrates on identifying weaknesses within databases, such as misconfigurations, weak authentication, and overly permissive permissions.
Host vulnerability scanning examines individual servers or workstations to identify weaknesses at the operating system level or within installed software.
Infrastructure as code (IaC) scanning analyzes templates like Terraform or CloudFormation before deployment, catching misconfigurations such as overly permissive security groups or unencrypted storage while they're still cheap to fix.
API scanning identifies exposed endpoints, broken authentication patterns, and excessive data exposure in APIs, which have become a frequent target as applications increasingly communicate through them.
Scans also vary by access level and vantage point. Authenticated scans use valid credentials to log in and assess a system from the inside, surfacing issues like weak internal configurations that an outside view would miss, while unauthenticated scans probe a system the way an attacker without credentials would. Similarly, internal scans assess your network from inside the perimeter, and external scans assess what's visible to anyone on the internet.
Most mature programs run all four combinations, since each reveals a different slice of your actual exposure.
Vulnerability scanning vs. penetration testing
Vulnerability scanning and penetration testing serve different purposes. Scanning is automated and continuous, providing broad coverage across your environment as it changes. Penetration testing is manual and time-bound, simulating real-world attacks to validate whether specific weaknesses can actually be exploited.
The two approaches complement each other. Scanning maintains ongoing awareness of potential weaknesses, while pen testing provides deeper validation of how attackers might chain issues together in realistic scenarios.
| Activity | Best at | Typical output |
|---|---|---|
| Vulnerability scanning | Broad coverage and fast detection of known issues | A list of findings to fix or validate |
| Penetration testing | Proving real attack paths and business impact | Exploit evidence and prioritized remediation steps |
Watch 12-min demo
See how Wiz eliminates scanning blind spots and alert fatigue by connecting vulnerabilities to real cloud context.
Common vulnerability scanning challenges
A vulnerability scanning program can fall short for several reasons, and the table below outlines the most common ones.
| Challenge | Description |
|---|---|
| Resource sharing | Vulnerability scanning requires significant network bandwidth and computing resources. Production environments are also resource-intensive, and when both processes compete for the same infrastructure, scan efficiency suffers. |
| False positives | Scanners may flag non-existent vulnerabilities, wasting time on issues that don't actually exist. Misconfigurations in scan policies often cause these false alarms. |
| Alert fatigue | Thousands of alerts make it overwhelming to track and address each one. Teams start ignoring findings, and critical vulnerabilities get lost in the noise. |
| Siloed tooling | Using separate scanners across environments creates data silos and fragmented views of risk, and teams struggle to correlate findings across their stack. |
| Lack of context | Most scanners don't account for asset criticality, business processes, or system dependencies, so they report CVEs without explaining which ones actually increase risk. |
| Blind spots | Traditional tools often miss cloud infrastructure, containers, serverless functions, and other modern workloads, leaving gaps in coverage. |
| Ongoing maintenance efforts | Agent-based scanning solutions require installing agents on target systems, and managing their installation, updates, and maintenance across environments can become time-consuming. |
| Software development delays | Traditional scanning practices require extensive scans and manual verification, which can delay application development and ultimately hurt an organization's bottom line. |
| Supply chain integrity | Organizations need to verify the integrity of their scanning tools, not just their scan results. In March 2026, attackers compromised the open source Trivy scanner, injecting credential-stealing code into official releases and GitHub Actions used by thousands of CI/CD pipelines, which shows how a compromised security tool can become an attack vector itself. |
| CVSS-only prioritization | Relying on severity scores without exploitability context produces a backlog that doesn't reflect actual risk. EPSS adoption is growing as a complement to CVSS for exactly this reason. |
Secure vulnerability management from pull request to cloud runtime
Wiz unifies vulnerability management by connecting code, cloud infrastructure, and runtime environments into a single context graph. Through agentless workload scanning, Wiz leverages cloud-native API snapshots to analyze operating systems, open-source packages, and container images across cloud, on-premises, and hybrid architectures with zero compute overhead. Upstream, Wiz Code embeds vulnerability and dependency checks directly into CI/CD pipelines, stopping unmitigated risks before they reach production.
To eliminate alert fatigue, the platform pairs static discovery with active runtime reachability. The lightweight, eBPF-based Wiz Sensor inspects Kubernetes and Linux workloads to confirm whether vulnerable packages are actively executing in memory or dormant on disk. The Wiz Security Graph then correlates these findings with external attack surface exposure, IAM entitlements, and sensitive data to isolate critical toxic combinations from background noise. Through Wiz AI-APP, this context-aware protection extends to AI pipelines, securing machine learning models, inference stacks, and training data stores alongside conventional workloads.
Book a demo to see how context and vulnerability management all work together for more effective security.
Move from vulnerability lists to exploitable risk
Wiz correlates vulnerabilities with exposure, identities, and data access so your team fixes what actually matters.
