What do organisations get wrong about container security?

Why This Matters for Security Teams

Container security is often treated as a narrow hardening exercise, but that misses the real attack surface. A container is only one packaging layer in a broader supply chain that includes source code, dependencies, CI/CD, registry trust, orchestration policy, and runtime isolation. If teams focus only on image scanning or one-time baseline checks, they can still ship vulnerable workloads with overbroad permissions, exposed secrets, or unsafe defaults.

The better framing is lifecycle governance aligned to the NIST Cybersecurity Framework 2.0, not just runtime defense. NHIMG research shows how quickly exposed credentials become operational risk: in the LLMjacking research, attackers attempted access to publicly exposed AWS credentials in an average of 17 minutes. That is the practical lesson for containers too. Misconfigurations, leaked secrets, and weak orchestration policy are usually exploited before a team finishes its next review cycle.

In practice, many security teams discover container exposure only after an image has already been deployed with excessive permissions or embedded secrets, rather than through intentional pre-production governance.

How It Works in Practice

Effective container security starts before a container is built and continues after it is running. The core mistake is assuming that scanning an image is enough. Image scanning helps, but it does not address whether the base image is trusted, whether the dependency chain is controlled, whether the runtime has unnecessary Linux capabilities, or whether the orchestrator is allowing privileged execution.

Practitioners usually need to cover four control points. First, secure the build pipeline so only approved sources, signed artifacts, and known dependencies enter the registry. Second, enforce deployment policy so the scheduler blocks privileged containers, host mounts, and unrestricted network paths. Third, protect secrets at runtime with short-lived credentials rather than baking tokens into images. Fourth, monitor running workloads for drift, unexpected process behavior, and lateral movement.

• Use policy-as-code to reject insecure manifests before deployment.
• Keep secrets out of images and inject them at runtime with short TTLs.
• Restrict namespace, capability, and filesystem access to the minimum required.
• Continuously verify what is actually running, not just what was approved.

Current guidance suggests aligning container controls with broader workload identity and zero trust practices, especially when using CISA Zero Trust guidance or platform-native policy engines. NHIMG’s State of Secrets in AppSec research reinforces why this matters: secret sprawl and slow remediation create a long tail of exposure that container hardening alone cannot fix. These controls tend to break down when teams allow ad hoc image promotion across environments because policy and runtime state drift faster than manual review can keep up.

Common Variations and Edge Cases

Tighter container controls often increase delivery friction, requiring organisations to balance deployment speed against trust boundaries. That tradeoff is real, especially in high-change environments where developers expect rapid release cycles and platform teams are asked to support both security and uptime.

There is no universal standard for every container environment yet, so the right answer depends on risk and operating model. In regulated environments, immutable images, signed attestations, and strict admission control are usually non-negotiable. In ephemeral dev and test environments, the priority may be reducing blast radius through network isolation and secrets hygiene rather than full production-grade hardening.

Common edge cases include sidecars that inherit broader access than the primary application, service meshes that obscure traffic visibility, and managed Kubernetes defaults that look secure but leave policy gaps. Another frequent miss is assuming namespace separation equals isolation. It does not. A compromised workload can still abuse mounted credentials, cloud metadata access, or misconfigured RBAC if those controls are not explicitly constrained. The most reliable approach is to treat containers as one enforcement point inside a larger workload governance model, not as the boundary itself.

Related resources from NHI Mgmt Group

• What do organisations get wrong about access friction and identity security?
• What do organisations get wrong about identity recovery and helpdesk support?
• What do security teams get wrong about persona-based identity reporting?
• What do organisations get wrong about temporary access in SaaS platforms?