Why a finding needs a memory

Run a container scanner against a moderately sized image and you will get somewhere between fifty and five hundred findings. Run it again tomorrow and you will get roughly the same ones, in a slightly different order, with a handful added and a handful gone.

The second report is not more useful than the first. In an important sense it is less useful, because by then somebody has already spent an afternoon reading the first one — and none of that afternoon survives.

The thing that gets lost

What a team actually produces when it reads a vulnerability report is not a list. It is a set of decisions:

• This one is exploitable in our context. Fix it this sprint.
• This one is in a package we do not call. Accept it, review in ninety days.
• This one is a false positive from a vendored copy of a library.
• This one we already fixed last month.

Each of those is expensive. Someone had to read an advisory, find the call site, judge the exposure, and be willing to sign their name to the conclusion. And each of them is attached to a specific vulnerability in a specific place — which is exactly the attachment a fresh report cannot preserve.

So the decisions evaporate, and the next person reads the same advisory and reaches the same conclusion, or a different one. After a few cycles of this the report stops being read at all. That is the actual failure mode of vulnerability management: not that teams cannot find vulnerabilities, but that finding them repeatedly is indistinguishable from not finding them at all.

Identity is the hard part

To keep a decision you need to know what it was about, which means a finding needs an identity stable enough to survive everything that legitimately changes around it.

That turns out to be a real design problem, because most of the obvious candidates are wrong:

• Position in the report changes whenever anything else changes.
• Severity is re-rated. CVSS scores move as understanding improves, and a vulnerability re-rated from high to critical is the same vulnerability.
• The installed version changes on every base image bump, including bumps that do not fix the issue.
• The scanner’s own identifier ties you to a vendor. Change engines and every decision your team has ever made is orphaned at once.

TRUSTIVAN derives identity from the content of the finding — what the vulnerability is, and where it lives — and deliberately excludes the things above. The practical consequence is that a re-rating does not create a new finding to be triaged again, and a change of detection engine does not reset the record.

What a memory makes possible

Once a finding persists, several things become expressible that were not before.

Regression becomes visible. A finding that was resolved and has come back is a materially different situation from one that was never fixed, and it is the single most interesting signal a vulnerability programme produces. It only exists if you can tell that this finding is that finding.

Accepted risk becomes accountable. A suppression with an owner, a written reason and an expiry date is a decision. The same suppression without those is a way to make a number go down. TRUSTIVAN requires the reason and bounds the expiry, because an acceptance nobody owns and nobody revisits is not really an acceptance.

A verdict becomes reproducible. If findings have identity and policies have versions, then “did this build pass” has a durable answer that can be produced again months later, during the audit or the incident review when it actually matters.

The uncomfortable implication

If the decision record is the valuable part, then detection is a commodity — and a vendor should say so rather than pretending its matching is a moat. TRUSTIVAN’s vulnerability detection is powered by Trivy, a good open-source engine, under Apache 2.0. We did not write it and we do not claim to have.

What we built is everything that happens to a finding after it is found. That is where the work was, and it is the part that does not come free with any scanner you could install this afternoon.