eBPF compliance: what a security reviewer will ask, and how to answer

Your platform team wants eBPF telemetry because it deploys once per node and instruments nothing. Your security team knows eBPF as the technology behind Cilium network policy and Falco runtime detection, and they will ask hard questions about a kernel-level collector: what it can read, what privileges it needs, how it is constrained, and where the data goes. This page answers those questions with control identifiers, kernel version numbers, and CVE references. You can forward it to the reviewer directly.

What is eBPF compliance in cloud native environments

eBPF lets sandboxed programs run inside the Linux kernel in response to events such as system calls, network connections, file operations, and process execution, without kernel modules or code changes to applications. Security teams usually meet it as an enforcement tool. In observability, the same mechanism works as a scoped telemetry collector: programs attach to kernel hook points, copy event data into maps, and stream it to a user-space agent for storage.

eBPF compliance covers two questions a reviewer has to answer. First, does kernel-level telemetry produce evidence that satisfies audit requirements under SOC 2, HIPAA, PCI DSS, and NIST 800-53? Second, can the collector itself pass review, given that it runs in kernel space with elevated capabilities? The distinction between kernel-space and user-space collection drives both answers: a kernel-space collector sees every process and connection on the node regardless of language or instrumentation, and it captures events before any user-space process can filter or suppress them.

A third question sits underneath both and is usually the one that decides the review: where does the collected data end up. A kernel-level collector sees more than any SDK, so the deployment model is not a footnote to the security argument. It is the security argument. That question is answered in the BYOC section below.

How eBPF works at the kernel level

Kernel-level review turns on four points: collection scope, verifier safety, hook selection, and runtime overhead.

Kernel-space collection vs user-space agents

User-space agents collect what applications hand them. Datadog’s primary APM instrumentation is a per-language SDK, and Dynatrace’s OneAgent injects into processes. Every uninstrumented service is a blind spot, and every SDK is another component in your audit inventory.

A kernel-space collector sits below all of that. groundcover’s eBPF sensor deploys as a single DaemonSet per Kubernetes node and collects logs, metrics, traces, and Kubernetes events from kernel hooks, with no SDKs, no code changes, and no restarts. Because collection happens at the syscall and socket layer, the collector sees a new service the moment it schedules onto a node, and coverage does not depend on developers remembering to instrument.

The eBPF verifier and sandboxed execution

Every eBPF program passes through the kernel verifier before it runs. LWN describes the verifier as a static-analysis system that checks programs for:

• termination,
• initialized memory use,
• bounds-safe access,
• valid kernel calls,
• correct argument types.

Verification runs in two phases: a DAG check that disallows loops and unreachable instructions, then simulation of every execution path with full register and stack state tracking, capped at 1 million instructions.

This is the point to make to a security reviewer: the kernel rejects unsafe programs at load time. The verifier does not monitor them after the fact. It permits load and store instructions only on registers with validated pointer types, then checks bounds and alignment. In secure mode, per the kernel verifier documentation, pointer arithmetic is rejected outright so that kernel addresses cannot leak to unprivileged users.

Be precise about what this does and does not establish, because the distinction matters later in the review. The verifier checks for stability problems that could panic the kernel and for access violations that could leak memory across privilege boundaries. It is not a general-purpose static analyzer, and it does not evaluate whether a program collects the data your policy permits. That remains the operator’s responsibility, and the answer to a reviewer asking about data scope lives in configuration and deployment topology, not in verification. The verifier is also not perfect: the Agni project (CAV 2023) formally analyzed it and found 27 previously unknown bugs, and the CVE history is covered under known risks below.

Kernel hook points and what gets collected

The main hook types produce most compliance-relevant telemetry:

• kprobes: These attach to kernel functions and expose process execution, file access, privilege-relevant syscalls, and related audit context.
• tracepoints: These are stable, versioned kernel instrumentation points suited to long-lived monitoring policies that survive kernel upgrades better than kprobes.
• uprobes: These attach to user-space functions and expose application-level activity, such as library calls, without modifying the binary.

