A container image carries its whole operating system userland, its libraries and anything a developer copied in, so a vulnerable package, a wide-open port or a forgotten private key ships to every node that pulls it. MITRE D3FEND names the countermeasure Container Image Analysis (D3-CIA), with the synonym Container Image Scanning, and defines it briefly: "Analyzing a Container Image with respect to a set of policies." It sits in the Model tactic as the only child of Asset Vulnerability Enumeration (D3-AVE). This guide covers what an image analysis should check, where in the pipeline to run it, how to enforce results at admission, how to verify the control and where it falls short. It is for platform engineers, DevSecOps teams and Kubernetes administrators. Wider image practice is in the Container Image Security Guide; this page stays on the D3FEND technique and its operation.
Key takeaways
- Policy, not just CVEs. D3FEND's description lists three things to find: outdated libraries, known vulnerabilities and misconfigurations such as insecure ports or permissions. Secrets and licences are common additions.
- Scan throughout the build workflow. D3FEND says images should be scanned throughout the container build workflow, which in practice means at build, in the registry, and again when new advisories appear.
- Admission control turns analysis into prevention. D3FEND names an admission controller that blocks deployments of non-compliant images as one implementation approach.
- False positives need a governed path. D3FEND expects the scanning to let knowledgeable professionals disregard false positives; use VEX statements or recorded exceptions, not silent ignore lists.
- It does not fix the build. D3FEND's own considerations note the technique does not necessarily prevent the build process adding insecure or unsecured files to the image; trusted base images and build hygiene still matter.
D3-CIA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CIA (d3f:ContainerImageAnalysis) |
| Synonym | Container Image Scanning |
| Tactic | Model |
| Parent technique | Asset Vulnerability Enumeration (D3-AVE), itself a child of Asset Inventory |
| D3FEND relation | analyzes Container Image |
| D3FEND reference | NSA Kubernetes Hardening Guide ("Container Images can contain unneeded, unsecured or insecure files") |
| Typical outputs | Per image digest: package list (SBOM), vulnerabilities with fixed versions, misconfiguration findings, secrets found, licence findings, pass or fail against policy |
| Main limitation | Static: it sees what is in the image, not what the container does at runtime |
What the analysis should check
| Check | What it looks for | Example policy rule (an example, not a standard) |
|---|---|---|
| Known vulnerabilities | OS and language packages matched to advisories | Fail on any CVE in the CISA KEV catalogue with a fix available; fail on critical findings with a fix older than an agreed number of days |
| Outdated libraries and base image | Base image age and end-of-life components | Fail if the base image is not on the approved list or is past its support date |
| Misconfiguration | Image metadata and Dockerfile or build settings: root user, exposed ports, added capabilities, package manager caches | Fail if the image runs as root or exposes administrative ports |
| Secrets | Private keys, cloud keys, tokens and passwords in any layer | Fail on any secret; treat the secret as compromised and rotate it |
| Licences | Licences of included packages | Warn on licences legal has not approved |
| Provenance | Signature and attestations for the image digest | Fail at admission if the image is not signed by the organisation's build identity |
Secrets deserve particular attention because deleting a file in a later layer does not remove it from earlier ones. The Secrets in Docker Hub Images page summarises an RWTH Aachen study of 337,171 images in which about 8.5% contained secrets, including tens of thousands of valid private keys, which is exactly what a secrets check in D3-CIA is meant to catch before publication. See also How to find hard-coded secrets in container images.
Where to run it
| Point | Purpose | Trade-off |
|---|---|---|
| Developer workstation and pull request | Fast feedback before merge | Advisory only; developers can skip it |
| CI build | Gate the push to the registry; produce the SBOM | Blocks releases if policy is too strict for the current backlog |
| Registry (on push and on a schedule) | Catch new CVEs in images already stored | Findings arrive after the image may be running |
| Admission to the cluster | Refuse non-compliant or unsigned images at deploy time | Needs a failure mode decision if the policy service is down |
| Running workloads | Re-evaluate the images in use against new advisories | Needs a live inventory of image digests per cluster |
Decision guidance: a small team can start with a scanner in CI plus the registry's own scanning, and add admission control once the backlog is manageable. Larger organisations with many clusters should enforce at admission from the start for production namespaces, because CI gates are easy to bypass with an image pushed from elsewhere. Platforms that hold many tenants benefit from AlwaysPullImages (see below) so images cached on a node cannot be reused without pull credentials.
Tools in general terms
Open source and commercial scanners do the analysis; several examples are listed alphabetically, with no ranking intended. Grype, sponsored by Anchore and licensed Apache-2.0, scans container images, filesystems and SBOMs across OS packages (Alpine, Debian, Ubuntu, RHEL and others) and language ecosystems, and supports OpenVEX to filter results. Trivy, built by Aqua Security and licensed Apache-2.0, scans container images, filesystems, Git repositories, virtual machine images and Kubernetes clusters for vulnerabilities, misconfigurations, secrets and licences, and produces SBOMs. Cloud provider registries and commercial container security platforms also offer image scanning; evaluation criteria are in the Container Security Buyer's Guide.
Enforcing at admission
D3FEND's description explains the mechanism: an admission controller intercepts requests to the orchestration API after authentication and authorisation but before the object is persisted, and a webhook can scan any image before it is deployed. Kubernetes offers several routes.
- ValidatingAdmissionWebhook: calls external validating webhooks in parallel; if any rejects the request, it fails. Policy engines and image verification services plug in here.
- ImagePolicyWebhook: lets a backend webhook make image admission decisions. It is disabled by default, must talk to its backend over TLS, and its configuration includes a
defaultAllowsetting that decides behaviour when the backend fails. Set it deliberately: fail-open keeps deployments flowing during an outage but admits unchecked images. - AlwaysPullImages: forces every new Pod's pull policy to Always, so a private image already on a node cannot be used by another tenant without credentials.
- Signature verification: the Sigstore policy-controller is an admission controller that validates signatures and attestations with ClusterImagePolicy resources, resolves tags to digests so the running image matches the admitted one, and by default checks only namespaces labelled
policy.sigstore.dev/include: "true". It has a warn mode for piloting. Its documentation states it is still under active development.
Pin images by digest in production manifests so the image that was scanned is the image that runs. More detail is in the Kubernetes Admission Control Guide.
Where identity fits
Three machine identities sit around D3-CIA. The CI pipeline identity that pushes to the registry and signs images should be the only identity that can produce an admissible image; protect its signing key or use keyless signing bound to the workload identity. The scanner's registry pull credential can read every image, including ones holding secrets, so scope it read-only and rotate it. And any credential the scan finds inside an image is a leaked non-human identity: rotate it, then trace where the image was pulled. See the Kubernetes NHI Security Guide.
How to build it
- Inventory images in use. List image digests running in each cluster and the registries they come from; this is the scope D3-CIA must cover.
- Write the policy. Agree fail and warn rules for vulnerabilities, base images, misconfiguration, secrets and licences, with an owner for exceptions.
- Scan in CI and generate an SBOM. Store the SBOM with the image digest so re-evaluation does not need a rescan.
- Turn on registry scanning. Scan on push and on a schedule so stored images are re-checked against new advisories.
- Pilot admission in warn mode. Enable admission checks for one namespace in audit or warn mode, review what would have been blocked, and fix pipelines first.
- Enforce for production. Switch to deny for production namespaces, decide the fail-open or fail-closed behaviour and document the emergency bypass (who approves, how it is logged, when it expires).
- Govern exceptions. Record each accepted finding as a VEX statement or a dated exception with justification; review expiries monthly.
- Roll back: if enforcement blocks critical deployments unexpectedly, return the namespace to warn mode rather than removing the webhook, so visibility remains while the cause is fixed.
How to verify it works
- Known-bad test image: keep a test image with an old vulnerable package, a root user and a dummy key string. CI must fail it, the registry must flag it and admission must refuse it in an enforced test namespace.
- Bypass test: push an image directly to the registry without the pipeline and try to deploy it; signature verification should refuse it.
- Outage test: in a test cluster, stop the policy backend and confirm the cluster behaves as the documented failure mode says.
- Drift check: compare running image digests with the last scan results to find images never scanned or scanned too long ago.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | What it shows |
|---|---|---|
| Running image digests with a scan in the last 7 days | 100% in production | Coverage of what actually runs |
| Production namespaces with admission enforcement | 100% | Whether analysis prevents, not just reports |
| Images in production with a KEV-listed CVE | Zero beyond the agreed fix window | Risk that matters most |
| Secrets found in images per month | Falling towards zero | Build hygiene improving |
| Expired exceptions still in force | Zero | Exception discipline |
ATT&CK techniques D3FEND relates to D3-CIA
Relationship type: inferred only. D3FEND derives these links through the Software and Container Image artefacts, largely inherited from its parent D3-AVE (D3FEND 1.6.0, checked November 2026). Many of the rows concern Windows hosts and firmware rather than containers, which shows that the inference is broad. The rows that matter most for images are the supply chain ones. IDs were checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND lists with IDs |
|---|---|
| Initial Access | T1195.001 Compromise Software Dependencies and Development Tools, T1195.002 Compromise Software Supply Chain |
| Persistence | T1505.001 SQL Stored Procedures, T1505.004 IIS Components, T1137.006 Add-ins, T1547.008 LSASS Driver, T1546.011 Application Shimming |
| Persistence and Stealth (pre-OS) | T1542.001 System Firmware, T1542.002 Component Firmware, T1542.003 Bootkit, T1542.004 ROMMONkit |
| Stealth and Execution | T1574.005 Executable Installer File Permissions Weakness, T1574.010 Services File Permissions Weakness, T1127.001 MSBuild, T1218.014 MMC, T1564.006 Run Virtual Instance, T1497.003 Time Based Checks |
| Collection | T1056.003 Web Portal Capture |
D3FEND's page also lists further related entries without IDs. Container-specific techniques such as implanting a malicious internal image are better addressed by signing, digest pinning and admission control described above than by vulnerability matching alone.
Common failure patterns
- Scanning tags, running digests: a tag scanned last week now points at a different image; without digest pinning the scan result describes something else.
- CI-only gates: images pushed by hand or from another pipeline skip the scan and run anyway because nothing checks at admission.
- Fail-open without monitoring: the admission backend is down for days and every image is admitted unchecked.
- Exception lists that never expire: a CVE ignored for one image is ignored for every image forever.
- Secrets "removed" in a later layer: the key is still in the earlier layer and in every copy of the image.
- Ignoring the base image: teams fix their own dependencies while the inherited base image ages, carrying most of the findings.
Framework mapping
| Framework | Reference | Relevance to D3-CIA |
|---|---|---|
| NIST SP 800-190 | Application Container Security Guide | Container security concerns and recommendations, including image risks |
| NIST SP 800-53 Rev. 5 | RA-5 | Vulnerability monitoring and scanning, applied to images |
| NIST SP 800-53 Rev. 5 | CM-14, SI-7 | Signed components; software, firmware and information integrity at admission |
| NIST SP 800-53 Rev. 5 | SR-4, CM-8 | Provenance of components; component inventory through SBOMs |
| NIST CSF 2.0 | ID.RA-01, PR.PS-02 | Vulnerabilities identified and recorded; software maintained and replaced commensurate with risk |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management | Image scanning is part of continuous vulnerability management |
| MITRE D3FEND | D3-AVE, D3-CIA | Parent and technique |
Related countermeasures
- Asset Vulnerability Enumeration (D3-AVE): the parent, covering vulnerability enrichment for every asset type. See D3-AVE Asset Vulnerability Enumeration.
- Configuration Inventory (D3-CI): records live cluster and workload configuration that complements static image checks. See D3-CI Configuration Inventory.
- Software Inventory (D3-SWI): image SBOMs feed it. See D3-SWI Software Inventory.
Practitioner checklist
- Keep an inventory of image digests running in every cluster.
- Scan in CI, on registry push and on a schedule, and store an SBOM per digest.
- Include vulnerability, base image, misconfiguration, secret and licence checks in the policy.
- Enforce at admission for production namespaces, with a documented failure mode.
- Pin production images by digest and verify signatures from the organisation's build identity.
- Rotate any credential found in an image and trace where that image was pulled.
- Record exceptions as VEX statements or dated, approved exceptions.
- Test with a known-bad image and a pipeline bypass attempt each quarter.
Standards and references
- MITRE D3FEND: Container Image Analysis (D3-CIA)
- NIST: SP 800-190 Application Container Security Guide
- Kubernetes: Admission Control in Kubernetes
- Sigstore: Policy Controller overview
- CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
- CISA: Known Exploited Vulnerabilities
- Anchore: Grype documentation
- Aqua Security: Trivy documentation
Related NHI Mgmt Group resources: Container Image Security Guide · Container Registry Security Guide · Kubernetes Admission Control Guide · SBOM Guide · MITRE D3FEND Guide