[REVIEW] scanner-tuning: add ephemeral asset identity and stale-scan evidence gates

[tiandashu]

Skill Being Reviewed

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

False Positive Analysis

Benign code/configuration that triggers a false positive:

scan_result:
  scanner: Tenable
  finding_id: CVE-2024-3094
  asset:
    ip: 10.40.12.18
    hostname: ip-10-40-12-18.ec2.internal
    cloud_provider: aws
    instance_id: i-0abc1111old
    ami_id: ami-legacy-2024-03
  first_seen: 2026-06-01T01:00:00Z
  last_seen: 2026-06-01T01:00:00Z
  scan_completed_at: 2026-06-01T01:10:00Z

current_asset_inventory:
  ip: 10.40.12.18
  instance_id: i-0def2222new
  ami_id: ami-hardened-2026-06
  launched_at: 2026-06-08T09:20:00Z
  package_status:
    xz-libs: 5.4.6-3.el9.patched

Why this is a false positive:
The scanner result is tied to a recycled private IP/hostname, not to the current cloud asset identity. scanner-tuning currently tells reviewers to document affected assets and correlate scanner output, but it does not require evidence that the finding is bound to a stable asset identity such as cloud instance ID, image digest, Kubernetes UID, container image digest, or asset inventory snapshot timestamp. In elastic cloud environments, suppressing or escalating a finding based only on IP/hostname can misclassify a terminated instance's stale vulnerability as present on a new clean instance.

Coverage Gaps

Missed variant 1: stale ephemeral compute finding

finding:
  cve: CVE-2025-12345
  asset_key_used_by_scanner: 172.20.5.44
  scan_time: 2026-06-03T02:00:00Z
cloud_inventory_now:
  172.20.5.44:
    instance_id: i-new-prod-api
    launch_time: 2026-06-07T18:00:00Z
    owner: payments-api

Why it should be caught:
The skill should require asset identity freshness before calling a finding true, false, suppressed, or severity-adjusted. The current workflow can treat scan history as current evidence even when the target has been replaced.

Missed variant 2: container image tag drift

scanner_finding:
  image: registry.example.com/app/api:latest
  digest_at_scan: sha256:oldvulnerabledigest
runtime_inventory:
  image: registry.example.com/app/api:latest
  digest_running: sha256:newpatchdigest
  deployed_at: 2026-06-08T10:00:00Z

Why it should be caught:
For containers, tags are mutable. Tuning decisions must bind findings and suppressions to immutable image digests, not tags. Otherwise a valid suppression for one digest can hide a new vulnerable digest, or a stale finding can remain against a patched digest.

Edge Cases

• Autoscaling groups can replace every host between weekly scans; the asset ID and launch timestamp matter more than IP.
• NAT, DHCP, and Kubernetes node reuse can cause the same scanner asset key to represent different workloads over time.
• External scanners may only see a load balancer IP; reviewer should mark backend identity as Not Evaluable unless deployment or target mapping evidence exists.
• Long-lived suppression records should expire or revalidate when instance ID, image digest, AMI ID, cluster UID, or scanner asset UUID changes.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add an evidence gate before false-positive disposition and severity override: require stable asset identity, inventory timestamp, scanner asset UUID, cloud instance/resource ID, image digest, and proof that the scanned object is the object currently in scope. Suppressions should be scoped to immutable asset identity where possible and must expire on asset replacement.

Comparison to Other Tools

Tool	Catches this?	Notes
Semgrep	No	Static code scanner; not designed for cloud asset identity freshness.
CodeQL	No	Code-focused; does not correlate scanner asset keys with cloud inventory.
Qualys/Tenable/Rapid7	Partial	They maintain asset IDs, but exports are often consumed downstream by IP/hostname unless integrations preserve scanner UUID and cloud metadata.
Wiz/Prisma/Lacework	Partial	CNAPPs usually bind cloud resource IDs and image digests; the review skill should require this evidence when vulnerability scanners feed VM tools.

Overall Assessment

Strengths:
scanner-tuning already has strong false-positive taxonomy, authenticated scan guidance, severity override rules, and cross-scanner correlation.

Needs improvement:
It assumes an affected asset is stable once named. Modern cloud and container environments need an asset-identity freshness gate before tuning decisions are accepted.

Priority recommendations:

1. Add an Asset Identity Freshness step before false-positive disposition and severity override.
2. Extend the false-positive record with scanner asset UUID, cloud resource ID, launch/deploy timestamp, image digest, and inventory source timestamp.
3. Require suppression invalidation when IP/hostname maps to a new instance, image digest, AMI, Kubernetes UID, or cloud resource ID.

Bounty Info

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

[tiandashu]

Opened implementation PR: #2010

Validation completed before opening:

• git diff --check
• Parsed all four YAML fixtures with PyYAML
• Verified the Asset Identity Freshness Gate and required evidence markers are present
• Verified fixture count: 2 vulnerable and 2 benign

Bounty request in the PR: Improver Moderate ($100) if accepted.

[shensz2017]

/attempt

[shensz2017]

Review for implementation PR #2010:

