Vulnerability Scanner Tuning -- CVSS 4.0 / CWE

Frameworks: CVSS 4.0 (FIRST.org), CWE (MITRE) Role: Security Engineer Time: 30-60 min Output: Tuned scan policy configuration, false positive analysis, severity override documentation, and cross-scanner correlation report

---

When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Use this skill when vulnerability scan results contain excessive false positives, when configuring or reconfiguring scan policies for new environments, when evaluating whether to use authenticated vs unauthenticated scanning, when scanner severity ratings do not align with actual risk, when onboarding a new scanner or comparing results across multiple scanners, or when scan performance (duration, resource consumption) needs optimization.

Do not use when: The task is triaging specific CVEs from scan output (use cve-triage), prioritizing patches from a remediation backlog (use patch-prioritization), or analyzing software composition (use sbom-analysis).

---

Context the Agent Needs

Before starting, collect or confirm:

• Scanner platform(s): Which scanner(s) are in use? (Qualys VMDR, Tenable Nessus/IO/SC, Rapid7 InsightVM/Nexpose, OpenVAS/Greenbone, Snyk, Trivy, Grype, Nuclei)
• Current scan policies: Existing scan policy names, configurations, and plugin/check selections
• Scan scope: Target IP ranges, hostnames, applications, containers, or cloud accounts
• Authentication status: Are scans currently authenticated (credentialed) or unauthenticated?
• False positive examples: Specific findings suspected or confirmed as false positives, with evidence
• Scan frequency: Current scan schedule and any performance constraints
• Result volume: Approximate number of findings per scan cycle and false positive rate if known
• Compliance requirements: Whether scans must meet specific compliance mandates (PCI ASV, DISA STIG, CIS Benchmark)
• Multi-scanner context: If using multiple scanners, which ones and how results are currently correlated

---

Process

Step 1: False Positive Identification and Classification

Systematically identify and classify false positives in scan results to establish tuning priorities.

Framework mapping: CWE (MITRE) for vulnerability classification

Common False Positive Patterns

Pattern	Description	Identification Method	CWE Example
Version-based detection without validation	Scanner detects a vulnerable version string but the specific vulnerable code/feature is not present (backported patch, custom build, or feature disabled)	Compare detected version against actual installed version; verify patch status via package manager (rpm -q, dpkg -l, apt list)	CWE-693 (Protection Mechanism Failure) misidentified
Banner-based detection	Scanner reads a service banner that reports an outdated version, but the software has been patched without updating the banner	Verify actual version via authenticated check; compare banner vs. binary version	CWE-200 (Information Exposure) false trigger
Protocol-level detection without exploit validation	Scanner flags a protocol vulnerability (e.g., SSL/TLS weakness) but the specific cipher suite or configuration is not actually in use	Review actual TLS configuration (openssl s_client, nmap --script ssl-enum-ciphers); compare against scanner finding	CWE-326 (Inadequate Encryption Strength) false match
OS/platform misidentification	Scanner misidentifies the target OS or platform, leading to inapplicable plugin results	Verify OS fingerprint; compare scanner-detected OS against actual OS	N/A -- detection error
Inherited/container base image findings	Scanner detects vulnerabilities in a container base image layer that are overridden or not reachable in the final image	Analyze Dockerfile layer order; verify whether vulnerable files exist in the final image	Context-dependent
Informational findings elevated to vulnerability	Scanner reports an informational check (e.g., service detected, open port) with a severity rating that implies vulnerability	Review plugin/check documentation; confirm whether the finding indicates an actual exploitable weakness	N/A -- severity error
Compensated vulnerability	A real vulnerability exists but a compensating control (WAF, IPS, network ACL) renders it unexploitable in the deployment context	Document compensating control; this is risk acceptance, not a false positive -- track separately	Context-dependent

False Positive Validation Workflow

For each suspected false positive:

1. Reproduce: Attempt to validate the finding independently (manual verification, second scanner, authenticated re-scan)
2. Classify: Determine the false positive pattern from the table above
3. Document: Record the CVE/plugin ID, affected asset, evidence of false positive, and verification method
4. Disposition: Mark as confirmed false positive, accepted risk, or true positive requiring remediation

