How to Scan for Vulnerabilities in 2026

Knowing how to scan for vulnerabilities is one of the most practical skills in cybersecurity. Whether you are a developer hardening your own application, a sysadmin responsible for a fleet of servers, or a security professional running assessments for clients, the process follows the same fundamental steps: define your scope, choose your tools, configure and run the scan, analyze the results, and prioritize remediation.

This guide walks through each step in detail, covering both manual command-line approaches and automated platforms that orchestrate dozens of tools for you.

Step 1: Define Your Scan Scope

Before you touch a scanner, answer three questions:

1. What am I scanning? -- A single web application? An IP range? A domain and all its subdomains? The scope determines which tools you need and how long the scan will take.
2. What am I authorized to scan? -- Scanning systems you do not own or have explicit permission to test is illegal in most jurisdictions. Get written authorization before scanning anything you do not control.
3. What am I looking for? -- Network-level vulnerabilities (open ports, outdated services)? Web application flaws (injection, XSS)? Configuration issues (missing headers, weak TLS)? Or all of the above?

A well-defined scope prevents wasted effort. Scanning an entire /16 network range with a web application scanner will not produce useful results. Conversely, running only a port scan against a complex web application misses the most interesting attack surface.

Step 2: Choose Your Scanner Type

The vulnerability scanning landscape breaks down into three broad approaches, each with trade-offs.

Manual CLI Tools

Tools like Nmap, Nuclei, and sqlmap give you fine-grained control. You choose exactly which checks to run, how aggressively to probe, and how to handle edge cases. The learning curve is steep, but the flexibility is unmatched.

# Network scan with service detection and vulnerability scripts
nmap -sV --script=vuln -oX results.xml target.example.com

# Template-based vulnerability scanning with Nuclei
nuclei -u https://target.example.com -t cves/ -severity critical,high

# Web application crawling and testing with OWASP ZAP (CLI mode)
zap-cli quick-scan -s all https://target.example.com

The problem with manual tools is orchestration. A thorough assessment requires running 10-20 different tools in the right order, feeding output from one into the next, and correlating results across all of them. This is where most teams either burn hours of manual work or leave gaps in coverage.

Commercial Scanners

Products like Nessus, Qualys, and Burp Suite provide polished interfaces and large vulnerability databases, compliance reporting, and support contracts. They are easier to operate but less flexible, and they typically charge per-asset or per-scan pricing that scales quickly.

Automated Orchestration Platforms

A newer category of platform -- including Metric Tower -- combines dozens of open-source and commercial scanning tools under a single interface, automatically orchestrating them in dependency order. You point the platform at a target; it runs subdomain discovery, port scanning, web crawling, vulnerability scanning, and specialized checks in sequence, piping results between tools and deduplicating findings.

This approach gives you the breadth of manual tools with the ease of a commercial scanner. Metric Tower, for example, orchestrates 58 modules -- from Nmap and Nuclei to ZAP and sqlmap -- in a dependency-aware DAG (directed acyclic graph) where each phase feeds its results to the next.

Step 3: Configure Your Scan

Configuration is where most scans either succeed or fail. Key decisions include:

Scan Intensity

Most scanners offer intensity levels (sometimes called profiles or policies). A light scan checks common ports and known CVEs -- fast but shallow. A deep scan tests every port, runs comprehensive fuzzing, and uses large wordlists for directory brute-forcing -- thorough but slow and potentially disruptive.

Start with a medium intensity for your first scan. You can always increase depth once you understand the baseline.

Authentication Credentials

If you are scanning a web application, providing valid login credentials lets the scanner test authenticated pages and features. Without credentials, the scanner can only test the login page and any unauthenticated endpoints -- missing the majority of the attack surface.

For network scans, SSH or WinRM credentials enable authenticated vulnerability checks that are far more accurate than banner-based detection.

Exclusions and Rate Limiting

Some endpoints should not be scanned: password reset functions (the scanner will spam real users), delete endpoints (the scanner might destroy data), and third-party services (you do not own them). Configure exclusion paths before scanning.

Rate limiting is equally important. A scan that sends 1,000 requests per second to a production API will look (and act) like a denial-of-service attack. Set request rates that your infrastructure can handle without impacting real users.

Step 4: Run the Scan

With scope defined and configuration set, running the scan itself is usually the simplest step. The details depend on your tool choice.

Using Nmap for Network Scanning

# Quick scan of common ports with service detection
nmap -sV -sC -oA scan-results target.example.com

# Full port scan (all 65535 ports) with OS detection
nmap -p- -sV -O -oA full-scan target.example.com

# Scan a subnet
nmap -sV --top-ports 1000 10.0.0.0/24

Using Nuclei for CVE and Misconfiguration Detection

# Scan for critical and high severity CVEs
nuclei -u https://target.example.com -severity critical,high

# Scan with all templates (comprehensive but slow)
nuclei -u https://target.example.com -t .

