Container Security: Image Scanning, Non-Root Execution, and Pod Security Standards

Last updated on September 19th, 2026 at 07:36 am

Most teams approach container security as a checklist. Once the image is scanned, check the box and move on to the next. However, if you’ve worked on a real Kubernetes cluster, you will quickly see the posture of the base image you installed 3 months ago fade away when a new CVE drops.

This isn’t a beginner’s overview. For most of the RAM and disk space, it’s an in-depth look at the state of container security today in the three key areas: image scanning, non-root execution, and Pod Security Standards, and, most importantly, where each of these is going.

The State of Container Image Scanning – Solid Foundation, Shifting Expectations

Teams have had plenty of time to develop image scanning, and most have something in place. Useful tools such as Trivy, Clair, Anchore, and Harbor are well established, well published, and fit seamlessly into CI/CD pipelines.

The conventional approach is as follows:

• Scan at build time to prevent issues from being committed.
• Scan on push to the registry to prevent non-conforming images.
• Do repeated scans within the registry – new CVEs are discovered after deployment.

This is where many teams fail: the last point. In my experience, most pipelines gate on the build-time scan and don’t modify registry images for months. This is not a safe position; it’s a false sense of safety.

What Scanners Actually Catch (and What They Miss)

Scanners effectively detect known packages and libraries in OS packages that contain CVEs. They can highlight obsolete base images, misconfigured layers, policy violations (such as exposed ports or running as root), and much more, including things taken into the Dockerfile.

Instead, they do not catch them:

• Runtime exploits- take from behavior, not static code.
• A misconfigured RBAC and/or weak admission control
• Vulnerabilities in YOUR application code (not typing them on the command line!)

This is explained in the OWASP DevSecOps guideline (Container Vulnerability Scanning): scan results have no value unless combined with an actual DevSecOps remediation workflow. Without triage, prioritization, and a fix cycle, it’s just generating reports no one acts on.

The Shift Toward Supply-Chain-Aware Scanning

It’s a place where everything is actually changing. Pure CVE scanning is transitioning to full supply-chain security, where software Bills of Materials (SBOMs) and image signing using tools such as Cosign are becoming part of the CVE scanning process.

The most common pattern in real-world production spaces:

• No image types can run without signature and verification (only signed and verified images) (at admission)
• All images used must come from approved internal registries.
• The results of those scans are compared with runtime information obtained through telemetry to provide real-world relevance, rather than prioritizing CVSS scores.

This is not just theory – admission tools such as Kyverno and OPA Gatekeeper are now able to do admission enforcement, and teams are deploying them. For anyone working with Kubernetes security at any level, the admission layer is a must.

Non-Root Execution – Still Ignored More Than It Should Be

People know they shouldn’t do several things but still do, such as running containers as root often because it’s easier. The base image runs as root; the app needs certain file paths; and no one wants to debug permission issues, etc. As a result, many teams lack securityContext settings.

This is a problem I see over and over in internal audits, not because engineers don’t know better, but because it’s the way it is, and there’s nothing to force them off their feet.
How Non-Root Enforcement Actually Works is a book by Don’t Root.

How Non-Root Enforcement Actually Works

At the Dockerfile level, these steps create an unprivileged user and switch to it:

RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuserUSER appuser

At the Kubernetes level, you enforce it through securityContext:

securityContext:  runAsNonRoot: true  runAsUser: 1000  runAsGroup: 3000  allowPrivilegeEscalation: false  readOnlyRootFilesystem: true  capabilities:    drop:      - ALL

The focus is on the capabilities. The drop: ALL line is more important than many people realize. Linux capabilities are finely grained privileges, such as “NET_BIND_SERVICE”, “SYS_ADMIN”, or “CHOWN”. The key point is that once you drop capabilities by default and add them back only when the workload truly needs them, you’re applying real least-privilege logic.

Almost all guides will say more about dropping than about anything else. Because of my experience in real life, my workloads were few, typically one to two capabilities, and most never used any capabilities. This is a tedious audit but worthwhile on a per-service basis.

What “Cluster-Wide Enforcement” Looks Like in Practice

Thinking around non-root isn’t only “the way to deploy to make one’s configuration.” Making it a hard requirement at the namespace level so that teams cannot avoid it if they don’t want to explicitly.

This is where Pod Security Standards fit in – interrelated with the next section. But the cultural shift matters too: use non-root templates for new workloads, rather than something a security team will chase down after the fact.

If you’re wondering how this relates to network-level controls, you might want to read about Network Policies, which are covered in the Kubernetes Network Security documentation and add a separate layer on top of workload hardening while still complementing it effectively.

Container Security and Pod Security Standards – The Enforcement Layer That Actually Has Teeth

Pod Security Standards is a more powerful alternative, replacing the old PodSecurityPolicy (PSP), which was difficult to make work properly. As of Kubernetes 1.25, Kubernetes has completely removed PSP. PSS offers you 3 profiles:

Labeling Namespaces and Understanding Enforcement Modes

Labels are used within PSS to create its namespaces:

labels:  pod-security.kubernetes.io/enforce: restricted  pod-security.kubernetes.io/audit: restricted  pod-security.kubernetes.io/warn: restricted

