{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/container-security-images-registries-runtimes-hosts/", "item": { "id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "slug": "container-security-images-registries-runtimes-hosts", "url": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts.md", "json": "https://update.dsesecurity.com/api/v1/posts/container-security-images-registries-runtimes-hosts/" }, "title": "Secure containers across images, registries, runtimes, and hosts", "summary": "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.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:34:09+00:00", "modified_at": "2026-08-26T13:27:47+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 504, "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.", "primary_source": { "name": "NIST SP 800-190 — Application Container Security Guide", "url": "https://csrc.nist.gov/pubs/sp/800/190/final", "published_on": "2017-09-25", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what NIST covers

\n

NIST SP 800-190 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.

\n

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.

\n

What the source does not establish

\n

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.

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: verify the full chain

\n

The following steps are DSE recommendations based on the cited source.

\n
    \n
  1. Approve base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision.
    2. \n
  2. Minimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container.
    3. \n
  3. Restrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it.
    4. \n
  4. 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.
    5. \n
  5. 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.
    6. \n
  6. Rehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation.
    7. \n
\n

Verification and evidence

\n

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.

\n

Official references

\n", "content_text": "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.\nSource fact: what NIST covers\nNIST SP 800-190 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.\nThe 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.\nWhat the source does not establish\nUsing 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.\nThe 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.\nApplicability questions\n\nWho controls the base images, dependencies, build service, registry, signing or integrity mechanism, and deployment policy?\nCan a mutable tag cause different content to run under the same name?\nWhich identities can publish, approve, pull, deploy, exec into, or change a workload?\nWhat host resources, secrets, networks, storage, devices, or orchestration APIs can the container reach?\nHow will the organization find every running instance of a withdrawn image digest?\n\nDSE recommendation: verify the full chain\nThe following steps are DSE recommendations based on the cited source.\n\nApprove base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision.\nMinimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container.\nRestrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it.\nSet 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.\nPatch and monitor the host and orchestration layers as production infrastructure. Preserve events that connect a running workload to its image digest and deployment change.\nRehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation.\n\nVerification and evidence\nChoose 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.\nOfficial references\n\nNIST SP 800-190 — Application Container Security Guide — National Institute of Standards and Technology; finalized September 25, 2017\nNIST Secure Software Development Framework — National Institute of Standards and Technology", "content_markdown": "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.\n\n## Source fact: what NIST covers\n\n[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.\n\nThe 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.\n\n## What the source does not establish\n\nUsing 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.\n\nThe 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.\n\n## Applicability questions\n\n- Who controls the base images, dependencies, build service, registry, signing or integrity mechanism, and deployment policy?\n\n- Can a mutable tag cause different content to run under the same name?\n\n- Which identities can publish, approve, pull, deploy, exec into, or change a workload?\n\n- What host resources, secrets, networks, storage, devices, or orchestration APIs can the container reach?\n\n- How will the organization find every running instance of a withdrawn image digest?\n\n## DSE recommendation: verify the full chain\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Approve base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision.\n\n- Minimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container.\n\n- Restrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it.\n\n- 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.\n\n- 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.\n\n- Rehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation.\n\n## Verification and evidence\n\nChoose 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.\n\n## Official references\n\n- [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\n\n- [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "url": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Secure containers across images, registries, runtimes, and hosts", "item": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/#article", "identifier": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "url": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/", "headline": "Secure containers across images, registries, runtimes, and hosts", "description": "Containers package applications but depend on a broader system. Govern image origin, build evidence, registry access, runtime policy, host security…", "abstract": "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.", "articleBody": "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.\nSource fact: what NIST covers\nNIST SP 800-190 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.\nThe 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.\nWhat the source does not establish\nUsing 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.\nThe 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.\nApplicability questions\n\nWho controls the base images, dependencies, build service, registry, signing or integrity mechanism, and deployment policy?\nCan a mutable tag cause different content to run under the same name?\nWhich identities can publish, approve, pull, deploy, exec into, or change a workload?\nWhat host resources, secrets, networks, storage, devices, or orchestration APIs can the container reach?\nHow will the organization find every running instance of a withdrawn image digest?\n\nDSE recommendation: verify the full chain\nThe following steps are DSE recommendations based on the cited source.\n\nApprove base-image sources and record immutable image identifiers. Retain the source revision, dependency set, build identity, build result, and promotion decision.\nMinimize images and remove unnecessary tools, packages, credentials, and services. Rebuild from maintained inputs rather than making undocumented changes to a running container.\nRestrict registry publishing, artifact promotion, orchestration administration, secret access, and interactive runtime access. Separate build and production duties where risk justifies it.\nSet 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.\nPatch and monitor the host and orchestration layers as production infrastructure. Preserve events that connect a running workload to its image digest and deployment change.\nRehearse withdrawal: identify every instance, stop or replace it safely, preserve evidence, verify service health, and prevent the artifact from returning through automation.\n\nVerification and evidence\nChoose 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.\nOfficial references\n\nNIST SP 800-190 — Application Container Security Guide — National Institute of Standards and Technology; finalized September 25, 2017\nNIST Secure Software Development Framework — National Institute of Standards and Technology", "datePublished": "2026-08-25T21:34:09+00:00", "dateModified": "2026-08-26T13:27:47+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/container-security-images-registries-runtimes-hosts/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Secure containers across images, registries, runtimes, and hosts" }, "articleSection": [ "Cybersecurity", "IT", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "IT", "Networks & Infrastructure", "Checklist", "Important priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 504, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "NIST SP 800-190 — Application Container Security Guide", "url": "https://csrc.nist.gov/pubs/sp/800/190/final", "datePublished": "2017-09-25" } } ] } }