Cloud-Native Runtime Security — eBPF & CNAPP

In one line: CSPM finds misconfigurations before an attack; this lesson is the other half — catching the attack while it runs, using eBPF to observe (and even block) suspicious behavior inside the Linux kernel, because modern intruders "live off the land" with normal admin tools that signatures don't flag — and CNAPP is the platform consolidating CSPM, this runtime protection, and identity into one place.

In plain English

CSPM is preventive: it scans your cloud for insecure settings before anything bad happens. But assume something bad does happen — an attacker gets a foothold in a running container. How do you catch them in the act? The old answer was signatures: a database of "known-bad" file hashes and patterns, like an antivirus. The problem is that today's serious attackers don't bring obvious malware files. They "live off the land" — they use the legitimate tools already on the system (the shell, curl, built-in admin commands) to do their dirty work, so there's no known-bad file to match. Signatures see normal tools and shrug. The fix is to watch behavior instead: not "is this a known-bad file?" but "is a web server suddenly spawning a shell and reading /etc/shadow? That's abnormal, flag it." To watch behavior cheaply and unavoidably, modern tools use eBPF — a way to run tiny safe programs inside the Linux kernel that see every process, file open, and network connection as it happens. Two tools lead here: Falco (detect and alert) and Cilium Tetragon (detect and enforce — it can kill the bad process in-kernel before it finishes). Finally, CNAPP is the umbrella platform that bundles this runtime protection together with CSPM and identity, because buying each piece separately stopped making sense.

Why signatures fail: living off the land

A signature-based detector matches activity against a list of known-bad indicators — a malware file's hash, a specific exploit string. It's fast and precise when the threat is a known file. Its fatal weakness: it only catches what's already on the list, and serious intruders make sure they're not.

The dominant evasion is living off the land (LOTL): instead of dropping a recognizable malware binary, the attacker abuses the legitimate software already present — the shell, scripting interpreters, package managers, built-in OS administration tools, cloud CLIs. Nothing they run is "known-bad," because every tool they use is a normal, trusted part of the system. A signature scanner sees bash, curl, and a standard admin command and finds nothing to flag — even as those exact tools are being chained into an intrusion. (State-grade intrusions documented in recent years leaned heavily on this technique precisely to slip past file-based detection.)

The answer is to detect on behavior, not identity-of-the-file: it doesn't matter that bash is legitimate; what matters is that a web-server process just spawned a shell, which read a credentials file, then opened an outbound connection to an unknown host — a sequence that's deeply abnormal for a web server, regardless of which "trusted" tools performed it. This is the baseline-and-anomaly idea from detection engineering, brought down to the level of individual system calls.

Terms, defined once

• Runtime security — detecting (and stopping) malicious activity in running workloads, as opposed to scanning configs or code beforehand.
• Signature-based detection — matching activity against a list of known-bad indicators (file hashes, exploit strings); blind to anything not already on the list.
• Behavioral / anomaly detection — flagging activity that deviates from normal behavior (a web server spawning a shell), regardless of whether a known-bad file is involved.
• Living off the land (LOTL) — attacking using the legitimate tools already on a system (shell, admin utilities, CLIs) so there's no malware file to match, defeating signatures.
• eBPF (extended Berkeley Packet Filter) — a Linux feature that safely runs small, sandboxed programs inside the kernel, observing syscalls, file, and network events with low overhead and no kernel modules.
• Syscall (system call) — a process's request to the kernel to do something (open a file, start a process, send on the network); the ground truth of what software is actually doing.
• Falco — an open-source (CNCF) eBPF runtime-security tool that detects and alerts on suspicious behavior via rules.
• Tetragon — Cilium's eBPF runtime-security tool that detects and can enforce in-kernel (e.g., kill a process or drop a connection before the syscall completes).
• CNAPP (Cloud-Native Application Protection Platform) — a consolidated platform bundling cloud-security tools (CSPM, workload/runtime protection, identity entitlements, Kubernetes posture) into one.

eBPF: watching from inside the kernel

To detect on behavior, you need to see everything a workload actually does — every process it starts, file it opens, connection it makes — reliably and cheaply. That ground truth lives in system calls, and the place to observe them without being evaded is the Linux kernel itself.

eBPF is the modern way to get there. It lets you load small, verified-safe programs into the running kernel that fire on kernel events (a process executing, a file opening, a packet flowing) and report what happened — without writing a risky kernel module and without the overhead of shuttling every event up to userspace for inspection. Because the observation happens in the kernel, below the application, a process can't simply hide its syscalls from it the way it might evade a userspace agent.

That vantage point is exactly what behavioral detection needs:

• It sees the full chain — this process spawned that one, which read this file, which then connected out — with the container and pod metadata attached, so an event isn't just "a shell ran" but "a shell ran inside the payments pod."
• It's low-overhead enough to run in production, so you're not forced to sample or to inspect only a copy of traffic.
• It's hard to evade, because it watches the syscall layer every process must use, not a log the attacker could tamper with.

Falco vs. Tetragon: detect, and enforce

Two open-source eBPF tools dominate cloud-native runtime security, and the useful distinction between them is detect versus enforce:

• Falco (a graduated CNCF project) is the runtime detection engine. You write (or adopt) rules describing abnormal behavior — "a shell was spawned in a container," "a sensitive file was read by an unexpected process," "an outbound connection to a non-allowlisted host" — and Falco alerts when the kernel events match. It's the detection-engineering discipline applied to syscalls: codify what's abnormal, fire on it, feed the alert to your SOC.
• Tetragon (from the Cilium project) goes a step further: because its logic runs inside eBPF in the kernel, it can not only detect but enforce in-kernel — kill the offending process or drop the connection before the syscall completes. Detection tells you the web server spawned a shell; enforcement stops the shell from running at all.