Tetragon’s TracingPolicy, for example, hooks kernel probes and stable tracepoints, with uprobes added when user-space function visibility is required, to filter events in-kernel before they ever reach user space.

What eBPF cannot do matters equally for a review. Programs read only through verifier-approved helpers; they observe events the kernel handles rather than scanning disks or reading arbitrary data at rest. Aqua Security notes that a “lack of prevention capabilities is an unavoidable shortcoming of eBPF-based security tooling”: tracing-based probes observe file access as it starts rather than blocking it, which is why enforcement tools pair eBPF with LSM hooks.

JIT compilation and performance overhead

The kernel JIT compiler compiles verified programs to native machine code, which is why kernel-level collection is cheap enough to run fleet-wide. The strongest independent number is the ISPASS 2024 study: across Tailbench, CloudSuite, and NVIDIA Triton workloads on dual-socket AMD EPYC hardware, median and upper-quartile overhead stayed well below 1%. Read the conditions before quoting it in capacity plans, because that result holds for scoped probes at or below specified request-rate thresholds. Full observability agents at production load measure higher in independent reports, roughly 1.8 to 3% CPU.

groundcover’s published benchmark held a Golang HTTP server at a constant 3,000 req/s and measured CPU and memory before and after each agent was introduced. The groundcover eBPF sensors (also known as Flora) added 9% CPU and 0% memory over baseline. Datadog added 249% CPU and 227% memory, OpenTelemetry 59% and 27%, and New Relic’s Pixie agent 32% and 9%. On total resource consumption, meaning agent plus induced overhead, Flora used 73% less CPU than Datadog and 74%, 77%, and 96% less memory than Datadog, OpenTelemetry, and Pixie respectively. These are vendor-published figures, and groundcover’s own disclaimer is worth repeating to a reviewer: no benchmark covers every aspect of a complex system, and you should run your own against your hardware and traffic.

For node sizing, budget low single-digit CPU percentage for a full eBPF pipeline and validate on your own workloads.

Why collector overhead is an availability control, not just a cost line

Overhead is usually argued as a budget question. On a compliance page it is also an availability question, and that framing is worth making explicitly because reviewers rarely hear it.

In the same benchmark, with the monitored application capped at 1000mCPU, the competing agents did not merely consume resources. They reduced the application’s request throughput by 71% (Datadog), 19% (OpenTelemetry), and 12% (Pixie) against baseline. An observability agent that constrains the workload it observes has introduced an availability risk into the system it was deployed to assure. In a containerized environment with limits set, that path ends in CPU throttling or an OOM kill of the monitored application.

This bears on controls your reviewer already tracks. SOC 2 availability criteria and NIST 800-53 SI-4 both assume the monitoring function does not degrade the monitored system. Two design choices carry the argument: Flora runs out-of-band in its own pod and namespace rather than inside the application process, so it cannot consume the workload’s resource budget, and its resource ceiling is a Kubernetes limit the platform team sets. Separately, the BYOC data plane runs apart from your workloads, so monitoring stays available and accurate during a production incident, which is precisely when audit evidence matters most and when a co-located collector is least likely to survive.

Key features and capabilities

Security reviewers map eBPF telemetry to control evidence: audit generation, tamper evidence, runtime monitoring, file integrity, network metadata, access control, and deployment governance.

Compliance framework mapping (SOC 2, HIPAA, PCI DSS, NIST 800-53)

The table below maps eBPF telemetry types to the controls they support, drawn from AICPA, HHS, PCI SSC, and NIST source text plus published vendor control mappings:

A second set of controls is satisfied by the deployment model rather than by the collector, and reviewers ask about these just as often:

One caveat belongs in any document you hand an auditor: every explicit eBPF-to-control mapping in the public record comes from vendors and audit-automation platforms, not from regulators. Sysdig publishes the most concrete artifact, listing controls including CC6.1, CC6.8, CC7.1, and CC7.2 for SOC 2 and AU-2, AU-10, SI-4, and SI-7 for NIST 800-53 in its compliance documentation.

No NIST publication names eBPF, and no retrieved QSA statement formally accepts eBPF telemetry as a substitute for traditional evidence. The frameworks are technology-neutral, which permits eBPF-based evidence but puts the burden of the mapping on you.

