Posture, policy-as-code & continuous compliance
Every lesson so far hardens one thing — an identity, a secret, a network, an image. This final lesson is about doing all of it continuously and automatically, across everything you run. Two failures define immature cloud security: misconfigurations are found late (a quarterly audit, or after a breach), and they're prevented by hope (a wiki page nobody reads). The mature answer is two-sided: detect drift continuously (posture management) and prevent bad config from ever shipping (policy-as-code). And because static checks can't see a live attacker, we add the layer most teams skip entirely — runtime threat detection. This is how security scales from one careful engineer to a whole organization.
On-ramp in one breath: continuously scan everything for misconfiguration (posture), automatically block insecure setups before they ship (policy-as-code), watch running workloads for active attacks (runtime), and produce compliance evidence on demand instead of scrambling once a quarter.
Detect: Cloud Security Posture Management (CSPM)
You now know the recurring failure modes (8.1): public buckets, over-permissive IAM, public databases, unencrypted storage. CSPM — Cloud Security Posture Management — is tooling that continuously scans your entire cloud for exactly these misconfigurations and flags them. Think of it as an always-on inspector walking every resource and asking, "Is this public when it shouldn't be? Over-permissioned? Unencrypted? Drifted from policy?"
CSPM is detective — it tells you what's already wrong. That's essential (you can't fix what you can't see), but it's reactive: the misconfiguration already exists in production by the time CSPM reports it. Which is why detection alone isn't enough.
Prevent: policy-as-code and admission control
The stronger move is to prevent the misconfiguration from ever reaching production. Policy-as-code means writing your security rules as executable code that the pipeline and platform enforce automatically — not as prose in a wiki. The rule "no storage bucket may be public" becomes a check that fails the build (via the IaC scanning of 8.6) and an admission rule that rejects a non-compliant resource at deploy time.
In Kubernetes this enforcement point is the admission controller (the same gate that verified image signatures in 8.6). Two standard policy-as-code engines:
- OPA / Gatekeeper — Open Policy Agent, a general policy engine, with Gatekeeper integrating it into Kubernetes admission. Policies are written in a dedicated policy language.
- Kyverno — a Kubernetes-native policy engine where policies are written as ordinary Kubernetes YAML (gentler learning curve).
Trace it with a concrete rule — "every pod must run as non-root and use a signed image": a developer applies a pod that runs as root. The admission controller evaluates the policy, finds a violation, and rejects the pod outright — it never runs. The misconfiguration was stopped at the gate, not found later by CSPM. This is the durable upgrade: policy-as-code turns "please remember to" into "the system won't let you." It's also exactly the golden-path idea from Chapter 7 — the secure way is the only way the platform allows, so doing the right thing is automatic.
:::tip Detect and prevent — you need both
- CSPM (detect): continuous scanning that catches what's already misconfigured, including drift in resources that predate your policies.
- Policy-as-code (prevent): admission control + IaC checks that reject non-compliant config before it ships. Prevention stops new mistakes; detection catches drift and the long tail of pre-existing ones. The principle is durable; OPA/Gatekeeper, Kyverno, and the CSPM vendors are the dated layer. :::
The runtime layer: catching the live attacker
Here's the gap nearly every guide leaves open. CSPM and scanning are static — they inspect configuration and artifacts at rest. Neither can see a live attacker doing something at runtime: a process spawning a shell inside a container, an unexpected outbound connection, a privilege escalation in progress. For that you need runtime threat detection — watching the behavior of running workloads and alerting on the anomalous.
Modern runtime tools use eBPF — a Linux kernel technology that lets tools observe system calls and network activity with deep visibility and low overhead, without modifying the kernel. The durable categories of tool (dated specifics, as always):
- Falco — open-source runtime detection: alerts on suspicious syscalls ("a shell was spawned in a container that should never spawn one").
- Tetragon / Cilium — eBPF-based runtime observability and enforcement.
- KubeArmor, and commercial agents like SentinelOne — runtime protection for workloads.
The point: static posture tells you the door is unlocked; runtime detection tells you someone just walked through it. A complete program needs both — and "only doing static scanning, no runtime detection" is one of the most common real-world gaps.
CNAPP and CIEM: the consolidation
You've now met several overlapping tools — CSPM (posture), image/workload scanning, CIEM (entitlements, 8.2), runtime detection. Buying and wiring these separately is painful, so the industry consolidated them into one platform category: CNAPP — Cloud-Native Application Protection Platform — which bundles:
- CSPM — posture / misconfiguration,
- CWPP — Cloud Workload Protection (the workloads/containers themselves, incl. runtime),
- CIEM — entitlement management (over-permissioned identities, from 8.2),
- often plus IaC and supply-chain scanning.
The durable insight is why CNAPP exists: real attacks chain across layers — a public workload (CSPM) running as root (CWPP) with an over-permissioned role (CIEM) is far more dangerous than any one of those alone. A unified platform sees the combined risk path that siloed tools miss. Examples of CNAPP-class products: Wiz, Prisma Cloud, Microsoft Defender for Cloud. (Tools are dated; the consolidation and the cross-layer risk insight are durable.)
Continuous compliance: evidence, not snapshots
The old way to "be compliant" (with a standard like SOC 2, ISO 27001, etc.) was a quarterly snapshot: an auditor checks once, you pass, and the next nine months drift unobserved. Compliance-as-code / continuous compliance flips it: each control becomes an automated, continuously-evaluated check, and the system continuously produces evidence ("every database has been encrypted at all times this quarter, here's the log"). Benefits:
- Drift detection — the moment a resource falls out of compliance, you know, instead of discovering it at the next audit.
- Evidence on demand — audits become "export the report," not a fire drill.
- Same engine as security — the very same policy-as-code rules that enforce security also prove compliance, because a passing policy is the evidence.
Compliance stops being a periodic event and becomes a continuous property of the system — the same shift from snapshot-to-continuous that runs through this whole chapter.
Why it matters
Security scales only when it's continuous and automatic. Detect misconfiguration continuously with CSPM; prevent it with policy-as-code (OPA/Gatekeeper, Kyverno) that rejects insecure config at admission — turning "please remember to" into "the system won't let you," the golden path of Chapter 7. Add the layer most teams skip — runtime threat detection (Falco, eBPF tools like Tetragon/Cilium) — because static checks can't see a live attacker. Recognize the CNAPP consolidation (CSPM + CWPP + CIEM + supply-chain) and why it exists: real attacks chain across layers. And treat compliance as continuous evidence, not a quarterly snapshot, using the same policy engine to both enforce and prove. This is how one engineer's careful habits become an organization's default.
Common pitfalls
- Detection without prevention. CSPM tells you what's already wrong — reactively. Add policy-as-code so new misconfigurations can't ship at all.
- Policy as a wiki page. Prose nobody enforces is hope, not control. Make it executable: failing builds and rejecting admissions.
- Only static scanning, no runtime. Posture and image scans are blind to a live attacker. Add runtime threat detection (Falco/eBPF) — this is the most common missing layer.
- Tool sprawl with no correlation. Siloed tools miss the chained risk path (public + root + over-permissioned). CNAPP exists to see the combined risk.
- Compliance as a quarterly snapshot. It drifts the other 89 days. Make controls continuous checks that emit evidence automatically.
Where this connects
- Back to 8.1 — CSPM hunts exactly the misconfiguration failure modes named there.
- Back to 8.2 — CIEM is the entitlement pillar of CNAPP, finding over-permissioned roles.
- Back to 8.6 — admission control here is the same gate that verifies image signatures.
- Back to Chapter 7 · Platform Engineering — policy-as-code is how the golden path makes secure the default; security scales via paved roads, not gatekeeping.
- Forward to 8.8 Checkpoint — lock in the whole chapter.