Findings & evidence | Infiniview Docs

Anatomy of a finding

Each persisted finding carries:

Severity, category, confidence, exploitability, and source phase.
Stable fingerprint, primary file, line range, scanner, and rule metadata.
Attack path, affected files, evidence, suggested fix, and parsed fix prompt.
Runtime replay, interaction replay, proof-of-concept, and bundle artifacts when present.
Delta state: new, recurring, regressed, fixed, or suppressed.
Repo-scoped or user-scoped suppression memory.

Delta state

Delta is computed against the previous successful scan on the same target. Each finding is exactly one of:

State	Meaning
`new`	Fingerprint not seen on the prior scan.
`recurring`	Same fingerprint as prior scan, comparable severity.
`regressed`	Same fingerprint as prior scan, but severity or exploitability worsened.
`fixed`	Present on the prior scan, absent on this one.
`suppressed`	Active suppression (repo-scoped or user-scoped) hides this fingerprint.

Verified vs unverified

A verifiedfinding was confirmed through runtime or interaction testing. It’s stronger than an unverified static hit, but you should still inspect the evidence and trust context before prioritizing work.

Note

Trust score weights verified findings differently from unverified ones. See Trust & readiness.

Suppressions

Suppressions are fingerprint-based:

Repo scope — hides the finding only for that repository.
User scope— applies across that user’s matching findings, regardless of repo.

Deleting the suppression restores the finding presentation without deleting history.

GET    /api/finding-suppressions
POST   /api/finding-suppressions
DELETE /api/finding-suppressions/{id}