A vulnerability scanner is a measuring instrument. Pointed at the same host week after week, it reports the same issue week after week, as it should. The problem starts when the receiving system treats every repeat as new work.
Much of the pain attributed to “too many vulnerabilities” is pain from too many records of the same vulnerability. The remedy is a distinction, held consistently, between the issue being managed and the evidence that it exists.
Two different things
A finding is the managed issue: a specific vulnerability or exposure affecting an asset or component. It answers “does this asset have this problem now, and what have we decided?” It has a status: open, resolved, risk accepted, false positive. It has first-seen and last-seen dates, an owner, and a history of transitions. It persists and changes.
An observation is dated assessment evidence about that issue: one scan engine seeing it in one specific run. It carries the raw scanner output, the timestamp the scanner reported, the run it came from, and the engine that produced it. Once written, it has no reason to change.
In one sentence: a finding is persistent and has state; an observation is historical and has none. Observations are only added. Findings are updated, never duplicated.
Mature programs expose the same shape under different names: new, active, resolved, recurred. Those states only make sense if something persistent sits above the scan results and remembers what came before.
What breaks when they are merged
Consider a tool that stores whatever the scanner emits as its unit of work. Thirty weekly scans of one unpatched service produce thirty records, each looking “new” on the day it arrives.
“First seen” is whatever the latest import says, so the real age of the issue disappears and any service-level target measured from it is wrong. Recurrence history is lost, because resolving one record says nothing about the other twenty-nine, or about whether the issue came back after remediation. Remediation tickets duplicate, and the owner who already remediated the issue receives it again.
Reporting suffers most. “What did we resolve last month” cannot be answered, since no record has a lifecycle. Trend lines count scans rather than problems: scan more often and the chart rises, scan less and it falls.
The opposite collapse is less common but as damaging. A tool that keeps only current state and discards scan results can say an issue is open or resolved, but cannot show which run supported that status. The answer may be right, but it is unsupported.
What the split enables
Keeping both, with every observation attached to one finding, gives three properties.
Deduplication without losing provenance. The same issue seen thirty times is one finding with thirty observations underneath it. Nothing is discarded; the count of observations is not the count of problems. Distinct-finding counts reduce duplicate inflation, but coverage changes and improved detection can still change the chart without a change in underlying exposure.
Chronology that survives imports and recurrence. Preserve the earliest supported observation date and the latest supported sighting. An older scan imported late may legitimately move first seen earlier; a historical import should never move last seen backwards. Record recurrence separately, so a reopened issue retains its history without treating a verified period of resolution as continuous exposure. “Resolved on the 3rd, recurred on the 11th” is itself evidence about the change process.
Evidence for every status. A finding marked resolved should point to the observations that supported the resolution: a later run that reassessed the component with checks able to detect the issue, and the earlier output showing it was present. A finding marked risk accepted should point to the decision. Two companion articles cover those states: what counts as evidence of resolution is in not checked is not clean, and how operator decisions are recorded and preserved is in operator decisions outrank the scanner.
What makes two findings the same
Everything above depends on deciding when two observations describe one finding, which is harder than it looks. The working rule: group observations when the evidence identifies the same issue in the same affected instance on the same asset. Two vulnerabilities in one package remain two issues even if one upgrade fixes both. Separate independently remediable instances. If two instances can be remediated by different people on different schedules, they are different findings even when the vulnerability identifier is the same.
A port can help identify an instance but is not a universal identity rule. Two listeners on different ports may run one binary from one package, remediated by one upgrade; one listener may be reached on several ports through forwarding. Component and asset are the stable anchors.
Keep “unknown” distinct from “not applicable.” When a scanner cannot tell which component is affected, that is missing information, not an answer. Uncertain identity needs review before merging: an incorrect merge hides an exposure, an incorrect split creates duplicate work, and the second is the cheaper error.
A short case. An authenticated scan reports an outdated library by package name and version on a server. An unauthenticated scan of the same server reports the matching vulnerability on a web endpoint, inferred from response headers. They may describe the same component. They may also describe a bundled copy inside the web application, which the package upgrade will not touch. Until someone confirms which, the two observations should remain separate findings flagged for review.
Asset identity matters equally. If a host is identified by IP address in one run and hostname in the next, finding identity falls apart with it.
Why evidence stays
It is tempting to delete old observations once a finding is resolved, but they are the only support the current state has. An auditor asking why a critical issue was marked resolved in March wants the run that reassessed the component and the output showing it was present before. An engineer debugging a false positive wants the scanner’s exact text.
Evidence retention should be a deliberate policy with a documented retention period based on investigation, audit, contractual and data-handling needs, not a side effect of tidying up. NIST’s guidance frames patching as ongoing preventive maintenance to be planned and measured rather than a series of one-off events (NIST SP 800-40 Rev. 4); measuring an ongoing process requires keeping the measurements.
In practice
A few questions reveal whether a tool keeps this distinction.
- If the same host is scanned three times this week, does the open count change?
- When an older scan is imported, does first seen move earlier where supported, and does last seen stay where it was?
- When a resolved issue recurs, is it the same finding with a recurrence date, or a new record with no history?
- When two observations might describe one component but the evidence is ambiguous, are they held for review or merged automatically?
If the answers are uncomfortable, the limitation is in the data model, and dashboard work will not correct it. Sectie’s Exposure & Vulnerability Management product is built on this split: one managed finding per issue and affected instance on an asset, with every scanner observation kept underneath it as evidence.
