The practice of protecting containerised applications, their images, runtime environments, and supporting infrastructure from compromise. It covers the full path from build to deployment to execution, because risk can be introduced in the image, the orchestrator, the secrets mechanism, or the cloud permissions the workload inherits.
Expanded Definition
Container security is broader than scanning a container image before release. It includes image provenance, dependency integrity, registry controls, runtime hardening, orchestrator policy, node security, and the credentials or NIST Cybersecurity Framework 2.0 outcomes that govern how the workload is allowed to communicate and change state.
In practice, the term covers both build-time and run-time protection. A secure image can still become a compromise point if it runs with excessive privileges, mounts sensitive host paths, inherits broad cloud permissions, or exposes secrets through environment variables. Definitions vary across vendors on where container security ends and platform security begins, but the operational boundary is usually the workload, the control plane, and the supporting identity and access model.
For NHIMG, the identity dimension matters because containers often authenticate through service accounts, workload identities, short-lived tokens, and secrets managers rather than human logins. That means container security is not only about code hygiene, but also about who or what is authorised to pull images, deploy workloads, and invoke internal services. The most common misapplication is treating image scanning as complete protection, which occurs when teams ignore runtime permissions, secrets exposure, and orchestrator policy drift.
Examples and Use Cases
Implementing container security rigorously often introduces deployment friction, requiring organisations to weigh rapid release velocity against image integrity checks, privilege limits, and runtime policy enforcement.
- Signing and verifying images before deployment so only approved builds from a trusted pipeline reach production, with provenance checks aligned to the NIST Cybersecurity Framework 2.0 approach to controlled change.
- Running containers as non-root, dropping unnecessary Linux capabilities, and blocking privileged mode to reduce the blast radius if an application is exploited.
- Using Kubernetes admission controls to prevent risky manifests, such as hostPath mounts, exposed host networking, or unconstrained service account usage.
- Storing API keys, tokens, and certificates in a dedicated secrets manager rather than baking them into images or environment variables that can be read from a compromised pod.
- Monitoring runtime behaviour for suspicious process launches, outbound connections, or unexpected writes, especially when the container inherits cloud permissions through an attached identity.
Security teams also use container isolation to support multi-tenant platforms, where one application’s misconfiguration must not expose another tenant’s data or credentials. In regulated environments, container controls often become part of evidence for secure build pipelines and least-privilege operations, even when the underlying application is otherwise cloud native.
Why It Matters for Security Teams
Container security matters because containers compress many trust decisions into a small execution unit. If image supply chain checks, cluster policy, and workload identity are misaligned, attackers can move from a single vulnerable container to broader cloud resources, internal services, or sensitive secrets. That is why container security is often evaluated alongside cloud governance, access control, and supply chain assurance rather than as a standalone tooling category.
For identity-focused teams, the key issue is that containers frequently depend on non-human identities. Service accounts, machine certificates, and ephemeral tokens can become durable attack paths if they are over-permissioned or reused across environments. When container workloads connect to CI/CD pipelines, secret stores, and API gateways, weak identity hygiene becomes an infrastructure-wide exposure. Guidance is still evolving on the exact boundary between container security, CNAPP, and workload identity governance, so practitioners should define control ownership clearly.
Organisations typically encounter container security as an urgent priority only after a compromised image, exposed secret, or cluster breach forces them to trace how the workload gained access in the first place, at which point container security becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when containers inherit identities and permissions. |
| NIST SP 800-63 | AAL2 | Workload access often depends on credential assurance concepts mapped from identity guidance. |
| NIST SP 800-53 Rev 5 | CM-6 | Secure configuration baselines are a core control for container platforms and orchestration. |
Use strong, short-lived credentials for service identities and avoid reusable long-lived secrets.
Related resources from NHI Mgmt Group
- What is the difference between shift left and runtime enforcement for container security?
- What is the difference between static image security and runtime container security?
- How should security teams govern signing keys in container pipelines?
- What is the difference between provenance and integrity in container security?