False Positive Record:
- Scanner:             [Scanner name]
- Plugin/Check ID:     [ID]
- CVE ID:              [CVE-YYYY-NNNNN or N/A]
- CWE:                 [CWE-NNN or N/A]
- Affected Asset:      [hostname/IP]
- Scanner Severity:    [Critical/High/Medium/Low/Info]
- FP Pattern:          [Version-based | Banner | Protocol | OS Misidentification | Container | Informational | Compensated]
- Evidence:            [Specific evidence proving false positive]
- Verification Method: [Package manager check | Authenticated re-scan | Manual testing | Configuration review]
- Disposition:         [Confirmed FP -- suppress | Accepted Risk -- document | True Positive -- remediate]

Step 2: Scan Policy Configuration

Configure or optimize scan policies to balance detection coverage, accuracy, and performance.

Framework mapping: CVSS 4.0 (severity validation), scanner-specific policy frameworks

Policy Configuration Areas

2a. Plugin/Check Selection

Configuration	Guidance	Rationale
Enable all vulnerability checks	Start with the full plugin set, then selectively disable confirmed noise generators	Ensures coverage; avoids blind spots from overly aggressive tuning
Disable purely informational plugins (if not needed)	Informational checks (service detection, banner grabbing) generate volume without security findings	Reduces result noise; keep enabled if needed for asset inventory
Enable compliance checks	Enable CIS Benchmark, DISA STIG, or PCI checks only when compliance scanning is required	Mixing vulnerability and compliance scans inflates results and confuses triage
Local security checks	Enable all local/authenticated check families	These provide the most accurate results; require credentials (see Step 3)
Dangerous/intrusive checks	Disable DoS and exploit-verification plugins for production; enable for pre-production/test	Prevents scanner from causing production outages
Web application checks	Enable only when scanning web applications with appropriate scope limits	Web app plugins are slow and generate noise against non-web targets

2b. Scan Intensity and Performance

Setting	Recommended Value	Notes
Max simultaneous hosts	10-20 (internal), 5-10 (external/DMZ)	Higher values increase speed but may trigger IDS/IPS or cause target instability
Max checks per host	4-8	Balances thoroughness vs. target resource impact
Network timeout	5-10 seconds (internal), 15-30 seconds (external/cloud)	Too short = missed checks; too long = excessive scan duration
Port range	All TCP (1-65535) + top 1000 UDP for comprehensive; top 10000 TCP for routine	Full port scans take longer but catch services on non-standard ports
CGI scanning	Enable only for confirmed web servers	Scanning non-web hosts with CGI checks wastes time
Thorough/paranoid mode	Enable for high-value targets; disable for routine scans	Significantly increases scan duration

2c. Exclusions and Scope Management

Exclusion Type	When to Use	Documentation Required
Host exclusions	Fragile systems that crash under scan load (legacy SCADA, medical devices, IoT)	Risk acceptance document; alternative assessment method (passive monitoring)
Plugin exclusions	Confirmed persistent false positive across all assets for a specific plugin	False positive evidence for at least 3 scan cycles; periodic re-evaluation (quarterly)
Time-based exclusions	Systems that cannot be scanned during business hours	Scan scheduling adjustment (see Step 6)
Credential exclusions	Systems where credentialed scanning is not permitted by policy	Documented reason; accept reduced detection accuracy

Step 3: Authenticated vs. Unauthenticated Scanning

Evaluate and configure credential-based (authenticated) scanning for improved accuracy.

Framework mapping: CIS Controls v8 (Control 7: Continuous Vulnerability Management)

Comparison Matrix

Attribute	Unauthenticated (Remote)	Authenticated (Credentialed)
Detection accuracy	Low-Medium (60-70% of vulnerabilities)	High (90-95% of vulnerabilities)
False positive rate	Higher (relies on banners, remote probes)	Lower (validates installed versions directly)
Detection scope	Network-exposed services and configurations only	Installed packages, local configurations, file permissions, registry entries
Credential management	None required	Requires credential vault integration (CyberArk, HashiCorp Vault, scanner-native vault)
Performance impact	Lower (fewer checks)	Higher (more thorough checks per host)
Risk	Low (non-invasive)	Medium (credential exposure, elevated access)
Compliance	Insufficient for most compliance mandates (PCI, HIPAA, DISA STIG)	Required for PCI internal scanning, DISA STIG compliance