# Scan a list of URLs from a file
nuclei -l urls.txt -severity critical,high,medium

Nuclei's template system is one of the most powerful concepts in modern vulnerability scanning. Each template is a YAML file that describes exactly how to detect a specific vulnerability. The community maintains over 11,000 templates covering CVEs, misconfigurations, exposed panels, default credentials, and more. You can also write custom templates for your own applications.

Using an Automated Platform

With an orchestration platform like Metric Tower, you provide the target URL or domain and select which modules to run. The platform handles tool orchestration automatically: subdomain discovery feeds DNS resolution, which feeds port scanning, which feeds vulnerability detection. Results stream in real time as each module completes.

The advantage of this approach is that you get coverage across 58 tools without needing to install, configure, or orchestrate any of them. The platform runs each tool in an isolated sandbox, passes results between phases, and deduplicates findings into a unified view.

Step 5: Analyze and Prioritize Results

A scan might return hundreds of findings. The temptation is to try to fix everything at once. Resist it. Effective vulnerability management requires prioritization.

Understanding CVSS Scores

The Common Vulnerability Scoring System (CVSS) provides a standardized way to rate vulnerability severity on a 0-10 scale:

CVSS is a useful starting point, but it does not account for your specific environment. A CVSS 9.8 remote code execution vulnerability in a service that is behind a VPN and only accessible to three people is less urgent than a CVSS 7.5 SQL injection on your public-facing login page with millions of users.

Prioritization Factors

Beyond CVSS score, consider:

• Exploitability -- Is there a public exploit? Is it being actively exploited in the wild? CISA's Known Exploited Vulnerabilities (KEV) catalog is a useful reference.
• Asset criticality -- Is the affected system a payment processor or an internal wiki? The business impact varies dramatically.
• Network exposure -- Is the vulnerability reachable from the internet or only from the internal network?
• Data sensitivity -- Does the affected system handle PII, financial data, or credentials?
• Remediation effort -- A configuration change that takes five minutes should be fixed immediately, even if its CVSS score is moderate.

Step 6: Remediate and Verify

Fixing vulnerabilities is the entire point. Scanning without remediation is security theater.

For each finding, determine the appropriate action:

• Patch -- Update the affected software to a version that addresses the vulnerability.
• Configure -- Add missing security headers, disable unnecessary services, restrict network access.
• Mitigate -- If a patch is not available, apply compensating controls (WAF rules, network segmentation, monitoring).
• Accept -- For low-risk findings where the cost of remediation exceeds the risk, document the acceptance decision with justification.

After remediating, rescan to verify. Many teams fix a vulnerability only to introduce a new one in the process, or apply a fix that does not actually resolve the issue. A verification scan confirms that the fix worked and that nothing else broke.

Automating Vulnerability Scanning

The six steps above work for manual assessments, but manual scanning does not scale. For ongoing security, you need automation.

CI/CD Integration

Embed vulnerability scanning into your deployment pipeline. Run scans against staging environments before promoting to production. Fail the build if critical or high vulnerabilities are detected. This shifts security left -- catching issues when they are cheapest to fix.

# Example: Metric Tower CI scan via API
curl -X POST https://app.metrictower.com/api/v1/scans \
  -H "Authorization: Bearer $METRICTOWER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "target": "https://staging.example.com",
    "modules": ["nuclei", "http-headers", "web-security", "sensitive-files"],
    "configuration": {
      "scan_intensity": "medium",
      "fail_on_severity": "high"
    }
  }'

Scheduled Scans

Set up recurring scans that run daily, weekly, or monthly without manual intervention. Scheduled scans catch regressions -- a security header that was removed during a refactor, a new service exposed after a configuration change, or a newly published CVE that affects software you have already deployed.

Finding Deduplication

When you scan the same target regularly, you need deduplication. Without it, the same missing CSP header shows up as a new finding every scan, burying genuinely new issues in noise. Good platforms track findings by fingerprint, marking each as new, repeated, regressed (was fixed, came back), or resolved.

Common Mistakes to Avoid

After years of running and reviewing vulnerability scans, certain anti-patterns come up repeatedly:

• Scanning production without warning -- Always coordinate with operations. Some scan types (especially aggressive fuzzing) can cause service degradation.
• Ignoring scan configuration -- Running a default scan with no customization misses authenticated endpoints and wastes time on irrelevant checks.
• Treating all findings equally -- A list of 500 findings sorted alphabetically is useless. Prioritize by risk, not by quantity.
• Scanning once and calling it done -- Your attack surface changes constantly. A scan from six months ago reflects a system that may no longer exist.
• Not validating fixes -- A ticket marked "resolved" means nothing until a rescan confirms the vulnerability is gone.

For help choosing the right scanner for your needs, see our comparison of the top vulnerability scanning tools. And if you want to understand the fundamentals before diving into tools, our introduction to vulnerability scanning covers the core concepts.