Tamper-evident audit logs

Kernel-level capture happens before user-space code executes, so a compromised application cannot suppress the record of its own syscalls the way it can tamper with application logs. This is the core auditor argument, and it maps to explicit requirements: PCI DSS 10.3 requires that audit logs be protected from destruction and unauthorized modification, and Drata’s logging guidance recommends applying file integrity monitoring or change-detection mechanisms to audit logs so that existing log data cannot be altered without raising an alert. Falco ships rules mapped to NIST AU-9 and AU-10, including “Clear Log Activities” and “CloudTrail Logging Disabled,” which detect tampering with the audit pipeline itself.

eBPF events are not cryptographically signed, so tamper evidence comes from capture position plus prompt export to storage the workload cannot reach. Tetragon’s threat model states plainly: if an attacker compromises root on a node, do not trust observability data from that node. Ship events off-node quickly.

Runtime security as continuous compliance monitoring

Runtime detection doubles as ongoing compliance evidence. PCI DSS 5.3.2 explicitly accepts continuous behavioral analysis in place of periodic malware scans, and SOC 2 CC7.2 and CC7.3 require monitoring and evaluating security events, which a continuous kernel event stream satisfies by construction rather than by scheduled job.

The same telemetry also detects hostile eBPF. BPFDoor, which MITRE ATT&CK catalogs as a passive Linux backdoor used by China-based threat actors, abuses BPF socket filters to watch for trigger packets on ports 22, 80, and 443, and ebpfkit demonstrated a full eBPF rootkit at Black Hat USA 2021. Monitoring bpf() program loads and maintaining a BPF program inventory baseline turns your observability layer into the detection control for this class of threat.

File integrity monitoring via eBPF

FIM is a named requirement, not a nice-to-have: PCI DSS 11.5.2 requires a change-detection mechanism that alerts on “unauthorized modification (including changes, additions, and deletions) of critical files” with comparisons at least weekly. The traditional implementation, auditd, carries measured cost. The peer-reviewed eAudit study found auditd “slows down programs by 5× or more” at syscall granularity while its eBPF-based replacement ran at 4.5% overhead, and a USENIX Security ‘23 study measured auditd overhead reaching 261% on memcached. In Wazuh’s 50,000-file-delete test, eBPF finished in 41 seconds against auditd’s 152 with lower CPU. Datadog’s engineering team reports, as a vendor claim, that its eBPF FIM pre-filters events in-kernel and cuts overhead by 94%. Assessors evaluate process and evidence quality rather than tool choice, per Agency Insights’ QSA commentary, so eBPF FIM is admissible where the alerting and response workflow around it holds up.

Network observability scope

At the network layer, eBPF hooks read connection metadata: source and destination addresses, ports, timing, volume, and the owning process and pod. Kernel tracepoints and kprobes do not break TLS; traffic encrypted on the wire stays encrypted, which is the right default for HIPAA transmission-security review.

Be direct about the part reviewers actually ask about. Flora does not stop at metadata. The sensor reconstructs application protocols at the socket layer and can enrich traces with full HTTP request and response payloads, headers, and query parameters, with built-in PII identification. No SDK instrumentation can produce that detail on its own. Presenting the collector as metadata-only would be inaccurate, and a reviewer who finds payload capture in the documentation after reading a metadata-only claim will discount the rest of your submission.

The correct answer is not that payloads are never captured. It is that payload capture is scoped, configurable, and, critically, never leaves your cloud account. Three controls to document:

• Configuration: protocol capture, payload retention, and field masking are deployment settings. Record the values you shipped, not the defaults.
• PII identification: the sensor flags PII in captured payloads, which gives you a discovery mechanism to point at rather than an assertion that none exists.
• Residency: captured payloads land in ClickHouse inside your own cloud account. There is no third-party processor to disclose, no cross-border transfer to paper over, and no vendor-side copy to include in a subprocessor register.

