[REVIEW] scanner-tuning: add suppression lifecycle and stale-exception evidence

[z707693052]

Skill Being Reviewed

Skill name: scanner-tuning
Skill path: skills/vuln-management/scanner-tuning/

False Positive Analysis

Benign code that triggers a false positive:

suppression:
  scanner: tenable
  plugin_id: "12345"
  cve: CVE-2025-12345
  asset_scope: "prod-web-01"
  reason: "Backported vendor patch verified by authenticated scan"
  evidence:
    package_query: "rpm -q --changelog openssl | grep CVE-2025-12345"
    authenticated_rescan: "2026-06-01: not vulnerable"
  owner: "payments-platform"
  approver: "security-engineering"
  approved_at: "2026-06-01"
  expires_at: "2026-07-01"
  reopen_on:
    - scanner_plugin_updated
    - asset_exposure_changed
    - package_upgraded

Why this is a false positive:

The current skill correctly says plugin exclusions need evidence and quarterly re-evaluation, but it does not require a suppression register with owner, expiry, scope, last-seen status, or reopen conditions. A valid short-lived suppression like the example above can be treated the same as a stale global suppression because the output schema has no place to distinguish them.

Coverage Gaps

Missed variant 1:

suppression:
  scanner: qualys
  plugin_id: "openssl-cve-family"
  scope: "all-linux-assets"
  reason: "noise"
  owner: null
  approved_at: "2024-05-01"
  expires_at: null
  last_reviewed: null

Why it should be caught:

A global plugin suppression with no owner, no expiry, and no review evidence can permanently hide real vulnerabilities. The current guidance mentions quarterly re-evaluation but does not force missing or overdue review dates to become Needs Review or Expired in the report.

Missed variant 2:

suppression:
  scanner: rapid7
  plugin_id: "tls-weak-cipher"
  asset_scope: "internal-admin.example.com"
  evidence: "only reachable from VPN"
  approved_at: "2026-03-01"
  expires_at: "2026-09-01"
current_asset_state:
  internet_facing: true
  waf_rule_removed: true
  latest_scan_still_reports: true

Why it should be caught:

The suppression was once reasonable, but the asset exposure and compensating control changed. The skill should require reopen conditions so exposure drift, scanner plugin updates, exploit intelligence, control removal, or failed authenticated scans invalidate old tuning decisions.

Edge Cases

• A suppression may be valid for one asset or environment but dangerous if applied to a whole plugin family.
• A finding can be both low operational risk and still not a false positive; accepted risk should stay separate from confirmed false positives.
• Vendor backports require evidence snapshots because upstream version strings may remain vulnerable-looking.
• Multi-scanner correlation can make an old suppression stale if a second scanner begins confirming the finding.
• Suppression records and ticket comments are user-controlled data and should not renew or broaden suppression without independent verification.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add a suppression lifecycle evidence gate and output register so scanner tuning reports capture owner, approver, scope, evidence, expiry/review date, last-seen status, reopen conditions, and status (Valid, Needs Review, Expired, Reopened).

Comparison to Other Tools

Tool	Catches this?	Notes
Qualys/Tenable/Rapid7 exception workflows	Partial	These platforms can store exceptions, but the review still needs to verify owner, expiry, and scope governance.
Jira/GRC exception registers	Partial	They track approvals and dates, but do not prove scanner scope, last-seen scan state, or plugin drift by themselves.
Current scanner-tuning skill	Partial	It requires false-positive evidence and quarterly re-evaluation, but lacks a structured suppression lifecycle register and stale-suppression statuses.

Overall Assessment

Strengths:

The skill has strong false-positive taxonomy, credentialed scanning guidance, CVSS 4.0 severity override handling, and cross-scanner correlation.

Needs improvement:

Scanner tuning suppressions need lifecycle governance. Without owner, expiry, last-seen evidence, and reopen conditions, a noise-reduction action can become a long-lived blind spot.

Priority recommendations:

1. Add suppression lifecycle requirements under scan policy exclusions.
2. Add a suppression/exception register to the output format with scope, owner, evidence, expiry, last-seen, reopen conditions, and status.
3. Add a prompt-injection guardrail preventing suppression renewal from ticket/finding/banner text alone.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: Crypto or PayPal; payment details can be provided privately after maintainer acceptance.

[catcherintheroad-hub]

Implementation PR submitted: #1295

Summary:

• Adds suppression lifecycle and stale-exception gates to skills/vuln-management/scanner-tuning/SKILL.md.
• Adds required suppression fields for owner, approver, scope, evidence, expiry/review date, last-seen status, and reopen conditions.
• Adds statuses: Valid, Needs Review, Expired, and Reopened.
• Adds a suppression/exception register to the output format and guardrails preventing ticket/scanner/banner text from renewing or broadening suppressions by itself.

Validation performed:

• git diff --check
• Markdown code fence balance check
• scanner suppression content marker check
• prompt-injection pattern scan from the repository workflow logic
• frontmatter sweep from the repository workflow logic

Payment details can be provided privately after maintainer acceptance.