Container Security Maturity Model: Five Levels

Most organisations run containers in production long before they can say which images are running, who built them, what they are allowed to do and which credentials they carry. This model uses NHI Mgmt Group's five levels, Ad hoc, Developing, Defined, Managed and Optimised, to score container security across six capability areas: images, build and supply chain, registries, admission control, runtime and cluster identity. It is written for platform, security and engineering leaders who need to assess where they are, set a realistic target and explain the gap to management. It assumes you know the risks; the Top 10 Container Security Risks and the Container Security Guide cover the discipline itself, and this page covers staged maturity.

Key takeaways

Admission control is the pivot. Until the cluster can refuse a non-compliant workload, every image and pod rule is advice; Kubernetes Pod Security Admission in enforce mode is the cheapest first gate.
Images are where secrets leak. In December 2025 Flare reported 10,456 public container images with exposed keys, and most removed secrets were reportedly never revoked.
Cluster identity is non-human identity. Service account tokens, cloud keys in pods and CI credentials decide how far one compromised container can reach, as the Tesla Kubernetes cryptojacking case showed.
Level 3 is the first sensible target: a minimal base image standard, scanning in the pipeline, digest or signature-pinned deployments, Baseline or Restricted pod security enforced in every namespace, default-deny network policies and audit logs collected.
Score per area and report the lowest. A strong image scanning programme on a cluster where any pod can run privileged is a Level 1 runtime, and the weakest area is where an attacker starts.

The five levels

Level	Name	What it looks like
1	Ad hoc	Teams pull public images by the `latest` tag. Images run as root with shells and tools inside. No scanning. Pods use the `default` service account with its token mounted. Cloud keys sit in environment variables. Network traffic inside the cluster is unrestricted. Nobody reads the API server audit log, if it is enabled at all.
2	Developing	Some approved base images and a private registry. Images are scanned, but results do not block anything. Pod security labels applied to a few namespaces in warn or audit mode. RBAC exists but cluster-admin is widely held. Secrets moved from images into Kubernetes Secrets without encryption at rest.
3	Defined	A container security standard sets minimal base images, non-root users, scanning thresholds and deployment by digest. Pod Security Admission enforces Baseline everywhere and Restricted for application namespaces. Default-deny network policies per namespace. A dedicated service account per workload, automounting disabled where the API is not needed. Encryption at rest for Secrets. Audit logs collected centrally.
4	Managed	Builds run on a hosted, hardened platform that produces signed provenance, and admission verifies signatures before a pod starts. Registry and running workloads are rescanned continuously with fix SLAs. Runtime detection alerts on shells, new processes and unexpected network calls. Workloads reach cloud services through workload identity federation, not stored keys. Metrics reported monthly.
5	Optimised	Policy as code covers build, admission and runtime, tested in the pipeline. Provenance requirements are enforced for every production image. Runtime detections trigger automated response such as isolating a pod or revoking its credentials. Access to clusters is just in time. Lessons from incidents and exercises feed policy changes within weeks.

Capability areas

Score each area separately. The columns show what Levels 1, 3 and 5 look like; Levels 2 and 4 sit between them.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Images	Any public image, root user, full operating system	Approved minimal base images, `USER` set to an unprivileged account, no shells or debug tools in production, scanning with blocking thresholds	Base images rebuilt automatically on upstream fixes; image age and vulnerability budget enforced
Build and supply chain	Built on laptops or shared runners with long-lived credentials	Builds in CI only; secrets scanning on images before push; SBOM generated per image	Hosted, isolated builds with signed provenance (SLSA Build L3 style); signing keys out of reach of build steps
Registries	Public registry accounts, personal namespaces	Private registry, access controlled, pull through approved mirrors, continuous rescanning	Only signed images with provenance accepted; stale and unowned repositories removed
Admission control	None; anything that applies is scheduled	Pod Security Admission enforces Baseline cluster-wide and Restricted for applications; digest pinning required	Signature and provenance verification at admission; policy as code with tests and reviewed exemptions
Runtime and network	Privileged pods, host mounts, flat network, metadata API reachable	Default-deny network policies, seccomp `RuntimeDefault`, metadata API access filtered, resource limits set	Behavioural runtime detection with automated isolation; sensitive workloads on dedicated nodes
Cluster identity and secrets	`default` service account everywhere, cloud keys in pods, cluster-admin shared	One service account per workload, least-privilege RBAC, automount off where not needed, bound tokens, Secrets encrypted at rest, access reviews	Workload identity federation for cloud access, external secrets store, just-in-time human access, `system:masters` used only for break glass

