You patched the TLS vulnerability. You ran a credentialed scan. The scan confirms it's fixed — the finding shows as remediated. But you open Tenable Asset Inventory and the vulnerability is still listed as Active on that asset. The scan says fixed. The inventory says open. Which one is right?
The scan is right. Here's why inventory lags behind — and how to resolve it.
Tenable Asset Inventory doesn't update in real time from individual scan results. It aggregates vulnerability state across scan history for each asset, and it uses a set of rules to determine whether a finding is Active, Fixed, or Reopened.
The problem is that inventory state can be influenced by multiple scan sources — different scan policies, different scanner groups, different credential sets. If the same asset is scanned by more than one scan configuration, and only one of them captured the remediation, inventory may still show the vulnerability as Active based on the other scan's last result.
Multiple scan policies hitting the same asset
If an asset is in scope for both a credentialed compliance scan and an uncredentialed network scan, and the TLS fix is only detectable via credentialed plugins, the uncredentialed scan will keep reporting the vulnerability. Inventory sees two scan sources — one says fixed, one says active — and defaults to Active.
Stale scan history
Tenable retains historical scan data and factors it into inventory state calculations. If the asset hasn't been rescanned since the remediation within the relevant scan group's evaluation window, the old finding persists.
Scanner group mismatch
If the remediation was confirmed by a scanner in one group but inventory is being calculated from a different scanner group's data, the fix won't propagate to inventory until the correct group rescans the asset.
Step 1 — Identify which scan confirmed the fix
In Tenable VM, go to the asset's vulnerability detail for the TLS finding. Look at the scan history — specifically which scan policy and scanner confirmed the remediated state.
Step 2 — Check for competing scan sources
Pull the asset's full scan history and look for multiple scan policies that include the same plugin ID. If an uncredentialed scan is still reporting the vulnerability, that's your conflict.
Step 3 — Exclude the asset from uncredentialed scans or update scan scope
If the vulnerability is only accurately detected via credentialed scanning, ensure the uncredentialed scan either excludes this asset or the plugin is suppressed for assets where credentialed coverage is confirmed.
Step 4 — Force a rescan with the correct policy
Trigger a targeted rescan of the asset using the credentialed policy that confirmed the fix. After the rescan completes, give inventory 24 hours to recalculate state.
Step 5 — Use recast or accept rules if the conflict persists
As a last resort, a vulnerability recast rule can force the finding to a specific state for reporting purposes while you resolve the underlying scan conflict. Document the recast and the reason.
Asset inventory showing Active after a confirmed fix almost always means competing scan sources or stale scan history — not that the vulnerability came back. Trace the scan history, find the conflict source, resolve it at the scan policy level, and let inventory recalculate. Don't chase the inventory state directly without understanding what's driving it.
These posts come from real production environments — not labs, not documentation. If that's the kind of writing you want more of, follow Root & Secure on Medium.