Metadata alone still carries privacy weight. The CJEU held in Breyer (C-582/14) that IP addresses are personal data where the operator has reasonable means to identify the subject, and the EDPS has stated that communications metadata can be as intrusive as the content of communications. That reasoning applies with more force once payloads are in scope, which is the whole argument for keeping the data plane inside your own boundary.

Kernel telemetry addresses the monitoring dimension of § 164.312(e)(1), evidencing what was transmitted, when, and between which endpoints, while the encryption and integrity specifications in (e)(2) still require cryptographic controls on the transport path.

Privilege model and least-privilege controls

Since Linux 5.8, eBPF no longer requires blanket root. The kernel split CAP_SYS_ADMIN into scoped capabilities: tracing programs need CAP_BPF plus CAP_PERFMON, networking programs need CAP_BPF plus CAP_NET_ADMIN. Since Linux 5.13, the upstream kernel disables unprivileged eBPF by default (kernel.unprivileged_bpf_disabled=2), and Ubuntu, RHEL, Debian, and SUSE all ship it disabled. That single sysctl answers most of the blast-radius question: the verifier-bypass CVE lineage (CVE-2020-8835, CVE-2021-3490, CVE-2021-31440, CVE-2021-33200, and CVE-2022-23222 at CVSS 7.8) all required the ability to load programs, so restricting load rights to the observability DaemonSet’s service account closes the unprivileged attack surface. Where unprivileged loading is permitted at all, the kernel applies a hardening pass that further limits kernel access and reduces available functionality.

Additional hardening layers a reviewer should expect in the deployment spec:

• Frozen maps: bpf_map_freeze() makes static maps read-only, the mitigation OffSeq recommended after finding all three major eBPF security monitors susceptible to map poisoning by same-privilege attackers.
• BPF token delegation: The kernel’s BPF token primitive delegates load rights to unprivileged processes within a user namespace, scoping who can load what.
• Kernel lockdown: lockdown=integrity blocks bpf_probe_write_user, the helper eBPF malware uses to modify user-space memory.
• Load auditing: Restrict CAP_BPF distribution and audit bpf() syscalls so every loaded program is inventoried.

Deployment topology is itself a compensating control, and it is the one most likely to be missed in review. The sensor runs out-of-band in its own pod in its own namespace, not as a sidecar and not injected into application processes. It never shares a process or memory space with the workloads it observes, and it is subject to the same Kubernetes primitives as anything else in the cluster: resource limits cap its consumption, and network policies constrain where it can send data. When a reviewer asks what stops an elevated collector from becoming an exfiltration path, the answer is a NetworkPolicy they can read, plus a data plane that terminates inside their own cloud account.

Be straight about the remaining tension. CIS Kubernetes Benchmark control 5.2.1 says minimize privileged containers, and eBPF agents need elevated capabilities by design; Falco’s least-privilege modern eBPF mode runs with CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE, and CAP_SYS_RESOURCE, and it is opt-in. Document the sensor as a scoped, inventoried exception with compensating controls rather than presenting it as fully conformant with the Restricted Pod Security Standard, which it cannot be.

BYOC: the deployment model is the data-protection control

Everything above concerns what the collector reads. This section concerns where what it reads ends up, and for most reviewers it is the more consequential question. A kernel-level collector sees more than any SDK. Shipping that to a vendor’s SaaS backend converts a visibility win into a data-transfer problem: logs carry PII, traces carry tokens and payload bodies, metrics reveal topology, and every one of those becomes a third-party processing disclosure.

groundcover’s Bring Your Own Cloud architecture removes the question rather than documenting around it. All observability data (logs, infrastructure metrics, custom metrics, traces, and Kubernetes events) stays inside your own infrastructure at all times.

What runs where

Two supported deployment models, in increasing order of isolation:

The storage components sit inside your environment under all two models. ClickHouse holds logs, traces, and Kubernetes events; VictoriaMetrics holds metrics behind a Prometheus-compatible PromQL interface, which means your auditors and your existing 