Credential Configuration Best Practices

1. Use service accounts: Dedicated scan service accounts with least-privilege access (read-only where possible, local admin/root only when required for patch-level detection)
2. Rotate credentials: Scan credentials should follow the same rotation policy as other service accounts
3. Vault integration: Store scan credentials in an enterprise secret management solution, not in the scanner's local credential store
4. Per-platform credentials: Maintain separate credentials for Windows (local admin or domain account), Linux/Unix (root or sudo-enabled account), network devices (read-only SNMP community/SSH), databases (read-only DB account), and VMware/cloud APIs
5. Credential verification: Run a credential verification scan before full scan to confirm authentication success across all targets

Authentication Configuration:
- Scan Type:           [Authenticated | Unauthenticated | Mixed]
- Credential Source:   [Scanner-native | CyberArk | HashiCorp Vault | Other]
- Windows Auth:        [Domain account: DOMAIN\svc-scan | Local admin | N/A]
- Linux Auth:          [SSH key (preferred) | SSH password with sudo | root | N/A]
- Network Devices:     [SNMPv3 (preferred) | SNMPv2c | SSH read-only | N/A]
- Database Auth:       [Read-only DB account | N/A]
- Cloud/API Auth:      [API key with read-only role | N/A]
- Credential Rotation: [Every N days]
- Last Verification:   [YYYY-MM-DD, success rate: [N]%]

Step 4: Severity Override Criteria

Define criteria for overriding scanner-assigned severity ratings when they do not reflect actual organizational risk.

Framework mapping: CVSS 4.0 Environmental Metrics (FIRST.org)

Legitimate Override Scenarios

Scenario	Direction	CVSS 4.0 Justification	Documentation Required
Internet-facing system with scanner-default internal context	Severity UP	Modified Attack Vector (MAV) = Network; no Modified Attack Requirements	Asset exposure evidence (perimeter scan, DNS records)
Air-gapped or segmented system	Severity DOWN	Modified Attack Vector (MAV) = Physical or Local; network path verified as blocked	Network diagram, firewall rule evidence, segmentation test results
High-value data system (PII, financial, health)	Severity UP	Confidentiality Requirement (CR) = High; Integrity Requirement (IR) = High	Data classification policy, asset inventory metadata
Non-production environment (dev, test, sandbox)	Severity DOWN	Mission Prevalence = Minimal (SSVC); Environmental score adjustment via reduced CR/IR/AR	Environment classification evidence; confirm no production data present
Compensating control fully mitigates	Severity DOWN (or suppress)	Environmental metrics adjusted to reflect effective mitigation	Compensating control evidence per Step 4 assessment; note this is risk-context adjustment, not a severity change to the vulnerability itself

Override Rules

1. Never override based on gut feeling: Every override must cite a specific CVSS 4.0 Environmental metric adjustment or documented business context
2. Document both the original and overridden severity: Maintain traceability from scanner-native severity to adjusted severity
3. Review overrides quarterly: Severity overrides must be re-evaluated as deployment context changes (e.g., system moved from internal to internet-facing)
4. Override scope: Overrides apply to a specific CVE + asset combination, not globally to a CVE across all assets

Severity Override Record:
- Scanner:             [Scanner name]
- Plugin/Check ID:     [ID]
- CVE ID:              [CVE-YYYY-NNNNN]
- CWE:                 [CWE-NNN]
- Asset:               [hostname/IP]
- Original Severity:   [Scanner severity and CVSS score]
- Overridden Severity: [Adjusted severity and CVSS 4.0 Environmental score]
- Override Direction:   [Up | Down | Suppress]
- Justification:       [Specific CVSS 4.0 metric adjustment or business context]
- CVSS 4.0 Vector:     [Full environmental vector string]
- Review Date:         [YYYY-MM-DD, quarterly]
- Approved By:         [Name, role]

Step 5: Cross-Scanner Result Correlation

When using multiple scanners, correlate results to improve confidence and identify coverage gaps.

Framework mapping: CWE for vulnerability classification, CVSS 4.0 for severity normalization

Correlation Method

