A finding is not a fact.

01 · The signal problem

A confident label can still rest on incomplete evidence.

A scanner may report an “outdated” cryptographic library, attach a high severity and place the item in a remediation queue. Yet the evidence may contain only a shortened upstream version, a service banner or a Boolean assertion. None of those necessarily establishes the installed vendor package, its patch state or the applicability of a particular advisory.

This is especially important in enterprise Linux. Vendors can backport a security fix while retaining the upstream version family. Red Hat advises customers to use its product-specific CVE and advisory information when determining whether a shipped package has been fixed. A comparison that discards the RPM release can therefore convert a patched system into an apparent vulnerability.

The visual certainty of a finding must never exceed the certainty of its evidence.

02 · Identity before verdict

Preserve the information that changes the answer.

A trustworthy assessment begins with complete identity. For an RPM this includes epoch, package name, upstream version, vendor release and architecture. For a container it includes the registry, immutable image digest, package ecosystem and scan provenance. For an asset it includes cloud account, workload, environment and observation time.

The second value can be evaluated against the operating-system vendor's advisory and fixed package. The first cannot. Normalisation is valuable only if it retains every field required to reconstruct that decision.

03 · Evidence states

Separate what was observed from what was concluded.

Findings should move through explicit evidence states rather than jump directly from detection to fact. Statepoint uses a vocabulary that keeps uncertainty visible:

This does not make vulnerability management slower. It prevents teams from spending scarce remediation capacity on unsupported conclusions and prevents weak signals from obscuring the risks that are genuinely urgent.

04 · A defensible decision

Validation needs a record, not an opinion.

The decision record should retain the original signal, complete software identity, affectedness source, applicable advisory, fixed version, environmental context, contradictory evidence and the reason for the final disposition. If evidence changes, the conclusion can be recalculated without erasing why an earlier decision was made.

05 · Applicability evaluation

Statepoint resolves identity before it assigns a verdict.

Statepoint's applicability flow starts with a broad upstream match and reconstructs the subject of the claim. Asset, component and vulnerability identities are normalised without discarding the provider or package fields that can change the answer. Vendor status and local evidence are then evaluated as separate decision axes.

Because the original signal, evidence, evaluator version, confidence and reason remain connected, a later intelligence update can reassess the same occurrence without destroying the earlier decision trail.

06 · The Statepoint approach

Make uncertainty actionable.

Statepoint is designed to connect security findings with the infrastructure and software evidence needed to evaluate them. The aim is not to suppress ambiguity, but to express it precisely: what is known, what is inferred, what remains unproven and what evidence would change the decision.

That produces a better remediation queue and a stronger audit trail. A validated finding can move forward with its rationale intact. An unsupported finding can be closed without pretending it never existed. An incomplete finding can remain visible with an explicit evidence request.