BYOC is the default architecture on every paid tier, and the Free tier deploys the same architecture rather than a hosted trial variant. That matters for review sequencing: your security team can inspect real data flows on a test cluster, with the actual IAM role, namespaces, and storage in your own account, instead of assessing an architecture diagram and hoping production matches it. Deployment takes about five minutes. For environments where the managed control plane is still too wide of a boundary, airGapped removes external communication entirely.

Correct a common misreading before a reviewer forms it: BYOC does not mean self-hosting everything. In the BYOC model groundcover manages the backend, so your team is not operating an observability platform as a second job. 

Access model

groundcover never has direct access to your environment. Deployment is authorized through a scoped, least-privilege IAM role in AWS, GCP, or Azure; the automation is what acts, and its actions are visible to you. This is the paragraph to hand a third-party risk team, because it changes the question from “what could the vendor see” to “what does this IAM role permit,” which is a question your existing cloud governance already knows how to answer.

Two architectural properties reinforce it:

• Stream processing in-node. Data is processed as it travels through each node rather than staged to storage first, so no telemetry is trucked outside the cluster in the course of normal operation. This also reduces storage cost and removes an intermediate copy from your data-flow diagram.
• Out-of-band collection. The sensor runs in its own pod in its own namespace, isolated from the workloads it observes. It has no impact on monitored applications, and it is governable with native Kubernetes primitives: resource limits and network policies apply to it like any other workload.

Components a reviewer can inventory

Named workloads, so the security team can map the Helm output to this list rather than reverse-engineering it:

In the monitored cluster: sensor (DaemonSet; loads the eBPF programs, aggregates and captures data), k8s-watcher (gathers Kubernetes metadata), vector (log and trace transformation pipelines), groundcover-metrics-ingester (metric aggregation and cardinality control), groundcover-custom-metrics, groundcover-victoria-metrics-agent, groundcover-kubestate-metrics, db-manager.

In the backend: groundcover-clickhouse (StatefulSet), groundcover-victoria-metrics (StatefulSet), groundcover-opentelemetry-collector, groundcover-monitors-manager, groundcover-postgres, which brokers the connection to groundcover’s cloud for permitted users.

One line each in your vendor register, one upgrade cycle, one security review.

Access control and retention over the telemetry itself

Auditors ask who can read the audit trail, not only who generates it. RBAC is granular at namespace, cluster, and workload level, so a user can be scoped to logs and traces in production only. Retention policies are set by cluster, log level, or namespace, with daily backups, volume snapshots, and object-storage offload. Because the data plane is in your cloud account, data residency is a property of the region you deployed into rather than a contractual commitment from a vendor.

For GDPR, this is the difference between removing the third-party processing question and documenting an answer to it. For HIPAA, it means the ePHI that kernel telemetry touches never enters a business-associate relationship you would otherwise have to paper.

How eBPF compliance fits in

A kernel-level collector changes your operational and audit posture in four specific places.

eBPF vs agents and sidecars

Sidecars carry measured cost: the MeshInsight study (ACM SoCC 2023) found service meshes add “up to 269% higher latency and up to 163% more virtual CPU cores.” Per-language agents carry audit cost: each SDK version in each service is an inventory item to track, patch, and review. A single DaemonSet replaces both patterns with one component, one upgrade cycle, one security review, and one line in the vendor register.

SIEM and compliance pipeline integration

eBPF telemetry feeds existing pipelines rather than replacing them. In the open source ecosystem, Falcosidekick forwards Falco alerts to more than 50 systems, Cilium’s Hubble Exporter writes flow logs consumed by the Splunk Add-On for Cilium, and Tetragon writes JSON events to /var/log/tetragon/tetragon.log for collection by fluentd or logstash.

On the groundcover side the integration surface is OpenTelemetry, not a proprietary format. The backend runs an OpenTelemetry Collector and exposes ingestion endpoints for Prometheus, OpenTelemetry, and cloud integrations, so kernel-collected telemetry arrives in your pipeline in the same vendor-neutral shape as everything else you already route. Metrics land in a Prometheus-compatible datasource, which means existing PromQL alerting and existing Grafana dashboards work against the evidence without a translation layer.

