Skip to content

[REVIEW] scanner-tuning: add maintenance blackout and scan-window coverage gap gates #1528

@bnpl7

Description

@bnpl7

[REVIEW] scanner-tuning: add maintenance blackout and scan-window coverage gap gates

Skill Being Reviewed

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

False Positive Analysis

Benign-looking tuned policy that can be incorrectly scored as effective coverage:

Scan Policy: PROD-WINDOW-ONLY
Schedule: Sunday 02:00-06:00 local time
Maintenance blackout: no scans during change freeze (last 10 days of quarter)
Authenticated scan: enabled
Last successful scan: 37 days ago
Open findings delta: -412 (suppressions applied)

Why this is a false positive:

The skill encourages suppression tuning and authenticated scanning, but does not require evidence that assets were actually scanned recently. A narrow scan window combined with change freezes, holiday blackouts, or failed credential rotations can leave production assets unscanned for weeks while suppressions reduce apparent finding volume. The policy looks tuned even though observation coverage is stale.

Coverage Gaps

Missed variant 1: Assets permanently skipped due to recurring maintenance tags

asset,scan_exclusion_reason,exclusion_expiry
pay-api-01,active_change_ticket,none
pay-api-02,active_change_ticket,none
pay-db-01,active_change_ticket,none

Why it should be caught: Exclusions without expiry create blind spots. Tuning should not proceed until scan reachability is restored or risk acceptance is explicit per asset.

Missed variant 2: Credential rotation broke auth scans mid-quarter

Authenticated scan success rate: 12% (down from 96%)
Top failure: Windows UPN mismatch after tenant rename
Unauthenticated fallback: disabled by policy
Result: only internet-facing banner checks run

Why it should be caught: Existing guidance mentions authenticated scanning tradeoffs, but not a hard gate blocking suppression work when auth success falls below threshold.

Missed variant 3: Container rebuild cadence outpaces scan cadence

Image tag retention: 72 hours
Registry scan schedule: weekly
Deployed images at scan time: 0% overlap with prior scan

Why it should be caught: Vulnerability posture drifts on every deploy while scanner results appear current because the registry job "succeeded."

Edge Cases

  • Blue/green clusters: Only inactive color scanned because active color blocks intrusive checks.
  • Geo-fenced scan engines: APAC assets never scanned when policy uses US-night window only.
  • OT/ICS maintenance moratoriums: Long intentional blackouts need compensating controls, not silent omission.
  • Suppression during outage: Teams suppress all findings from unscanned assets to silence noise; skill should flag meta-suppression.

Remediation Quality

  • Fix resolves the vulnerability
  • Fix doesn't introduce new security issues
  • Fix doesn't break functionality
  • Issues found: Add "Coverage Freshness" gates before Step 1 false-positive work and before severity overrides.

Comparison to Other Tools

Tool Catches this? Notes
Tenable Exposure Score Partial Uses scan recency in exposure metrics; skill does not
Qualys VMDR SLA dashboards Partial Can show scanning gaps; not required by skill
Semgrep/CodeQL No Different domain

Overall Assessment

Strengths: Strong false-positive taxonomy, good validation workflow, and practical severity override guidance.

Needs improvement: Tuning guidance assumes scans are occurring successfully. Maintenance blackouts and failed auth windows are common operational realities that make tuned results misleading.

Priority recommendations:

  1. Add SCAN-COV-01 gate: every in-scope asset must have a successful scan within policy-defined max age (for example 7 or 14 days) before suppressions are accepted.
  2. Require authenticated-scan success rate threshold (for example >= 90%) before classifying version-based findings as false positives.
  3. Document blackout/compensating-control pairing: if scans are paused, mandate alternate telemetry (runtime SBOM, admission controller, WAF rule validation).

Bounty Info

  • I have read and agree to the CONTRIBUTING.md bounty terms
  • Preferred payment method: PayPal

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions