Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions skills/vuln-management/scanner-tuning/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -177,6 +177,21 @@ Authentication Configuration:
- Last Verification: [YYYY-MM-DD, success rate: [N]%]
```

#### Credentialed Scan Coverage Evidence Gate

Do not treat "scan completed" or "no vulnerabilities found" as proof that credentialed checks were performed. For each asset class, prove that the scanner authenticated with sufficient privilege and completed the local evidence collection required for package, patch, registry, file, or configuration checks.

| Evidence | Required Detail |
|---|---|
| Asset credential scope | Asset group, platform, scanner engine, expected credential type, credential source, credential privilege level |
| Authentication result | Success, failed, not attempted, partial, or unknown per asset or asset class |
| Scanner-specific proof | Tenable credentialed checks evidence, Qualys authentication status QIDs, Rapid7 credential/test result, agent status, or equivalent vendor evidence |
| Local inventory proof | Package manager inventory, patch inventory, registry/share access, file-system access, database/version query, network-device command output |
| Reachability prerequisites | Management port/protocol reachability, firewall path, scan engine location, account lockout or rate-limit evidence |
| Coverage decision | Full, Partial, Failed, Not Attempted, or Not Evaluable, with retest owner and due date |

**Finding classification:** Mark the scan result **Not Evaluable** when credential status, local inventory retrieval, or privilege level cannot be proven. Treat failed credentialed checks on production assets as a **High** tuning gap when the scan is used for patch compliance, severity overrides, or false-positive suppression. Do not suppress a version-based finding or downgrade severity until credentialed evidence proves the installed package/patch state.

### Step 4: Severity Override Criteria

Define criteria for overriding scanner-assigned severity ratings when they do not reflect actual organizational risk.
Expand Down Expand Up @@ -322,6 +337,12 @@ Highlight the most impactful tuning recommendations.]
| Scan Frequency | [Current schedule] | [Recommended schedule] | [Priority] |
| Port Range | [Current range] | [Recommended range] | [Priority] |

### Credentialed Scan Coverage Matrix

| Asset Class | Scanner / Engine | Credential Source | Auth Result | Local Inventory Proof | Failed / Not Attempted Assets | Coverage Decision | Retest Owner / Due Date |
|---|---|---|---|---|---|---|---|
| [Windows servers] | [scanner/engine] | [vault/site/shared credential] | [success/failed/partial] | [registry/share/package evidence] | [count/list] | [Full/Partial/Failed/Not Evaluable] | [owner/date] |

### False Positive Analysis

| Plugin/Check ID | CVE ID | FP Pattern | Affected Assets | Evidence | Recommendation |
Expand Down Expand Up @@ -399,6 +420,8 @@ Common Weakness Enumeration. A community-developed list of software and hardware

5. **Not correlating results across scanners.** Organizations running multiple scanners often treat each scanner's output independently, leading to duplicate remediation efforts for the same vulnerability and missed findings that only one scanner detects. Establish a correlation process using CVE ID as the primary key and CWE as a fallback for non-CVE findings.

6. **Accepting unauthenticated or partially authenticated scans as negative evidence.** A clean scan is only useful if the scanner proved the local evidence it needed to inspect. Credential failures, insufficient privileges, stale agents, blocked management ports, or missing package/patch inventory turn "not detected" into unknown coverage. Track credentialed scan coverage separately from vulnerability counts.

---

## Prompt Injection Safety Notice
Expand All @@ -423,7 +446,11 @@ Common Weakness Enumeration. A community-developed list of software and hardware
- PCI DSS 4.0 (Requirement 11.3): https://www.pcisecuritystandards.org/
- Qualys VMDR Documentation: https://www.qualys.com/documentation/
- Tenable Nessus Documentation: https://docs.tenable.com/nessus/
- Tenable Nessus Credentialed Checks: https://docs.tenable.com/nessus/10_10/Content/NessusCredentialedChecks.htm
- Tenable Scan Tuning Credentials Configuration: https://docs.tenable.com/quick-reference/vulnerability-management-scan-tuning/Content/VM-Scan-Tuning/CredentialsConfiguration.htm
- Qualys Authentication Status QIDs: https://docs.qualys.com/en/vm/latest/authentication/auth_stat_qids.htm
- Rapid7 InsightVM Documentation: https://docs.rapid7.com/insightvm/
- Rapid7 InsightVM Scan Credentials: https://docs.rapid7.com/insightvm/configuring-scan-credentials/
- Greenbone/OpenVAS: https://greenbone.github.io/docs/
- Trivy: https://aquasecurity.github.io/trivy/
- Grype: https://github.com/anchore/grype
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# Credentialed Scan Coverage Edge Cases

Use these fixtures to verify that `scanner-tuning` does not treat a completed scan or empty finding set as reliable evidence when credentialed checks failed, were not attempted, or did not collect the local inventory required for vulnerability validation.

## Case 1: Network Scan Completed but Credentials Failed

**Scenario:** The scan completed successfully from the network perspective, but Windows authentication failed on all production servers. The scanner returned open ports and banner-based findings, but no local registry, installed package, or patch inventory evidence exists.

**Expected decision:** Not Evaluable for patch-level conclusions; High tuning gap if the scan is used for patch compliance.

**Expected markers:**
- `Credentialed Scan Coverage Matrix`
- `Authentication result`
- `Not Evaluable`
- `High`

## Case 2: Authentication Succeeds but Local Inventory Fails

**Scenario:** Linux SSH login succeeds, but package inventory collection fails because sudo/root privileges are missing. The report says credentials were accepted, but no rpm, dpkg, or equivalent package inventory was retrieved.

**Expected decision:** Partial or Not Evaluable; do not suppress version-based findings until package evidence is collected.

**Expected markers:**
- `Local inventory proof`
- `credential status`
- `package/patch inventory`
- `Not Evaluable`

## Case 3: Mixed Asset Classes With Partial Credential Coverage

**Scenario:** Windows servers authenticate successfully, network devices return SNMP authentication failed, databases are not attempted, and Kubernetes nodes are scanned only remotely. The summary says "authenticated scan" because at least one credential family worked.

**Expected decision:** Partial coverage with per-asset-class retest owners and due dates.

**Expected markers:**
- `Asset credential scope`
- `Failed, Not Attempted`
- `Coverage decision`
- `Retest Owner / Due Date`

## Case 4: Agent Present but Stale or Offline

**Scenario:** Endpoint agents are installed and the scan policy relies on agent data, but a subset of high-value assets has not checked in for 21 days. The scanner still shows the last known software inventory.

**Expected decision:** Not Evaluable for current exposure until agent freshness or a live credentialed scan is proven.

**Expected markers:**
- `agent status`
- `Local inventory proof`
- `Not Evaluable`

## Case 5: False-Positive Suppression Before Credentialed Retest

**Scenario:** A team wants to suppress a banner-based OpenSSL finding as false positive because the OS vendor backported a fix. No authenticated package check, vendor advisory evidence, or package-release evidence is attached.

**Expected decision:** Do not suppress; require credentialed retest or package evidence before false-positive disposition.

**Expected markers:**
- `Do not suppress`
- `version-based finding`
- `credentialed evidence`

## Case 6: Full Credentialed Coverage With Evidence

**Scenario:** The scanner authenticates to Windows, Linux, databases, and network devices with appropriate privileges. Evidence includes scanner-specific auth success indicators, package/patch inventory, registry/share access where needed, database version query output, successful agent freshness, and retest owner for the small exception set.

**Expected decision:** Full credentialed coverage for the scoped asset classes.

**Expected markers:**
- `Scanner-specific proof`
- `Local inventory proof`
- `Full`
- `Credentialed Scan Coverage Matrix`