This matters for two questions reviewers ask. First, exit: telemetry in open formats in storage you own is not a lock-in position, which shortens the vendor-concentration conversation. Second, scope of eBPF itself. Kernel collection sees everything that crosses the wire, in any language, without instrumentation. But the decisions inside your application logic, the feature flag that routed a user down one path, the business rule that fired, do not cross the wire and stay outside its line of sight by design. OpenTelemetry SDK instrumentation covers that layer. The two compose: eBPF solves the coverage problem, SDKs solve the depth problem, and groundcover’s sensor enriches SDK-generated traces with the kernel-level detail the SDK cannot see. State that boundary explicitly in your submission rather than letting a reviewer discover it.

Container and Kubernetes support

Kernel events alone are useless to an auditor without workload context. eBPF tooling built for Kubernetes maps events to the objects controls actually reference: Tetragon is “Kubernetes-aware, allowing it to map security events to namespaces and pods,” which ties syscall evidence to workload-isolation controls, and NIST SP 800-190 recommends exactly this class of container-native monitoring. The same syscall-level visibility surfaces container-breakout attempts, the technique ebpfkit demonstrated and the class CVE-2021-31440 exploited, mapping directly to workload-isolation controls. Flora collects Kubernetes events natively into ClickHouse alongside logs and traces, and supports EKS, AKS, and GKE.

eBPF security tools ecosystem

For procurement and audit trails, name the tools. Cilium graduated from the CNCF in October 2023 and Falco in February 2024, both with published threat models and control mappings; Tetragon provides kernel-level enforcement and a documented threat model but no published NIST control matrix. Flora is the proprietary option purpose-built for full-signal telemetry rather than enforcement. A reviewer can pull each project’s documentation directly, which is more than most agent-based stacks offer.

Known risks and how to mitigate them

eBPF is safe by design but not free of operational sharp edges. Each risk below pairs with its mitigation:

• Kernel version floors: CAP_BPF requires Linux 5.8, BTF and CO-RE require 5.2, and Cilium recommends 5.10 for production. Ubuntu 22.04 (5.15), Debian 12 (6.1), and Amazon Linux 2023 (6.1) all clear these; legacy Amazon Linux 2 on kernel 4.14 does not. Audit node kernels before rollout.
• Privilege escalation surface: The verifier CVE history is real but reachable only by processes that can load programs. Keep unprivileged_bpf_disabled set, patch kernels, and confine load rights to the sensor.
• Adversarial eBPF: BPFDoor variants remained active through 2026, and the Scales rootkit hit more than 1,500 Arch User Repository packages. Monitor program loads and alert on deviations from your BPF inventory baseline.
• Managed-cloud restrictions: GKE explicitly prohibits custom eBPF programs on Dataplane V2 nodes, and both GKE and AKS block the bpf syscall in their default seccomp profiles. Verify provider compatibility before committing to a tool.
• Learning curve: Verifier rejections and bounds-tracking quirks make writing eBPF programs hard, and rejection messages do not always identify the offending code. Deploying a maintained sensor avoids that cost; your team operates configuration, not BPF C.
• Portability: CO-RE with kernel BTF makes programs portable across distributions, but RHEL’s backport model (kernel 4.18 with newer features backported) means version strings mislead. Verifier behavior also varies across kernel versions, so a program accepted on one node can be rejected on another. Test per distro.
• Linux-only scope: eBPF for Windows reached v1.4.0 on July 24, 2026, still marked pre-release, and Microsoft’s repository describes it as “work-in-progress.” Windows hosts need separate coverage today.

What’s next for eBPF compliance

Three developments are worth tracking for your next audit cycle. A signed-BPF-programs patch series posted to the Linux Security Module list on September 14, 2025 extends BPF_PROG_LOAD with signature fields and an LSM hook to deny unsigned loads, which would give auditors cryptographic provenance for every program on a node. The BPF token primitive is maturing as the fine-grained alternative to handing out CAP_BPF. And on the regulatory side, HHS issued a Security Rule NPRM on December 27, 2024; the current rule remains in effect during rulemaking, but teams building HIPAA evidence pipelines on kernel telemetry should watch the final text for audit-control changes.