1. Normalize identifiers: Map findings across scanners using CVE ID as the primary correlation key. For findings without CVE IDs, use CWE + affected component + vulnerability description as a composite key.
2. Severity normalization: Different scanners may assign different severity ratings to the same CVE. Use CVSS 4.0 Base score from NVD as the authoritative severity, not scanner-specific severity.
3. Confidence scoring: Assign confidence based on corroboration across scanners:

Confidence Level	Criteria	Action
High	Finding confirmed by 2+ scanners with consistent details	Treat as true positive; proceed to remediation
Medium	Finding reported by 1 scanner only; consistent with known vulnerability data (NVD, vendor advisory)	Likely true positive; validate with authenticated re-scan if not credentialed
Low	Finding reported by 1 scanner only; inconsistent with NVD data or contradicted by another scanner	Investigate further; likely false positive if contradicted
Conflict	One scanner reports vulnerable, another explicitly reports not vulnerable (patched) for the same asset+CVE	Requires manual investigation; re-scan with authentication; check patch status directly

4. Coverage gap analysis: Identify vulnerability classes or asset types that only one scanner detects. Common gaps:

Scanner Type	Typical Strength	Typical Weakness
Network scanner (Qualys, Tenable, Rapid7)	OS and network service vulnerabilities, authenticated patch checks	Application-level dependencies, container vulnerabilities
Container scanner (Trivy, Grype, Snyk Container)	OS package and language-specific library vulnerabilities in container images	Runtime configuration, network-level exposures
DAST scanner (OWASP ZAP, Burp Suite, Nuclei)	Web application vulnerabilities (XSS, SQLi, SSRF, auth flaws)	Infrastructure vulnerabilities, non-web services
SCA scanner (Snyk, Dependabot, Mend)	Third-party library vulnerabilities in source code	Infrastructure, OS-level, and runtime vulnerabilities

Cross-Scanner Correlation Summary:
- Scanners Correlated:     [List of scanners]
- Total Unique Findings:   [N] (after deduplication)
- High Confidence:         [N] (corroborated by 2+ scanners)
- Medium Confidence:       [N] (single scanner, consistent with NVD)
- Low Confidence:          [N] (single scanner, inconsistent data)
- Conflicts:               [N] (disagreement between scanners)
- Coverage Gaps Identified: [List by scanner and vulnerability class]

Step 6: Scan Scheduling Optimization

Configure scan schedules to balance coverage, freshness, and operational impact.

Framework mapping: CIS Controls v8 (Control 7.5: Perform Automated Vulnerability Scans of Internal Enterprise Assets), PCI DSS 4.0 (Requirement 11.3.1: Internal scans quarterly minimum)

Scheduling Matrix

Scan Type	Frequency	Timing	Targets
Full credentialed scan	Weekly	Maintenance window (off-peak hours)	All production and staging systems
Discovery/inventory scan	Daily	Low-impact; can run during business hours	All network segments
External perimeter scan	Weekly (minimum); daily for high-value targets	Any time (external scanners)	Internet-facing assets
Container image scan	Per-build (CI/CD integration) + weekly registry scan	CI/CD pipeline trigger + scheduled registry sweep	All container images
Web application scan (DAST)	Bi-weekly to monthly (per application risk tier)	Off-peak hours; coordinate with app team	Web applications by risk tier
Compliance scan (CIS, STIG, PCI)	Monthly to quarterly per mandate	Maintenance window	In-scope assets per compliance framework
Ad-hoc/emergency scan	As needed (new critical CVE, incident response)	Immediate	Targeted assets potentially affected by the specific vulnerability

Scheduling Best Practices

1. Stagger scan windows: Do not scan all assets simultaneously; distribute load across the scan window
2. Coordinate with change management: Schedule scans after patch windows to validate remediation
3. Avoid scanning during backups: Concurrent backup and scan operations degrade both
4. Monitor scan duration: Track scan completion times; investigate if scans consistently exceed expected duration (may indicate network issues, target instability, or policy misconfiguration)
5. Retain scan history: Maintain at least 13 months of scan results for trend analysis and compliance evidence

---

Findings Classification

Classify the overall scanner tuning state into one of the following:

