Container Runtime Security Standards

Running-container security standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies to the security of the container once it is already running: where the manifest no longer protects because the process exists, has a shared kernel underneath and an attacker inside. Covers the isolation model and its limits, the choice and pinning of the runtime, rootless and user namespaces, seccomp, container escape paths and their mitigation, runtime detection (eBPF, Falco, Tetragon, Tracee, KubeArmor), the drift of the immutable container, signature verification at execution time, container and node forensics, and the applicable benchmarks.

Triggers: seccomp, RuntimeDefault, seccomp.json, --security-opt seccomp=, SeccompDefault/--seccomp-default, runc, crun, runsc/gVisor, kata-runtime, containerd-shim-kata-v2, RuntimeClass, hostUsers, /etc/subuid, /etc/subgid, rootless Podman, --privileged, no-new-privileges, CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_DAC_READ_SEARCH, CAP_BPF, docker.sock, containerd.sock, crio.sock, hostPath, hostPID, hostNetwork, hostIPC, mounted /proc and /sys, cgroups v1/v2, falco, falco_rules.yaml, tetragon, TracingPolicy, tracee, kubearmor, bpftool, unprivileged_bpf_disabled, readOnlyRootFilesystem, criu, checkpointctl, the kubelet's /checkpoint/, kube-bench, docker-bench, "container escape", "the container has been modified at runtime".

Guiding principle: a container is a host process with namespaces and cgroups, not a virtual machine. It shares the kernel, and therefore shares the surface: every capability, every host mount and every unfiltered syscall is a direct path to the node. The whole of §3 derives from that fact. Operational corollary: what prevents the escape is the runtime configuration; what tells you it has happened is runtime detection. They are different controls and you need both.

Posture: this skill is defensive. It describes risk class, indicator and mitigation. It contains no payloads, exploitation chains or step-by-step recipes; authorised offensive work lives in offensive-security-standards.

Not applicable: see kubernetes-standards (a split already agreed on both sides: there admission, Kyverno/Gatekeeper policies, Pod Security Standards, securityContext as declarative Pod hardening, signing at admission and all image building; here what happens after the Pod starts: runtime, seccomp, escape, detection, drift and node forensics); selinux-standards (the container's MAC is theirs, without exception: container_t, container_file_t, MCS categories, container-selinux, :z/:Z, udica, seLinuxOptions, seLinuxChangePolicy and the authoring of AppArmor profiles. Here: seccomp —which belongs to this skill—, and detecting that the MAC has been disabled, bypassed or that a process has escaped despite it; if the problem is an AVC or a label, it belongs there); linux-hardening-standards (the node OS baseline: CIS/STIG, sysctl, auditd, SSH, mounts, measured boot — the hardened node is their boundary; here only the sysctls and capabilities specific to the runtime and why they matter); operating-systems-standards (the mechanism is theirs: what a namespace really is, what a cgroup isolates and what neither of the two isolates; here seccomp, the escape and its detection); onprem-standards (the platform umbrella: hardware, hypervisor, fleet, OOB plane); incident-response-forensics-standards (the full forensic process: phases, chain of custody, order of volatility, imaging, timeline, Velociraptor/Volatility — here only what container and node artifact exists, how long it lasts and how it is captured before it evaporates); incident-management-standards (incident governance: severity, IC, communication); detection-engineering-standards (a boundary decided and declared: which runtime signal matters and what should fire belongs to this skill —unexpected shell execution, writes to binaries, capability change, socket mount—; the rule's lifecycle —backlog, ATT&CK coverage, thresholds, tuning, false positive management, test framework and destination in the SIEM— is theirs. The Falco rule is born here and is governed there); observability-standards (collection, retention and correlation of the telemetry); vulnerability-management-standards (triage and SLA for the runtime CVEs cited here); cicd-standards (the pipeline that builds, signs and publishes); iac-standards (node provisioning); appsec-standards (the flaw in the application code that gives the initial RCE); cryptography-pki-standards (custody of signing keys); secrets-management-standards (custody and rotation of the secrets the container consumes); bcdr-standards (platform continuity and recovery); offensive-security-standards and ctf-lab-standards (offensive verification of the isolation and sample detonation, with scope and authorisation in writing; this skill is defensive); podman-systemd-containers-standards (Podman and Quadlet as a way of running services under systemd; here their security); linux-administration-standards and ha-clustering-standards; azure-standards/aws-standards/ gcp-standards (the managed node's runtime and its node image advisories); grc-compliance-standards (the required control and its evidence); webassembly-standards (the sandbox of a Wasm module and its imports are theirs; the isolation of the node that runs the Wasm host is still ours — a Wasm host is just another process, with its seccomp, its capabilities and its escape surface).

Cross note: windows-server-ad-standards shares with this skill the pattern of a platform whose compromise is total — a compromised node is compromised for all its containers just as a DC is for the whole domain. The layered containment criterion is analogous; the technical domain is not.

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8). This domain moves by escape CVE: a minimum version here expires overnight.