Worked example: catching a living-off-the-land intrusion

An attacker exploits a vulnerability in a web service running in a container. They don't upload any malware — they live off the land: they use the container's own shell and built-in tools to read a mounted credentials file and then curl it out to a server they control.

Signature antivirus: sees bash and curl — both legitimate, both on no known-bad list. Nothing fires. The credentials walk out the door.

eBPF behavioral detection (Falco): the kernel reports the syscall chain — the web-server process exec'd a shell (abnormal for a web server) → the shell read /etc/shadow-class secrets → an outbound connection opened to an unknown host. Each step matches a "this shouldn't happen in this workload" rule. Falco alerts in real time; the SOC sees the intrusion as it unfolds, with the pod and process context attached.

eBPF enforcement (Tetragon): the same behavioral rule, but instead of only alerting, the in-kernel program kills the spawned shell before it can read the file — the intrusion is stopped at the first abnormal action, not merely recorded.

The decisive point: the attacker used only trusted tools, so the file-identity question ("is this known-bad?") was useless. The behavioral question ("is this sequence normal for this workload?") caught it — and eBPF is what made watching that sequence in production cheap and evasion-resistant.

CNAPP: the consolidation

For a decade, teams bought cloud-security capabilities as separate products with separate four-letter names: CSPM for misconfigurations, CWPP (Cloud Workload Protection Platform) for the runtime protection this lesson covers, CIEM (Cloud Infrastructure Entitlement Management) for over-broad identities and permissions, KSPM (Kubernetes Security Posture Management) for cluster configuration. The result was a pile of disconnected tools that each saw one slice and couldn't correlate across slices.

CNAPP (Cloud-Native Application Protection Platform) is the consolidation of those into a single platform. Its real value isn't bundling for its own sake — it's correlation across the slices: a CNAPP can connect "this workload has a critical vulnerability" (CWPP) + "it's reachable from the internet" (CSPM) + "it runs with an over-permissive role" (CIEM) + "and right now it's behaving abnormally" (runtime) into one prioritized "this is the path an attacker will actually take" — instead of four separate dashboards no human can join by hand. That correlated, attacker's-eye prioritization is the same risk-based triage CSPM taught for findings, now spanning posture, workload, identity, and runtime together.

The dated specifics — verify current before relying on them

As of this writing (mid-2026): Falco and eBPF itself are graduated CNCF projects; Tetragon is the Cilium project's eBPF runtime-security and enforcement component (Cilium is also CNCF-graduated). The CNAPP category was named by Gartner (around 2021) and now describes the convergence of CSPM + CWPP + CIEM + KSPM into one platform, with industry coverage reporting most enterprises consolidating cloud security toward a handful of vendors. The state-sponsored intrusions most cited for living-off-the-land tradecraft (e.g., the Volt Typhoon campaigns against critical infrastructure) are illustrations, not durable facts. Tool names, project statuses, vendor counts, and threat-actor labels will change — treat them as a snapshot, verify current, and rely on the durable parts: signatures miss living-off-the-land, behavioral in-kernel detection catches it, and CNAPP consolidates the cloud-security stack.

Why it matters

• It catches what prevention misses. CSPM and hardening reduce the attack surface, but determined attackers still get in. Runtime detection is the layer that sees the intrusion as it happens — defense in depth, with a layer that assumes prevention failed.
• It's the only thing that catches living-off-the-land. Modern intruders deliberately use trusted tools to defeat signatures. Behavioral, syscall-level detection is the answer to an attack with no malware file to match — and it's increasingly how real breaches are found.
• eBPF made it practical. Watching every syscall in production used to be too costly or too evadable. In-kernel eBPF made low-overhead, hard-to-evade runtime visibility realistic — which is why this approach became the cloud-native standard.

Common pitfalls

Where people commonly trip up

• Relying on signatures alone in the cloud. Living-off-the-land attacks use legitimate tools and match no known-bad list. Add behavioral, syscall-level detection.
• Treating prevention (CSPM) as sufficient. Posture management reduces the attack surface but won't catch an intruder already inside. Pair it with runtime detection — assume prevention can fail.
• Detection with no response path. A Falco alert nobody triages is noise. Route runtime alerts into the SOC and IR workflow; where appropriate, use in-kernel enforcement (Tetragon) to block, not just alert.
• Unbounded enforcement. Killing processes in-kernel can take down legitimate workloads if rules are too broad. Tune behavioral rules to the workload's real baseline before enforcing, exactly like detection tuning.
• Buying disconnected point tools. Separate CSPM, CWPP, CIEM, and KSPM dashboards can't correlate an attack path. A CNAPP's value is joining posture + workload + identity + runtime into one prioritized view.
• Forgetting the kernel vantage point matters. A userspace-only agent can be evaded or starved of context. eBPF observes at the syscall layer every process must use — that's why it's hard to evade.

Page checkpoint

Required checkpoint

Did runtime security click?

Pass to unlock the Next button below

What's next

→ Continue to Kubernetes Security — the controls that keep the platform itself safe: admission control (Pod Security Admission, Kyverno/OPA), image provenance and signing, secrets handling, and network policies.

→ Going deeper: the preventive sibling is CSPM; the behavioral-baseline discipline is detection engineering; alerts route into the SOC; the layered "assume prevention failed" logic is defense in depth.