Dimension detail: what moves each area up

Images, Level 2 to 3: the Kubernetes security checklist asks for minimal content in images, images that run as an unprivileged user, and production images without shells or debugging utilities, using ephemeral debug containers for troubleshooting instead. See the Hardened and Minimal Base Images Guide and the Container Image Security Guide.
Build, Level 2 to 3: scan built images for secrets before they are pushed, not only for vulnerabilities. The Flare research found AI model API keys were the most common secret type in leaked images, alongside cloud, database and source control credentials. See the Secrets in Container Images and Build Artefacts Guide.
Build, Level 3 to 4: SLSA defines Build L1 as provenance exists, L2 as a hosted build platform with signed provenance, and L3 as hardened builds that isolate runs from each other and keep signing secrets away from user-defined build steps. See the SLSA and Build Provenance Guide and the Sigstore Guide.
Admission, Level 2 to 3: Pod Security Admission applies the Pod Security Standards per namespace using labels of the form pod-security.kubernetes.io/<mode>: <level>. Roll out with warn and audit first, then switch to enforce. Note that warn and audit are applied to workload resources such as Deployments, while enforce applies only to the resulting pods. See the Kubernetes Admission Control Guide.
Admission, Level 3 to 4: the Kubernetes checklist accepts either sha256 digest references or deploy-time signature verification through admission control; Level 4 does both.
Runtime, Level 2 to 3: apply a default-deny policy selecting all pods in each namespace, filter workload access to the cloud metadata API, and keep the API server, kubelet API and etcd off the internet. See the Container Runtime Security Guide.
Identity, Level 2 to 3: set automountServiceAccountToken: false for pods that do not call the API and use bound, projected tokens that expire and rotate. Legacy Secret-based tokens do not expire; before v1.24 one was created automatically for every service account, so older clusters may still hold them. See the Kubernetes Service Account Token Guide and the Kubernetes NHI Security Guide.

Mapping to frameworks and techniques

Source	Reference	Relevance to the model
NIST SP 800-190	Application Container Security Guide	Risks and countermeasures for images, registries, orchestrators, containers and host operating systems
NIST SP 800-53 Rev. 5	CM-6, CM-7	Configuration settings and least functionality: pod security and minimal images
NIST SP 800-53 Rev. 5	SI-7, SR-11	Software integrity and component authenticity: signing and provenance
NIST SP 800-53 Rev. 5	RA-5	Vulnerability monitoring and scanning of images and running workloads
NIST SP 800-53 Rev. 5	AC-2, AC-6	Service account management and least-privilege RBAC
NIST CSF 2.0	PR.PS-01	Configuration management practices established and applied
MITRE ATT&CK	T1610 Deploy Container, T1611 Escape to Host	What admission control and pod security are meant to stop
MITRE ATT&CK	T1525 Implant Internal Image	Why registry access control and signing matter
MITRE ATT&CK	T1552.007 Container API, T1613 Container and Resource Discovery	Credential theft and discovery that cluster identity controls limit

Self-assessment questions

Answer for your production clusters first. A control in place on one cluster but not the others scores Level 2.

Images

Can you list every image running in production today, with its base image, age and owner?
What share of production images run as a non-root user and contain no shell?
Does a critical vulnerability in a new image stop the pipeline, or only raise a ticket?

Build and supply chain

Are production images built only in CI, and are images scanned for secrets before they are pushed?
Can you show signed provenance for a production image and verify it?

Registries

Do any teams or contractors push company images to personal or public registry namespaces?
Are images in the registry rescanned when new vulnerabilities are published?

Admission control

Which namespaces enforce Baseline or Restricted, and which are only in warn or audit mode?
Could someone deploy an image by tag, or an unsigned image, to production today?

Runtime and network

Does every namespace have a default-deny network policy, and can pods reach the cloud metadata API?
Would you be alerted if a shell started inside a production container?

Cluster identity and secrets

How many workloads use the default service account, and how many people hold cluster-admin?
Do any pods hold long-lived cloud access keys, and are legacy service account token Secrets still present? See How to rotate a Kubernetes service account token and detect old token use.
Is encryption at rest configured for the Secret API, and are confidential values kept out of ConfigMaps?

Scoring and evidence

