A container moves through registries, scanners, deployment policies and runtime systems. Security evidence often does not. When each stage produces an isolated record, teams lose the ability to explain whether the thing observed at runtime is the thing they assessed before deployment.
01 · The fragmentation problem
Five tools can describe five different containers.
A registry scanner reports a repository and tag. An SBOM generator lists packages. A vulnerability engine records CVEs. An admission controller evaluates a Kubernetes manifest. A runtime sensor reports a process in a pod. Every observation may be correct, yet the operating picture remains incomplete if those records cannot be reconciled to an immutable image digest and workload identity.
Tags move. Images are rebuilt. Workloads roll forward and back. A result that cannot retain its identity and time boundary quickly becomes an assertion about something that may no longer be running.
02 · The evidence chain
Keep every decision attached to the same subject.
A useful container-security model follows the artifact from source to execution. Statepoint treats each stage as a related evidence class rather than a replacement for the previous one.
SBOM tools such as Syft can catalogue packages from container images and filesystems. That inventory is valuable, but it becomes decision-grade only when Statepoint can connect its source and digest to the vulnerability, deployment and runtime records that follow.
03 · Statepoint capability
Turn a registry object into an evidence-backed vulnerability record.
Statepoint inventories container registries and images across Azure, AWS and Google Cloud, preserving the image digest as the stable identity. Scan execution remains distinct from inventory, so an image that exists but has not completed assessment cannot appear clean by default.
The detail view keeps package occurrences, unique CVEs and affected-image counts separate. That prevents one vulnerable package repeated across an image from being presented as several unrelated risks.
CVSS describes intrinsic severity. EPSS adds exploit likelihood. KEV shows known exploitation. Vendor state and fixed-version evidence help determine applicability and remediation. Statepoint keeps those signals beside their source facts rather than flattening them into an unexplained label.
04 · Failure is evidence
A missing result must not look like a clean result.
Container workflows need explicit operational states: queued, running, completed, failed and timed out. The same discipline applies to coverage. An inventory record does not prove that a scan completed. A deployed sensor does not prove that it is ready. The absence of findings does not prove the absence of risk when collection failed.
“No findings” and “no evidence” are materially different security states.
Statepoint preserves insufficient coverage as an outcome in its own right. This lets teams distinguish a healthy runtime sensor from an absent or not-ready sensor, and a completed assessment from a resource that became unavailable before evaluation.
Scan state provides the same protection earlier in the lifecycle. Teams can distinguish a completed assessment from an image that was queued, failed, timed out or became unavailable before evaluation.
05 · Runtime context
An alert matters when it can be traced back.
Falco observes runtime events and can enrich alerts with container and Kubernetes metadata. The alert becomes more useful when the operating layer connects pod, namespace, process context and resolved image digest to the artifact previously inventoried and assessed.
The digest is the bridge that prevents a moving tag from becoming the identity of the workload. It lets later runtime evidence refer back to the exact artifact, packages and vulnerability evaluation already recorded.
That connection supports a better investigation: which package and image were involved, whether admission controls evaluated the deployment, what evidence was available beforehand and whether the runtime event changes the priority of an existing finding.
06 · The operating outcome
One workload. One traceable story.
The goal is not a single universal container score. It is a coherent record that can answer what was built, what was known, what was allowed, what ran, what changed and what action followed. Statepoint brings those observations into a governed operating context across Azure, AWS and Google Cloud while preserving the distinction between available evidence and unproven coverage.
Sources
Anchore · Syft SBOM documentation Falco · Cloud native runtime security documentation