Container security for web applications is a chain of controls from source and dependencies to image build, registry, deployment and runtime. A clean vulnerability scan at build time does not prove that the deployed bytes came from the reviewed source, that the workload runs with safe privileges or that a compromised service cannot reach sensitive cluster resources. Teams need an enforceable path that identifies each artifact, records provenance, admits only approved workloads and detects behavior that violates the application’s intended operating envelope.
NIST SP 800-190 groups risks around images, registries, orchestrators, containers and host operating systems. That remains a useful structure, while current Kubernetes and software-supply-chain practices add stronger admission and provenance options. Start by drawing the exact trust chain for one web service: source commit, build runner, dependency sources, image digest, signature or attestation, registry repository, deployment identity, namespace, node and exposed network path. Every transition should have an owner, policy and evidence.
Threat-model the container delivery path
Consider an attacker who changes source, poisons a dependency, steals CI credentials, replaces an image tag, abuses registry permissions, submits a privileged workload or exploits the running application. Include accidental paths: a debug image reaches production, a secret is baked into a layer, a mutable tag drifts between environments, or a broad service account lets one pod enumerate the cluster. Rank scenarios by business impact and reachable assets rather than treating all scanner findings as equivalent.
Document trust boundaries around the build service, registry and cluster control plane. CI should not possess standing production administrator credentials. The registry should distinguish publishers from deployers. Admission should evaluate immutable artifact identity and workload policy before scheduling. Runtime identity should be scoped to the service’s actual API calls. If a team cannot identify which source produced a running digest and which authority admitted it, incident containment will become guesswork.
| Layer | Common failure | Preventive control | Evidence |
|---|---|---|---|
| Source/build | Unreviewed or compromised build | Protected branch, isolated runner, pinned inputs | Commit and provenance attestation |
| Image | Vulnerable or secret-bearing layers | Minimal base, secret scanning, rebuild policy | SBOM and scan tied to digest |
| Registry | Tag replacement or excess access | Immutable tags, scoped roles, retention | Push and delete audit events |
| Admission | Privileged or unsigned workload | Policy on digest and pod settings | Admission decision |
| Runtime | Escape, lateral movement or stolen token | Hardening, network policy, narrow identity | Process, network and audit telemetry |
Build minimal, reproducible and attributable images
Use reviewed base images from a small approved set. Pin by digest when reproducibility matters, and define how updates are discovered so pinning does not freeze vulnerabilities. Multi-stage builds can keep compilers and package managers out of the runtime image. Remove caches and test credentials. Run as a non-root numeric user where possible, set a read-only root filesystem and write only to declared volumes or temporary paths. Treat the Dockerfile and build configuration as production code.
Generate an SBOM and vulnerability result for the final digest, not merely the repository name. Set remediation policy by exploitability, exposure and business consequence, with an expiry for exceptions. Rebuild when the base changes even if application source does not. SLSA describes increasing assurance for build provenance; choose a practical level and preserve an attestation that links artifact to source and builder. Signing with a system such as Cosign can establish artifact identity, but verification policy and key or identity governance determine whether that signal is trusted.
Make the registry and admission controller enforcement points
Separate repositories and permissions by environment or release authority. Developers may publish candidates without having permission to replace production artifacts. Enable immutable tags where available, but deploy by digest because tags remain human labels. Log pulls, pushes, deletions and policy changes. Replicate only approved artifacts across trust boundaries. Define retention carefully so evidence and rollback images remain available without accumulating unsupported software indefinitely.
Admission policy should reject known-dangerous settings and artifacts lacking required evidence. Kubernetes Pod Security Standards provide baseline and restricted profiles covering host namespaces, privileged containers, capabilities, volume types and related controls. Add organization-specific rules for approved registries, digest references, service accounts and image age. Roll out policy in audit and warning modes, fix legitimate workloads, then enforce. Maintain a time-bound emergency exception path with named approval and retrospective review rather than a permanent bypass namespace.
Reduce runtime privilege and lateral movement
Set CPU, memory and ephemeral-storage requests and limits based on tests; resource exhaustion is both reliability and security risk. Drop Linux capabilities and add back only those demonstrated necessary. Use seccomp defaults, prevent privilege escalation and avoid hostPath, host networking and host process namespaces. Stronger sandboxing may be appropriate for untrusted or multi-tenant code, but it changes compatibility and performance and should be evaluated against the threat model rather than adopted as a label.
Use a dedicated service account per workload and disable automatic token mounting when the application does not call the Kubernetes API. Apply namespace and cloud-identity controls separately. Default-deny network policy is useful only when the network implementation enforces it and required DNS, ingress and egress paths are documented. Protect metadata services and restrict outbound access to sensitive control systems. Encrypt transport, but do not mistake service mesh deployment for authorization design.
| Release gate | Question | Fail condition |
|---|---|---|
| Artifact identity | Can the digest be traced to reviewed source and builder? | Only a mutable tag is known |
| Known risk | Are findings triaged with bounded exceptions? | Critical exposed issue has no decision owner |
| Workload policy | Does the manifest meet enforced restricted settings? | Privileged access is unexplained |
| Identity/network | Can the service reach only required APIs and destinations? | Default service account or broad egress |
| Operations | Can responders isolate and redeploy from trusted artifacts? | Recovery depends on editing a live container |
Keep secrets out of images and preserve useful telemetry
Inject secrets at runtime from a managed source and scope access to workload identity. Kubernetes Secret objects require appropriate encryption and RBAC; base64 representation is not protection. Avoid exposing values through command arguments, environment dumps or logs. Rotate credentials and exercise the application’s behavior during rotation. A leaked secret remains an incident even if the image is deleted because registry caches, developer machines and exported layers may retain it.
Collect Kubernetes audit events, admission decisions, registry events, workload logs, process and network signals appropriate to the risk. Alert on privileged workload creation, exec into production, unexpected image digest, service-account misuse and denied policy changes. Tune detection against known deployment behavior. Preserve container and node context so an ephemeral pod can be tied to release, owner and incident. Do not rely on shell access for diagnosis; build structured health, metrics and safe debugging paths.
Prepare containment and recovery before an alert
A response runbook should identify how to block an image digest, revoke workload and CI identities, isolate a namespace or node, preserve evidence and redeploy from a known-good artifact. Deleting a pod may destroy volatile evidence and allow the controller to create another compromised instance. Coordinate containment with service continuity. If the issue entered through the build chain, rebuilding on the same untrusted runner is not recovery.
Exercise a poisoned dependency or stolen deployment credential. Measure time to identify affected digests, clusters and customer-facing services. After response, rotate credentials, patch source and bases, rebuild with trusted infrastructure, verify admission, and reconcile data or transactions affected while the service was compromised. Feed lessons into policy and paved-road templates so each product does not repeat the same manual repair.
Roll out container policy without breaking delivery
Inventory current workloads against the target controls and group failures by cause. Use audit and warning modes to estimate impact, then fix shared base images, deployment templates and platform defaults before asking every product team to patch manifests individually. Publish a migration date and a narrow exception process. Measure blocked releases, policy bypasses and time to resolution so enforcement does not silently push teams toward unmanaged clusters or manual production changes.
Version policy and test it against known-good and deliberately unsafe manifests. Changes to admission, networking or runtime defaults can affect availability, so stage them through representative clusters and preserve rollback. Give developers local or pull-request feedback that matches production enforcement. Document ownership for the policy engine itself, including availability, update, audit and emergency behavior. A security control that fails open without visibility or fails closed without an operational route creates a different production risk.
Key takeaways
- Trace every running digest back to reviewed source and a trusted builder.
- Deploy immutable digests and enforce artifact and workload policy at admission.
- Use restricted runtime settings, narrow identities and explicit network paths.
- Tie SBOMs, scans, signatures and exceptions to the exact artifact.
- Rehearse isolation and trusted rebuild instead of relying on pod deletion.
Frequently asked questions
Is image scanning enough for container security?
No. It addresses known package findings but not source or builder compromise, registry replacement, unsafe workload privileges, identity abuse, network exposure or runtime behavior. Scanning is one control in a verifiable delivery and operation chain.
Must every container run as non-root?
Non-root should be the default and exceptions should be justified and constrained. Some workloads may require specific privileges, but that need should lead to narrower capability, sandbox and placement decisions rather than unrestricted privilege.
Can production deploy the latest tag?
It should not. A mutable tag prevents reliable attribution and rollback. Use a human-readable version for discovery but resolve and deploy an immutable digest, preserving the release record and verification evidence.
Conclusion
Secure web application containers come from a controlled chain, not a hardened Dockerfile alone. The practical standard is whether a team can identify the running artifact, prove how it was built, explain why it was admitted, bound what it can do and replace it safely after compromise. Build that path once as a platform capability, make exceptions visible, and test response against real release infrastructure.