A scan is a snapshot. Administrators need vulnerability history
The latest scan answers a simple question: what can the scanner see now? That is important information, but it is often insufficient for an administrator.
Imagine a vulnerability disappears after an update and returns a week later. Was the fix rolled back? Did an older package reach the server? Did a new container appear? Or did the previous scan omit that source? The current report cannot answer. It shows the state while removing the route that led there.
I therefore treat a scan as a photograph. Operations needs the film.
What disappears when you retain only the latest result
The simplest process overwrites the previous JSON file or stores only the current table. The list is fresh and apparently tidy, but several important facts disappear:
- when the vulnerability was first observed,
- which subsequent scans still contained it,
- when it stopped being detected,
- whether it returned after remediation,
- which status and decision the team assigned,
- whether the remediation deadline was met.
Without history, you cannot distinguish a new problem from one left open for three months. You also cannot identify a regression in which a previously resolved finding returns.
History changes prioritisation
Two vulnerabilities can have the same CVSS and affect equally important machines. One appeared today. The other has been open for sixty days and passed its internal deadline. The latest scan shows two similar rows. History shows two different operational problems.
In Secvalis, a finding lifecycle records first seen, last seen and resolved timestamps. If the same CVE and package return after resolution, a new cycle begins. An old risk acceptance therefore does not automatically carry into a new occurrence, and recurrence does not masquerade as uninterrupted continuity.
That is a small data-model detail with a large operational effect. "Fixed in May and detected again in July" requires a different response from "open continuously since May".
A status without history is only a label
NEW, IN_PROGRESS, ACCEPTED_RISK and FIXED become useful only when the team knows who made the decision and when. Otherwise, FIXED can mean a verified update or a click made six months ago by someone who has since left.
Useful history connects the technical result with the decision:
- who started the work,
- which comment or change reference was recorded,
- who accepted the risk,
- when the acceptance expires and needs review,
- whether a later scan confirmed that the finding disappeared.
Secvalis does not install the fix. It preserves the context in which an administrator decided what to do and allows that decision to be checked against later scans.
A trend matters more than a single number
"We have 312 vulnerabilities" means little without a baseline. Was the number 500 last month, or 120? Is the critical count falling while the number of hosts with stale scans rises?
Scan history shows changes in CVE counts over time. Interpretation still requires care. A fall does not always mean remediation: a machine may have stopped reporting, scan scope may have changed or the machine may have been removed from the project. Read the trend together with scan freshness and fleet state.
This is also why a dashboard should not replace an administrator. A chart helps ask the right question. It does not automatically explain why the number changed.
This is not only an audit feature
History is often sold as "compliance evidence". It can indeed show what was found, when action was taken and whether deadlines were met. Its first user should still be the operations team.
Administrators use history when:
- a vulnerability returns after an update,
- they need to know how long a problem has existed,
- work moves between teams or shifts,
- a system owner asks why a task is urgent,
- they must distinguish absence of findings from absence of a fresh scan,
- someone revisits a decision made months earlier.
An audit should consume the trail created by normal work. It should not force the team to reconstruct that work a week before the meeting.
When a simpler solution is enough
If you maintain two machines, review results regularly and make every decision yourself, dated files or a small scan-comparison script may be sufficient. There is no reason to deploy a platform merely to draw a chart.
Central history begins paying for itself as machine count grows, several people review findings, deadlines apply or decisions must survive a change of administrator. Legislation is not the threshold. The threshold is the point at which one person's memory stops being a reliable system of record.
To review scan history and statuses using fictional data, open the public Secvalis demo.
This is part 3 of a series about CVEs in day-to-day system administration. Part 1 explains how to read a CVE page, while part 2 covers checking fleet exposure.