Evidence an assessor should ask for	Supports
Running image inventory with base image, digest, age and scan results	Images at Level 3
Pipeline configuration showing blocking scan thresholds and secrets scanning	Build at Level 3
Provenance attestations and signature verification policy	Build and admission at Level 4
Namespace labels showing pod security enforce levels, and exemption list	Admission at Level 3
Network policy inventory per namespace and runtime alert samples	Runtime at Level 3 to 4
Service account and RBAC export, cluster-admin holders, access review records	Identity at Level 3

Moving up: roadmap

Level 1 to 2, first 90 days: turn on API server audit logging and collect it; move to a private registry; start scanning images; apply pod security labels in warn and audit mode to see what would break; remove cloud access keys from pods and rotate any that were reachable.
Level 2 to 3, within 12 months: publish a container security standard; adopt minimal base images and non-root users; make scanning block on agreed thresholds; enforce Baseline everywhere and Restricted for applications; add default-deny network policies; give every workload its own service account and disable automounting where not needed; encrypt Secrets at rest. The Container and Kubernetes Security Policy Template is a starting point.
Level 3 to 4: move builds to a hosted, hardened platform producing signed provenance; verify signatures at admission; add runtime detection and continuous registry rescanning with fix SLAs; replace stored cloud keys with workload identity federation. See the Workload Identity Federation Guide.
Level 4 to 5: manage build, admission and runtime policy as tested code; connect runtime alerts to automated isolation and credential revocation; move human cluster access to just in time; rehearse the Kubernetes Cluster Compromise Playbook and feed lessons into policy.

Rollback: every enforcement step should start in an observe mode (pod security warn and audit, admission policies in audit, network policies tested in staging), with a documented exemption route and a quick way to revert a label or policy if production breaks.

Small vs large organisations: a small team running a managed Kubernetes service can reach Level 3 with built-in Pod Security Admission, native network policies, the provider's registry scanning and workload identity. A large organisation with many clusters will need policy as code, a central policy engine and fleet-wide reporting to keep levels consistent.

Metrics that show progress

Admission coverage: share of namespaces enforcing Baseline or Restricted, and the number of active exemptions.
Image hygiene: share of running images that are non-root, digest-pinned or signature-verified, and median image age.
Vulnerability exposure: critical vulnerabilities in running images and mean time to replace the image.
Identity hygiene: workloads on the default service account, cluster-admin holders, and pods holding long-lived cloud keys.
Network isolation: share of namespaces with default-deny policies.

Common failure patterns

Scanning without enforcement: dashboards full of findings while vulnerable images deploy anyway because nothing blocks them.
Exposed management interfaces: a dashboard or API reachable without authentication. In the Tesla Kubernetes cryptojacking case, attackers entered through a Kubernetes console with no password and found AWS credentials inside a pod.
Secrets baked into images: keys copied into layers during builds and pushed to registries, including personal and contractor accounts outside corporate monitoring, as in the Docker Hub secrets leak.
Deleting instead of revoking: removing a leaked secret from an image while the credential stays valid for anyone who already pulled it.
Enforce mode switched on without a dry run: production pods rejected, enforcement rolled back and never reinstated.
Cluster-admin as the default role: engineers and CI pipelines share broad rights, so one stolen token controls the cluster.

Lessons from incidents

The Tesla case and the Docker Hub research show the same weakness at two ends of the life cycle: a credential that should never have been inside a container. In one, a long-lived cloud key in a running pod turned an exposed console into cloud compute abuse; in the other, keys baked into images were published to a public registry and, in most cases, never revoked. Both are identity failures that image scanning alone would not fix. The maturity steps that address them are in the identity and build areas: workload identity instead of stored keys, secrets scanning before push, and revocation as part of response.

Practitioner checklist

Score each of the six areas separately and report the lowest alongside the average.
Collect API server audit logs and protect them from general access.
Adopt minimal, non-root base images with no shells in production.
Block deployments on agreed scan thresholds and scan images for secrets before push.
Enforce Pod Security Standards in every namespace after a warn and audit trial.
Deploy by digest or verify signatures at admission.
Apply default-deny network policies and filter metadata API access.
Give each workload its own service account, disable automounting where not needed and remove legacy token Secrets.
Replace cloud keys in pods with workload identity federation.
Rehearse a cluster compromise and revoke every credential the cluster held.

Container Security Maturity Model: Five Levels From Ad Hoc to Optimised