# Secure containers across images, registries, runtimes, and hosts > Containers package applications but depend on a broader system. Govern image origin, build evidence, registry access, runtime policy, host security, monitoring, and retirement as one lifecycle. - Canonical URL: https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:09+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Containers package applications but depend on a broader system. Govern image origin, build evidence, registry access, runtime policy, host security, monitoring, and retirement as one lifecycle. ## Potentially affected Organizations building, acquiring, storing, deploying, or operating application containers in on-premises, hosted, or cloud environments. ## DSE recommendation Maintain a traceable image-to-runtime chain, minimize and verify images, constrain registry and orchestration access, harden the host boundary, and prove that vulnerable or unapproved artifacts can be located and withdrawn. ## Article Bottom line: a container image is only one part of the security boundary. The build inputs, registry, orchestrator, runtime configuration, host operating system, network paths, secrets, and monitoring all influence what code runs and what it can reach. ## Source fact: what NIST covers [NIST SP 800-190](https://csrc.nist.gov/pubs/sp/800/190/final) describes application containers as operating-system virtualization combined with application packaging. NIST explains that containers provide a portable, reusable, and automatable way to package and run applications. The guide addresses potential security concerns and recommendations for container use. The publication is a technology guide, not a product certification. Its September 2017 date also means teams should pair its enduring architectural guidance with current documentation for the chosen operating system, orchestrator, registry, cloud service, and image tooling. ## What the source does not establish Using containers does not automatically isolate an application to the degree its owner expects. A passed image scan does not establish provenance, safe runtime configuration, host integrity, correct authorization, or absence of a newly disclosed issue. An orchestrator’s default settings and available controls can vary by product and version. The source does not guarantee that a container can be rebuilt, rolled back, or investigated. Those outcomes require retained inputs, immutable identifiers, logs, and tested operating procedures. ## Applicability questions - Who controls the base images, dependencies, build service, registry, signing or integrity mechanism, and deployment policy? - Can a mutable tag cause different content to run under the same name? - Which identities can publish, approve, pull, deploy, exec into, or change a workload? - What host resources, secrets, networks, storage, devices, or orchestration APIs can the container reach? - How will the organization find every running instance of a withdrawn image digest? ## DSE recommendation: verify the full chain The following steps are DSE recommendations based on the cited source. - Approve base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision. - Minimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container. - Restrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it. - Set explicit runtime policy for privilege, filesystem writes, host mounts, device access, resource limits, network flows, and service identity. Test that disallowed behavior is actually blocked. - Patch and monitor the host and orchestration layers as production infrastructure. Preserve events that connect a running workload to its image digest and deployment change. - Rehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation. ## Verification and evidence Choose one deployed workload and trace it backward from runtime to image digest, registry record, build, source, dependencies, approvals, and base image. Then test a denied privilege, an image withdrawal, and restoration of the service. Record environment, timestamps, identities, results, and residual exceptions. ## Official references - [NIST SP 800-190 — Application Container Security Guide](https://csrc.nist.gov/pubs/sp/800/190/final) — National Institute of Standards and Technology; finalized September 25, 2017 - [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-190 — Application Container Security Guide - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/190/final - Source publication date: 2017-09-25 ## Citation and use Preferred citation: “Secure containers across images, registries, runtimes, and hosts,” DSE Security, https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.