Lineage you can defend
Each image-to-repository link records how it was established: observed from a verified attestation, derived from immutable identifiers or inferred. Inferred links are excluded from strict lineage.
Container security.
From image to runtime.
Connect container image vulnerabilities to packages, layers and running workloads. Follow the image digest from the registry into production.
Build artifact
Base image
System packages
Application layer
Investigation context
01 / Unpack
Look inside the artifact you ship.
- Image digest
- Package inventory
Inspect image contents and package versions rather than relying only on a tag.
02 / Connect
Keep findings attached to the image.
- Finding evidence
- Artifact identity
A digest anchors the investigation to the artifact that was actually scanned.
03 / Rebuild
Carry the investigation into the next build.
- Replacement build
- Verification scan
Coordinate the base-image or package change and review the replacement artifact.
Digest
Pinned scans
Never a mutable tag.
Layer
Attribution
Which layer brought each package.
cosign
Signatures
Verified by digest against your trust policy.
Live
Workload binding
Which workloads run each digest now.
The category
What is container image scanning, and where does it stop?
Container image scanning lists what is inside an image and matches it against advisories. On its own it answers one question: is this image vulnerable? The questions that decide priority come after. Which base image brought the package in? Is the image signed by your pipeline? Which commit built it? Which workloads run it right now? A scanner that cannot answer them hands your team a list of CVEs and no order in which to fix them.
SecurityVault answers all four on one graph that runs from code to image to cloud. Each image finding is correlated with the commit and build that produced the digest, ranked by the exposed workloads running it, stopped by fail-closed gates before promotion and kept as continuous evidence for your controls. Platform teams fix the base image that clears the most findings; security teams see which running workloads are actually affected.
Image identity
Start with an immutable container digest.
Package inventory
Review the components inside its layers.
Workload context
Follow the image relationship into the environment.
An image scan describes the artifact; runtime context describes where it runs.
How SecurityVault does it
How does SecurityVault secure container images?
Scan
Every image scan runs trivy, grype, syft and dockle alongside the native engine's image mode, against a digest-pinned reference. The digest is confirmed before the scan starts and a moved tag is re-resolved, so a deleted image fails with a clear reason instead of a silent pass.
Discover
Registry push webhooks start a scan when a selected tag is pushed to an onboarded repository. Signature and cache tags are skipped, and every skip is audited.
Inventory
The image SBOM is stored as components and layers. That drives layer attribution, malicious-package and typosquat checks on image packages, and base-image recommendations ranked by fewer vulnerabilities, smaller size and active maintenance.
Trust
cosign signatures and attestations are verified by the platform, not by the scanner that read the image. Verified SLSA provenance links the image to the repository that built it.
Bind
Runtime observations bind each workload to the digest it runs. Freshness is tracked per cluster snapshot, so the binding reflects what is running now, not what was deployed last quarter.
Image audit
How do you audit a container image?
A container image audit asks three things before an image is promoted: what is inside it, how it was built and where it came from. These are the checks SecurityVault runs on every scanned digest, and the record each one leaves.
Vulnerabilities
trivy and grype match the operating-system packages and application dependencies in every layer against advisories. Each CVE is attributed to the layer, and so the base image, that brought it in.
Build practice
dockle checks how the image was built rather than what is inside it: an image that runs as root or carries leftover sensitive files is flagged even when it has no known vulnerabilities.
Secrets
The native engine unpacks the image filesystem and looks for credentials baked into a layer, which are routed to an owner like any other secrets finding.
Packages
Image packages are checked for known-malicious and typosquatted names, not only for CVEs.
Origin
cosign signatures and attestations are verified against your trust policy by digest, and verified SLSA provenance names the repository that built the image. The guide to verifying build provenance walks through the checks.
Inventory
The image SBOM exports as CycloneDX or SPDX 2.3, so the audit record lists every component and the layer it came from.
Outcomes
What happens to an image finding?
The finding sits on the digest, and the digest sits between the commit that built it and the workloads that run it. That position is what turns a CVE list into a ranked queue.
Commit
triggered
Build
produces
Container image
stored in
Registry
runs image
Workload
01
02
Consolidate image scan results
The same CVE from trivy, grype and the native engine is one logical finding, and the same package in a repository and its image is the same story.
03
Ranked by blast radius
Blast radius counts the workloads and ingresses running the digest, so an internet-facing service outranks an idle batch job.
Gates
Can an image be stopped before it runs?
At three points. The CI gate fails closed on the image scan. Registry promotion can be evaluated on blocking CVEs, signature and SLSA level. At the cluster, an image with no completed scan stays pending evaluation and an image from an untrusted source can never evaluate to allow. Image policies export as Kyverno policies that move from audit to enforce only with two approvals from different people, and the admission webhook can refuse unsigned images and :latest tags. See deployment gates and Kubernetes admission control.
Image findings
Review the vulnerabilities identified in the artifact.
Policy evaluation
Apply the configured promotion conditions.
Release decision
Retain the outcome before the image runs.
A policy decision belongs to the specific artifact being promoted.
Evidence
How does image evidence support compliance?
Image findings count as container evidence when controls are evaluated, and the image SBOM, signature verification result and policy decisions are kept per digest. SecurityVault maps that evidence to your controls across 6 seeded framework catalogues through the cross-walk, so you prepare for an audit from records rather than screenshots. See continuous compliance.
Artifact reference
Identify the scanned image.
Scan inventory
Retain package and finding evidence.
Compliance evaluation
Map the evidence to the controls it supports.
The scan record travels with the image identity.
FAQ
Container security questions
- What is container image scanning?
- Container image scanning inventories the operating-system packages and application dependencies in each layer of an image and matches them against known vulnerabilities, exposed secrets and misconfigurations. SecurityVault scans by immutable digest and keeps the result on the same graph as the commit that built the image and the workloads that run it. See the glossary definition.
- Which scanners run on a container image?
- trivy, grype, syft and dockle, plus the native engine's image mode, which unpacks the filesystem and runs code, secrets, dependency, IaC and supply-chain checks over it. Results that agree resolve to one finding, so a CVE reported by three tools is one item in the queue. The guide to open-source container image scanners compares what each tool finds.
- What does a container image security audit check?
- Known vulnerabilities in every layer, build practice such as running as root, secrets baked into layers, malicious or typosquatted packages, signatures and build provenance, and the full component inventory as an SBOM. Each check runs against the image digest, so the audit record describes exactly the image that ships. Open-source tools cover parts of this list; the guide to open-source container image scanners shows which.
- Why scan by digest instead of by tag?
- A tag such as latest can point at different bytes tomorrow. Every scan targets a digest-pinned reference, and the digest is confirmed before the scan starts, so the result describes exactly the image that was scanned and the image that runs.
- How do you know which workloads run an image?
- Runtime observations from the cluster sensor, cluster state collection and cloud APIs record which digest each workload runs. Observations that a newer complete snapshot no longer sees are ended, and evidence from a deregistered cluster is shown as history, not as active. The article on binding images to workloads by digest explains why this matters.
- Do you verify image signatures and provenance?
- Yes. cosign signatures and attestations are verified against your trust policy, always by digest, and a result is accepted only when the signed envelope binds to that exact digest. Verified SLSA provenance links the image to the repository that built it.
- Can I export an SBOM for an image?
- Yes. Each image's SBOM exports as CycloneDX or SPDX 2.3, rebuilt deterministically from the stored component inventory, with the layer each component came from. See SCA and SBOM.
Related: SCA and SBOM · secrets detection in image layers · Kubernetes security (KSPM) · risk-based vulnerability management · SecurityVault for platform engineering · cloud posture. New to the platform? Start with the quickstart.
From the blog
Further reading on container security
- Open-source container image scanners: Trivy, Grype, SyftOpen-source container image scanning tools compared: what Trivy, Grype, Syft and Dockle each find, where they disagree, and how to run them in CI.
- Build provenance: verify the image you deployVerify container build provenance against the image digest, trusted builder and approved source, then retain the evidence behind deployment decisions.
- How to prioritise container vulnerabilities: KEV, EPSS, reachPrioritise container vulnerabilities with CISA KEV, FIRST EPSS, reachability and image-to-workload exposure, so the short list is what attackers would use.
- Container image scanning: layers, base images and real fixesContainer image scanning that separates base-image, OS package and application dependency findings, so each goes to the team that can fix it.
See it on your stack
Connect one registry and one cluster.
See an image CVE with the commit that built it and the workloads running that digest today.