This is a valid Moderate gap in scanner-tuning. The current skill has a solid false-positive workflow, severity override criteria, and cross-scanner correlation guidance, but it assumes that the affected asset remains stable once the scanner names it. In cloud, container, Kubernetes, autoscaling, DHCP, and load-balanced environments, IPs, hostnames, DNS names, and image tags can all point to different objects over time.

#2010 adds the right evidence gate before accepting suppressions, false-positive dispositions, or severity overrides. Requiring both stable identity evidence and freshness evidence is the key improvement: scanner asset UUID alone is useful but not enough, and current inventory alone is also not enough unless it can be tied back to the scanned object.

The proposed evidence categories are well scoped:

• cloud VMs need resource/instance ID plus launch/termination/current inventory timestamp;
• containers need immutable image digest plus build/deploy/runtime digest evidence;
• Kubernetes workloads need UID-level identity rather than pod name alone;
• external endpoints need scanner asset UUID plus current load balancer/backend mapping.

The fixtures strengthen the PR because they cover real operational mistakes: stale private IP reuse, mutable latest tag drift, a current cloud asset match, and digest-scoped container suppression. Those are exactly the cases where downstream exports often lose scanner-native identity and teams accidentally make tuning decisions against the wrong object.

A few review notes:

• The Not Evaluable / stale evidence outcome should stay. If the current object cannot be proven to be the scanned object, the safe action is re-scan or keep the finding open, not suppress it.
• Suppression invalidation on instance ID, image digest, AMI/source image, Kubernetes UID, or scanner asset UUID change is an important guardrail.
• The prompt-injection safety update is also useful because scan output and banners can contain misleading text; asset identity matching must remain evidence-based.
• The change is additive and fits the existing skill structure without turning scanner tuning into a full CNAPP workflow.

One future improvement could be mentioning CMDB reconciliation keys or cloud asset inventory export IDs in the table, but the current implementation already captures the core decision logic.

Overall, I support merging #2010 as a focused scanner-tuning improvement. It makes false-positive and suppression decisions safer in dynamic infrastructure.

[JamesJi79]

/attempt #2007

I will submit a VALID GAP analysis for this review.

[Errordog2]

Implemented this review as PR #2275: #2275

Summary:

• Added an Asset Identity Freshness gate before true-positive, false-positive, suppression, or severity override decisions.
• Added stable identity fields for scanner UUID, cloud resource ID, launch timestamp, image digest, Kubernetes UID, and inventory timestamp.
• Added stale compute and mutable container tag-drift examples.
• Added suppression invalidation/revalidation guidance when instance IDs, image digests, AMIs, Kubernetes UIDs, scanner UUIDs, or cloud resource IDs change.
• Added an Asset Identity Freshness output table.
• Validation completed: git diff --check, frontmatter required-field check, index path check, changed-file fence-balance check, workflow-equivalent prompt-injection scan, and marker checks for the new identity-freshness fields.

Requesting Improver - Moderate ($100) if accepted. Payment details can be provided privately after acceptance.

[JamesJi79]

/attempt #2007

I will submit VALID GAP analysis for this review.

[JamesJi79]

/attempt #2007

VALID GAP - Scanner Tuning: Ephemeral Asset Identity and Stale-Scan Evidence Gates

Why Valid (FP confirmed)

The FP example shows a scanner result tied to a recycled private IP/hostname, not the current cloud asset identity. The skill tells reviewers to document affected assets and correlate scanner output but does not require evidence that the finding is bound to a stable asset identity such as cloud instance ID, image digest, or Kubernetes UID. In elastic cloud environments, suppressing or escalating a finding based only on IP/hostname can misclassify a terminated instance's stale vulnerability as present on a new clean instance.

Coverage Gaps

Gap 1 - Stale ephemeral compute finding - The skill should require asset identity freshness before calling a finding true, false, suppressed, or severity-adjusted. The current workflow treats scan history as current evidence even when the target has been replaced. Need gate: SCAN-ASSET-FRESH-01.

Gap 2 - Container image tag drift - For containers, tags are mutable. Tuning decisions must bind findings and suppressions to immutable image digests, not tags. Otherwise a valid suppression for one digest can hide a new vulnerable digest. Need gate: SCAN-ASSET-FRESH-02.

Gap 3 - No suppression invalidation trigger on asset replacement - Long-lived suppression records should expire or revalidate when instance ID, image digest, AMI ID, cluster UID, or scanner asset UUID changes. Need gate: SCAN-ASSET-FRESH-03.

Suggested Gates

1. SCAN-ASSET-FRESH-01: Evidence of stable asset identity binding before false-positive disposition - cloud instance ID, image digest, Kubernetes UID, or scanner asset UUID. Evidence: asset identity fields in false-positive record with inventory source timestamp.
2. SCAN-ASSET-FRESH-02: Evidence that container findings are bound to immutable image digests, not tags. Evidence: running digest, scanner digest, and digests-match verification in the tuning record.
3. SCAN-ASSET-FRESH-03: Evidence of suppression revalidation trigger on asset identity change - expiration or invalidation rule when IP/hostname maps to a new instance, image digest, AMI, or Kubernetes UID.