There are 3 modes: Enforce (drops non-compliant pods), Audit (logs violations and does not drop pods), and Warn (displays warnings to the user). Enablement starts with audit in production, then moves to enforce when workloads are updated.

Restricted Profile requires:

• Non-root user execution
• No privilege escalation
• Dropping all of, and a few being added to the capabilities (note the additions are for specific purposes only)
• It is highly recommended to use a read-only root filesystem. Use of a read-only root filesystem is encouraged.
• Seeking a host path volume failed to return any host path volumes for sensitive paths.
• No privileged containers

My testing on a cluster of dedicated test site machines with mixed workloads shows that about 30-40% of deployments fail the ‘restricted’ profile on the initial pass; most require either a runAsNonRoot attribute or a NET_BIND_SERVICE attribute for services that bind to port 80. Both are answerable, but both call for intentional adjustment(s).

PSS + Policy Engines – Why You Need Both

You will find a good baseline in the PSS, but it doesn’t go as deep as you’d like. Not possible to impose “images must be drawn from our internal registry” using PSS. Namespace labels do not enforce resource limits, required labels, or runtime classes.

This is where Kyverno and OPA Gatekeeper can help. These policy engines enable custom admission rules in code, and increasingly use their policing to shape the admission process for their operations—hence, GiOs.

The material inside a layered stack has the following form:

• Enforcement of the workload hardening profile at the namespace level by PSS
• Kyverno/Gatekeeper – custom rules for registry trust, resource quotas, labels, naming conventions
• Use Image scanning to scan images through CI/CD gates and the registry continuously. Leverage image scanning to scan images through CI/CD gates and the registry continuously.
• Monitoring at runtime – Falco, various tools that look for things that are abnormal after things go online.

Lack of Cluster-Level Policy Enforcement (K04) is a common concern in real-world Kubernetes clusters, as highlighted by OWASP’s Kubernetes Top Ten. Integrating PSS with a policy engine directly fills that gap.

This also relates to broader (cluster) design principles. The 4Cs of Kubernetes Security – Cloud, Cluster, Container, Code is worth reading in full, as it is a good model for understanding each element’s place in the overall stack.

My Take on the Gaps Most Teams Still Have

It’s easy to “talk the talk” on this. The gaps in practice are more specific.

Gap #1: Leaping without a remediation process. Teams look at images, notice only 200 medium-severity CVEs, have no idea which are actually a risk in their environment, and effectively ignore the results. The problem area for scanning programs is not just prioritizing by CVSS, but by prioritizing by exploitability.

Gap 2: Non-root set at pod level but not at container level. For Kubernetes: runAsNonRoot can be explicitly defined in the pod spec, but each container can override it. A container may run as root even if it isn’t configured to, if you don’t also set it to run as non-root.

Gap 3: PSS was set with a baseline in production because of the “breaking things” restriction. This is the most prevalent one. While a baseline is good, it is not mandatory; it simply prevents known paths for privilege escalation. A baseline is a good starting point, but it’s not the end of the road for workload hardening.

Gap 4: Lack of a strategy for secrets. Even hardened workloads can be breached if secrets aren’t properly managed. As you build a complete security posture, Secrets Management in Kubernetes should be a logical next step after image scanning and PSS.

A Practical Three-Phase Rollout

A sensible starting framework for teams based on inconsistent or mixed baselines is:

Phase 1 is about getting the basics right. Phase 1 is about getting this all settled.

• Fail builds on critical/high CVEs; Deploy Trivy in CI.
• Enable the default securityContext that will be assigned to new workloads (non-root, drop ALL capabilities, read-only root filesystem)
• Enable some level of enforcement in all namespaces, and audit for restricted.

In Phase 2, harden and automate. In Phase 2, harden and automate.

• Move production namespaces into a restricted phase. Move production namespaces into a restricted phase.
• Install Kyverno policies to enforce trusted registries and disallow privileged containers.
• Enlist “Registry Scanning” to continuously monitor images after deployment.

Phase 3 follows Phases 1 and 2, tying in compliance and monitoring.

• Map PSS to CIS Benchmark controls and NIST guidance.
• Add runtime monitoring (Falco or another) to detect what static controls cannot.
• Implement a feedback loop: “input” should be CVEs found to address first at runtime.

Find two external references from books you can trust to strengthen your points.
If you want to explore this subject further and would like to read more authoritative and in-depth articles, then the two resources below are worth your while:

• OWASP Kubernetes Top Ten
• Kubernetes Official Pod Security Standards Documentation

Wrapping Up

Container Security using Image Scanning, Non-Root Execution, and Pod Security Standards isn’t simply a problem to be solved; it’s three different layers, each with its own maturity curve.

Image scanning has become a fundamental element today, and it will continue to develop into supply-chain consciousness. We understand non-root execution well, but its use is inconsistent. Pod Security Standards work best with policy engines and rollout plans for existing workload configurations, giving you the power to enforce them.

It isn’t always the teams with the most tools who are right. They have clear defaults enforced at the platform level, and a remediation process that actually gets executed. From there, work outwards.

Pranay Sai Aduvala

I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!