Classification	Definition	Criteria
Poorly Tuned	Scanner produces unreliable results	False positive rate > 30%, unauthenticated only, no severity overrides documented, no cross-scanner correlation
Basic	Scanner operational but significant tuning gaps	False positive rate 15-30%, partial credential coverage, some ad-hoc overrides without documentation
Tuned	Scanner produces reliable, actionable results	False positive rate < 15%, full credentialed scanning, documented overrides, regular policy review
Optimized	Scanner program is mature and well-integrated	False positive rate < 5%, multi-scanner correlation, automated result ingestion, severity overrides with CVSS 4.0 justification, scan scheduling aligned with change management

---

Output Format

Produce a structured report with these exact sections:

## Scanner Tuning Report
**Date:** [YYYY-MM-DD]
**Skill:** scanner-tuning v1.0.0
**Frameworks:** CVSS 4.0, CWE
**Reviewer:** AI-assisted (human review required for policy changes and severity overrides)

### Executive Summary
[3-5 sentences. State the scanner(s) evaluated, current false positive rate estimate,
key tuning issues identified, authentication status, and overall tuning classification.
Highlight the most impactful tuning recommendations.]

### Scanner Configuration Summary

| Setting | Current State | Recommended State | Priority |
|---|---|---|---|
| Authentication | [Unauthenticated / Partial / Full] | [Full credentialed] | [High/Medium/Low] |
| Plugin Selection | [All / Custom / Compliance-mixed] | [Separated vuln and compliance policies] | [Priority] |
| Dangerous Checks | [Enabled / Disabled] | [Disabled for production] | [Priority] |
| Scan Frequency | [Current schedule] | [Recommended schedule] | [Priority] |
| Port Range | [Current range] | [Recommended range] | [Priority] |

### False Positive Analysis

| Plugin/Check ID | CVE ID | FP Pattern | Affected Assets | Evidence | Recommendation |
|---|---|---|---|---|---|
| [ID] | [CVE-ID] | [Pattern] | [N assets] | [Brief evidence] | [Suppress / Re-scan authenticated / Investigate] |

**Estimated False Positive Rate:** [N%]
**Top FP Contributors:** [List top 3-5 plugins generating the most false positives]

### Severity Overrides

| CVE ID | Asset | Original Severity | Adjusted Severity | Justification | Review Date |
|---|---|---|---|---|---|
| [CVE-ID] | [asset] | [severity] | [severity] | [CVSS 4.0 metric adjustment] | [date] |

### Cross-Scanner Correlation
[If multiple scanners are in use]

| Metric | Value |
|---|---|
| Scanners Correlated | [list] |
| Total Unique Findings | [N] |
| High Confidence (2+ scanners) | [N] ([%]) |
| Conflicts Requiring Investigation | [N] |
| Coverage Gaps | [list by scanner type] |

### Scan Schedule

| Scan Type | Current Schedule | Recommended Schedule | Targets |
|---|---|---|---|
| [type] | [current] | [recommended] | [scope] |

### Overall Tuning Classification
**Rating:** [Poorly Tuned | Basic | Tuned | Optimized]
**Rationale:** [2-3 sentences explaining the rating]

### Recommendations
1. [Highest-impact tuning recommendation]
2. [Second priority recommendation]
3. [Third recommendation]

### References
- CVSS 4.0 Specification: https://www.first.org/cvss/v4-0/
- CWE (MITRE): https://cwe.mitre.org/
- Scanner documentation: [URLs for specific scanner platforms]

---

Framework Reference

CVSS 4.0 (FIRST.org)

Common Vulnerability Scoring System version 4.0. Used in scanner tuning for severity validation and Environmental metric overrides. CVSS 4.0 introduces separate Vulnerable/Subsequent System impact metrics, the Threat metric group (replacing Temporal), and a Supplemental metric group.

• Specification: https://www.first.org/cvss/v4-0/
• Calculator: https://www.first.org/cvss/calculator/4.0
• User Guide: https://www.first.org/cvss/v4.0/user-guide

CWE (MITRE)

Common Weakness Enumeration. A community-developed list of software and hardware weakness types used to classify vulnerability findings across scanners. CWE provides a common taxonomy for cross-scanner result correlation and false positive pattern analysis.

• Database: https://cwe.mitre.org/
• Top 25 (2024): https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html
• CWE/CVE Mapping: https://cwe.mitre.org/data/index.html

---

Common Pitfalls