3. Isolation model, escape and detection

3.1 What a container shares with the host (and why that is everything)

• The kernel is shared: syscalls, page tables, drivers, the host's /proc and /sys. A kernel flaw is a flaw in all the node's containers at once.
• Namespaces (pid, net, mnt, uts, ipc, user, cgroup) give a separate view, not separate privilege — except the user namespace, which is the only one that really separates identity.
• cgroups limit resources, not access. A cgroup does not contain an attacker; it stops them from taking the node down by consumption. cgroups v2 is the requirement: v1 has a known escape surface (controller delegation and release_agent) that v2 does not reproduce, besides being the model that modern tooling assumes. A node on cgroups v1 in 2026 is a finding.
• What actually confines: seccomp (which syscalls exist), capabilities (what it can ask the kernel for), MAC (which objects it can touch) and user namespace (with which real identity). All four at once or the model is a lie.

3.2 Escape paths: risk class, indicator and mitigation

They are listed as surface to close and to watch, not as a procedure.

3.3 seccomp with judgement

• RuntimeDefault is the floor, not the goal. It blocks the group of syscalls that no legitimate workload uses (kexec_load, init_module, bpf without the capability, etc.) with a very low breakage rate. Verify it is actually enabled: the Kubernetes default without --seccomp-default is Unconfined, and that is the domain's most frequent silent failure.
• The default profile differs between runtimes (containerd vs CRI-O), between versions and between architectures. A profile tested on x86_64 is not tested on arm64.
• A bespoke profile: only for high-value workloads or ones exposed to untrusted input. It is generated from real observation (recording the workload's syscalls while it exercises its full path: start-up, traffic, log rotation, shutdown), not from a theoretical list.
• A denylist, not an allowlist, unless you can maintain it: a strict allowlist breaks with every update of the runtime, libc or the language itself. If you adopt it, take on the maintenance as part of the image's lifecycle.
• SCMP_ACT_LOG before SCMP_ACT_ERRNO: the new profile is deployed first in logging mode over real traffic, what it would have blocked is reviewed, and only then is it enforced. Skipping this phase is scheduling an outage.
• The profile is versioned code alongside the workload, with its test (§4). A profile that only exists on one node is drift.

3.4 Runtime detection

• eBPF is the technology, not the control. It gives visibility of syscalls and kernel events at low cost and with no modules. But loading eBPF programs is a near-root capability: CAP_BPF (plus CAP_PERFMON/CAP_NET_ADMIN depending on the program type) allows instrumenting the entire kernel. Hard rules:
  • kernel.unprivileged_bpf_disabled = 1 on all nodes, plus JIT hardening (net.core.bpf_jit_harden), verified by the node baseline (linux-hardening-standards).
  • An explicit inventory of who holds CAP_BPF/CAP_SYS_ADMIN: it is almost always an observability or security DaemonSet. Each one is a supply chain target of the highest value: a compromised agent can selectively silence its own alerts and keep looking healthy.
  • Loading a new eBPF program is itself a signal to detect. An eBPF rootkit filters the event stream your agent reads, which will faithfully report already manipulated data: that is why you need a second independent source (the node's auditd, runtime telemetry, control plane).
  • A recent CVE verified as a risk class: CVE-2026-64036 (OOB in the css_rstat_updated() path via a BPF kfunc, 7.8) — a repeated pattern of a kfunc/verifier bug reachable by whoever can already load programs.
• Signals that really matter (this skill decides what should fire; the rule's lifecycle belongs to detection-engineering-standards):
  • Execution of a shell or interpreter inside a container that does not have it as its entrypoint — the domain's highest value/noise ratio signal.
  • Writes to the container's binaries or system paths (/bin, /usr, /lib) and any write at all if the rootfs is read-only (impossible by design ⇒ a finding).
  • A change to the capability set or to no_new_privs of an already running process; unexpected use of setuid/setgid.
  • Access to masked /proc and /sys, to the runtime's /var/run/*.sock, or to the node's filesystem from a container.
  • An outbound connection to an unforeseen destination (C2, exfiltration, mining) and anomalous DNS resolution.
  • Execution of a binary that did not come in the image (drift, §3.5), downloading and executing in memory, curl|sh.
  • Reading credentials: the ServiceAccount token, /var/lib/kubelet, the provider's IMDS.
  • Disabling controls: MAC moved to permissive, an AppArmor unconfined profile, seccomp removed, the detection agent stopped.
• Before writing your own rules, exhaust the maintained ruleset. Falco ships community-reviewed rules; the real work is per-environment tuning, not creativity. Every rule of your own is born with its firing test (§4).
• Detection without response is decoration. Every high-confidence signal has a destination (observability-standards), an owner and an action — isolate the Pod, capture (§3.6), escalate. Without that, the agent only burns CPU.

3.5 Immutable container and drift

• The contract is: the image is the container. readOnlyRootFilesystem: true, writes only to declared volumes, zero package installation at runtime, zero operator exec in production outside break-glass.
• A container that is modified at runtime is a finding, not an operational anomaly: either it is a compromise, or it is a deployment practice that must be corrected. Both are investigated.
• The comparison declared image ↔ running process (an executed binary that is not in the layers, a new file in system paths) is a high-value, low-noise detection.
• kubectl exec/podman exec in production: logged, attributed to a person and alerted. It is at once a legitimate emergency tool and the most convenient technique for an attacker with control plane credentials.

3.6 Container and node forensics: the evidence evaporates by design

• The problem: the orchestrator reschedules or restarts the Pod, and with it go memory, processes, temporary files and the writable filesystem itself. In an incident, the platform's default behaviour destroys the evidence while it "recovers".
• Golden rule: on suspicion, capture before containing, and contain without deleting. Isolating the Pod's network and marking the node (cordon) preserves more than killing the Pod. The order of volatility and the chain of custody belong to incident-response-forensics-standards; what follows is what artifact exists in this domain and how long it lasts.
• Forensic checkpoint (CRIU): the kubelet's checkpoint API creates a stateful copy (memory, descriptors, sockets) without the container noticing, to analyse it in an isolated environment. Verified Aug 2026: alpha in v1.25, beta and enabled by default since v1.30; it is invoked with a POST to the kubelet (/checkpoint/<ns>/<pod>/<container>, access restricted to cluster administrators) and inspected with checkpointctl. The restore is deliberately not in the kubelet: it happens outside Kubernetes, in the container engine. A checkpoint contains secrets and personal data in memory: treat it with the same control as a RAM image.
• Artifacts that do survive and must be collected: runtime (containerd/CRI-O) and kubelet logs on the node, the host's journal and auditd, control plane and API server events, detection agent (eBPF) records, image layers and the real digest executed, mounts and persistent volumes, and a disk/memory image of the node if the compromise is a node compromise.
• If the compromise is of the node, the whole node is evidence and it is no longer trusted: it is isolated, preserved and rebuilt from a trusted source; it is not "cleaned". Every credential that passed through it (ServiceAccount tokens, IMDS credentials, mounted secrets) is considered compromised and rotated.
• Rehearse it. A capture procedure nobody has ever executed does not work on the day it is needed, because by then the Pod has been rescheduled three times.

3.7 Supply chain at execution time

• Admission validates what is requested; the node runs what is finally downloaded. Signature verification also in the engine (policy.json with sigstoreSigned in Podman/CRI-O) for critical workloads, and pin by digest everywhere: a tag is mutable by definition.
• Current precedent: the compromise of trivy-action/setup-trivy in March 2026 and the 2026 tag poisoning campaign (documented in offensive-security-standards) demonstrate that the security tool is a priority target — it runs in CI and on the nodes, with high privileges, by design. Every runtime agent is pinned by digest, its signature is verified and its advisory channel is followed as if it were part of the kernel.
• A private registry with pull-through; never a direct pull from public registries in production.

3.8 Node hardening: the boundary

The node belongs to linux-hardening-standards, and its baseline (CIS/STIG, sysctl, auditd, mounts, MAC enforcing) is a prerequisite, not a complement. On this side there remain only the invariants that exist because of the fact of running containers:

• cgroups v2, kernel ≥6.3 if user namespaces are used, MAC enforcing and active for containers.
• unprivileged_bpf_disabled=1 + JIT hardening; an inventory of CAP_BPF holders.
• The runtime socket with minimum permissions and never exposed over the network or mounted in containers.
• Nodes segmented by trust: hostile or multi-tenant workloads on their own node pool, with their reinforced RuntimeClass. Mixing hostile tenants with internal workloads on the same node nullifies any policy you write on top.
• A node image that is immutable and rebuildable, updated by replacement, not by live patching.

3.9 Applicable benchmarks

• CIS Kubernetes Benchmark v1.11.0, audited with kube-bench (cis-1.11 profile). Verified Aug 2026: that profile covers Kubernetes 1.29–1.32; for newer clusters it is still the practical reference, but the coverage is not official — state that when reporting. Never quote "the Kubernetes CIS" generically: CIS goes by product version.
• CIS Docker Benchmark, audited with docker-bench (which picks the set according to the daemon version). Declared gap (§8): the current version number was not confirmed in Aug 2026.
• NSA/CISA Kubernetes Hardening Guidance: verified Aug 2026, the current version is still 1.2, of 29 Aug 2022, with no later revision located. It is a guide of criteria (it explains the why and the attacker's view) and it complements CIS, which is about configuration. Use it as a design argument, not as an automatable checklist, and bear its age in mind: it does not cover user namespaces GA, cgroups v2 or the current generation of eBPF detection.
• The benchmark measures, it does not protect. A high score with a mounted docker.sock is still a compromise one step away.

4. Quality gates (they break the build or the deployment)

1. A seccomp profile tested, not assumed. Functional gate: the workload exercises its full path (start-up, real traffic, log rotation, shutdown, restart) with the profile active and without a single unexpected denied syscall. That the container starts proves nothing — the missing syscalls show up in the rare case, in production, at 3 a.m. A mandatory prior phase in logging mode (§3.3).
2. Runtime policy verified in CI and on the node. The pipeline fails on --privileged, a mounted runtime socket, a hostPath to a sensitive path, hostPID/hostNetwork/hostIPC, a vetoed capability, the absence of seccompProfile or readOnlyRootFilesystem: false without a signed exception. The same policy runs at admission (kubernetes-standards) and as a verification of the node's real state, because what was admitted is not always what runs.
3. A test that the detection fires — adversarial validation. A gate of its own and non-negotiable: in a test environment, benign actions equivalent to the watched techniques are executed (opening a shell in a container that does not have one, writing to /usr/bin, reading a masked /proc file, mounting a socket, initiating an unexpected outbound connection) and it is verified that the alert reaches its destination with the correct context. A rule that has never been seen to fire is not deployed, it is written. It is re-run after every update of the agent, the kernel or the runtime.
4. Runtime and kernel versions verified against the current advisory on every node in the inventory, as a deployment gate. A node with runc below the minimum of §2 does not accept workloads.
5. A forensic capture test rehearsed: a checkpoint of a test Pod, inspection with checkpointctl, and collection of the §3.6 artifacts with their time measured. It is rehearsed at least once every six months and after every runtime change.
6. An inventory of exceptions with an owner and an expiry: every privileged Pod, every added capability, every hostPath, every container with MAC disabled. Without an owner and without a date, the exception is withdrawn.
7. A benchmark run and trended (kube-bench, docker-bench): the value is in the time series and in the handling of the exceptions, not in the number.

5. Security: what this protects and what it does not

• What it gives you: it turns "RCE in the application" into "RCE inside an unprivileged process, with no dangerous syscalls, with no access to the node and with someone watching". It is containment plus detection; neither of the two alone is enough.
• What it does not give you: it does not fix the application's vulnerability (appsec-standards) or a kernel flaw. Against a kernel 0-day, the only real isolation is the one that does not share a kernel (Kata/microVM) or does not share a node.
• Hostile multi-tenant: if you run third-party code, namespace isolation is not sufficient by design. The correct posture is reinforced isolation + a dedicated node + detection, and treating the escape as a scenario, not as a hypothesis.
• The security agent is attack surface of the highest value: privileged, on all nodes, with kernel access. It is pinned by digest, signed, verified and its own health is watched — a downed or silenced agent is a high-severity alert, not an observability incident.
• Secrets at runtime: environment variables visible in /proc/<pid>/environ (and therefore to anyone with hostPID or CAP_SYS_PTRACE), ServiceAccount tokens mounted by default, IMDS credentials reachable from the Pod. Prefer a file over an environment variable, automountServiceAccountToken: false and blocking IMDS access from workloads. Custody and rotation: secrets-management-standards.
• Disabling a control "to make it work" is a risk decision, and it is taken as such: with an owner, a ticket, an expiry and compensation. Never on the fly and never as a silent default.

6. Performance and operability

• Realistic cost: seccomp RuntimeDefault and MAC are practically free. gVisor pays in syscall-intensive work and I/O; Kata pays in start-up and memory per Pod. Rootless pays ~25-30 % of start-up and fuse-overlayfs. None of those costs justifies running as root: measure them on your workload before dismissing them on rumour.
• Detection has a cost and noise: size the agent's CPU and event volume, and treat it as a platform workload with its own limits. An unbounded agent that saturates the node is an availability incident caused by security. Verified Aug 2026: Tracee consumes notably more than Falco or Tetragon in high-volume environments (2-4× versus Tetragon according to reports) and its default configuration generates an overwhelming event volume — it is deployed with filtering from day one, not afterwards.
• A written and tested runbook for: a suspect Pod (isolate, capture, escalate), a suspect node (cordon, preserve, rebuild), a downed agent, and a rollback of a seccomp profile that breaks production. Without a runbook, the 3 a.m. incident ends in --privileged.
• Rollback: every runtime hardening step (a new profile, a reinforced RuntimeClass, userns) is deployed in rings with its reversal tested.
• Kernel and runtime changes break profiles and agents: every node update re-runs gates 1, 3 and 4 of §4. It is the number one cause of detection that stops working in silence.

7. Sustainability and prohibitions

Cadence

• Runtime advisories (runc, crun, containerd, CRI-O, gVisor, Kata) actively tracked: it is the channel through which the escape arrives. Review at least monthly and immediate reaction to anything critical.
• Node kernel: top patching priority when the finding allows escape or MAC bypass.
• Falco/Tetragon/Tracee/KubeArmor: version and ruleset reviewed quarterly; the ruleset ages faster than the binary.
• Quarterly review of the exceptions inventory (§4.6) and of the inventory of holders of CAP_BPF/CAP_SYS_ADMIN.
• Scheduled rebuilding of the node image even if nothing changes.

FORBIDDEN (an automatic gate wherever possible)

• ❌ Mounting the runtime socket (docker.sock, containerd.sock, crio.sock) in a container. It is granting root on the node, under another name.
• ❌ --privileged / privileged: true without a signed, bounded, expiring exception and on a dedicated node.
• ❌ hostPath to sensitive paths on the node (/, /etc, /proc, /sys, /var/run, /var/lib/kubelet, block devices), and any writable hostPath without justification.
• ❌ hostPID, hostNetwork or hostIPC in application workloads.
• ❌ Running as root (UID 0) without written justification; and root with hostPath or added capabilities, never.
• ❌ CAP_SYS_MODULE, CAP_SYS_RAWIO; CAP_SYS_ADMIN, CAP_BPF, CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE outside approved infrastructure agents.
• ❌ Disabling seccomp or the MAC "to make it work" (seccompProfile: Unconfined, --security-opt seccomp=unconfined, label=disable, AppArmor unconfined). The correct path is a bespoke profile (seccomp, here) or a bounded policy (MAC, selinux-standards).
• ❌ procMount: Unmasked or mounting the host's /proc//sys.
• ❌ A container without runtime detection in a multi-tenant environment or one that runs untrusted code. Without detection there is no evidence that the isolation holds.
• ❌ Running untrusted code with a shared runtime (runc/crun) without a dedicated node.
• ❌ Nodes on cgroups v1, or with a runtime below the patched minimum version of §2.
• ❌ Modifying the container at runtime: installing packages, hot patching, operator exec as routine practice, a writable rootfs with no reason.
• ❌ An image by mutable tag or without signature verification on the path to production.
• ❌ Killing or restarting a suspect Pod before capturing evidence; deleting the compromised node "to recover" without preserving it.
• ❌ Re-enabling unprivileged_bpf_disabled=0 or handing out CAP_BPF without an inventory.
• ❌ A detection agent deployed without a firing test (§4.3), or with alerts without an owner or a destination.
• ❌ Pinning runtime versions, feature gate states or benchmark versions from memory, without the verification of §8.

Quick review checklist (a workload entering production)

• Runtime on a patched version; node on cgroups v2; kernel up to date and ≥6.3 if there is userns.
• Rootless or hostUsers: false where the node allows it; if not, a written reason.
• drop: ALL + a justified allowlist; allowPrivilegeEscalation: false; not root or a signed exception.
• An explicit seccompProfile and verified active on the node; a bespoke profile tested if applicable.
• MAC active and enforcing for the container (policy: selinux-standards).
• No runtime socket, no sensitive hostPath, no hostPID/hostNetwork/hostIPC, no privileged.
• readOnlyRootFilesystem: true + declared volumes; drift detection active.
• Image by digest and signature verified; runtime agent pinned by digest and signed.
• Runtime detection deployed, with a passed firing test and alerts with an owner.
• Reinforced isolation (RuntimeClass) if the workload is untrusted or hostile multi-tenant.
• A forensic capture procedure rehearsed and accessible in the runbook.

8. Mandatory web verification

Before pinning any version, feature state or benchmark number, look it up — do not remember it:

1. Runtime escape CVEs: it is the datum that expires fastest in the whole document. Verified Aug 2026: the runc triad of Nov 2025 (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) is still the most recent significant set; patched in runc 1.2.8 / 1.3.3 / 1.4.0-rc.3+ and containerd 1.6.39+ / 1.7.28-2+. Declared gaps: the exact stable version of runc, crun, containerd and CRI-O was not verified in Aug 2026, nor could the isolated report of active exploitation in Jun 2026 be confirmed (one source asserts it, the rest do not) — treat it as unconfirmed and consult the upstream advisory.
2. The state of user namespaces in Kubernetes (verified Aug 2026: GA in v1.36, Apr 2026; beta enabled by default since 1.33; requires kernel ≥6.3, which many managed nodes still do not have). Check your cluster version and the node's uname -r: this changes per release.
3. SeccompDefault: verified Aug 2026 that it is still a kubelet feature gate + the --seccomp-default flag, with no cluster default. Declared gap: it was not confirmed whether it has graduated to GA or whether there is a date to make it the default; consult KEP-2413 and your version's seccomp reference.
4. Forensic checkpoint: verified Aug 2026 beta and enabled by default since v1.30. Declared gap: its state in v1.36 could not be confirmed (still beta, already GA?). Read it in your version's release notes before basing an incident procedure on it.
5. The state of the detection tools: verified Aug 2026 — Falco graduated in CNCF (29 Feb 2024), v0.44.1 (Jun 2026), with the legacy eBPF probe, gVisor and gRPC documentation withdrawn in May 2026; Tetragon active as a Cilium subproject in CNCF; Tracee active (Aqua) with a notably higher cost; KubeArmor in CNCF Sandbox. Declared gaps: the current versions of Tetragon, Tracee and KubeArmor were not verified, nor were hard maintenance health signals (commit cadence, number of maintainers, CNCF level changes in 2026). Check it in their repos and in the CNCF landscape before betting a platform on it.
6. Reinforced isolation versions: verified Aug 2026 Kata Containers 4.0.0 (20 Jul 2026), with a guest kernel bump for CVE-2026-31431. Declared gap: the current version of gVisor was not verified (it publishes very frequent releases) nor that of crun.
7. Benchmarks: verified Aug 2026 — CIS Kubernetes Benchmark v1.11.0 (kube-bench profile cis-1.11, official coverage K8s 1.29-1.32) and NSA/CISA Kubernetes Hardening Guidance v1.2 of 29 Aug 2022 as the current version, with no later revision found. Declared gaps: the current version of the CIS Docker Benchmark could not be confirmed (look it up at cisecurity.org/benchmark/docker, which only lists the supported ones), and it was not checked whether a CIS Kubernetes Benchmark later than v1.11.0 already exists.
8. eBPF hardening and its CVEs: verified Aug 2026 CVE-2026-64036 (OOB via the css_rstat_updated() kfunc, 7.8 CVSS v3.1 according to kernel.org). Check your distro's tracker for the patch state and look for later verifier/kfunc CVEs before considering a kernel version safe.
9. Supply chain compromises in security tools: a verified precedent from the catalogue — trivy-action/setup-trivy, March 2026. Before introducing any new agent or scanner, look for recent incidents of the project: in this domain the tool runs privileged on every node.
10. Managed node provider advisories (EKS/AKS/GKE) for the node image version you are running: the runtime patch arrives through there, not through your pipeline.

If the web contradicts this document, the web wins — flag the discrepancy.