Application security has spent the last decade building better static and dependency-time defenses — SAST, SCA, signed provenance — while the runtime itself stayed a black box. That gap matters more every year: the xz backdoor (CVE-2024-3094) sat in a release tarball for weeks before a Microsoft engineer noticed a half-second SSH login delay on March 29, 2024, and caught it by accident, not by policy. Two technologies born in observability engineering, not security, are now closing that gap: eBPF, a Linux kernel technology first merged in 2014 and massively expanded since kernel 4.x, and OpenTelemetry, the CNCF project formed in 2019 from the merger of OpenCensus and OpenTracing. Together they let security teams see what code actually does in production — every syscall, socket, and process spawn — without redeploying a single service. This post explains how the two fit together, what they catch that scanners miss, and where the approach still breaks down.
What Makes eBPF Different From Traditional Security Instrumentation?
eBPF is different because it runs security logic inside the Linux kernel itself, attached to real events, instead of relying on an application to log its own behavior. Extended Berkeley Packet Filter started as a networking filter mechanism merged into the kernel in 2014, and by kernel 4.4 (2016) it had grown into a general-purpose, sandboxed virtual machine that can attach small verified programs to syscalls, network events, function entry/exit points, and scheduler events. A kernel-side verifier statically checks every eBPF program before it loads, rejecting anything that could loop forever or access memory it shouldn't — which is why, unlike a kernel module, a buggy eBPF probe can't crash the box. Practically, this means a security tool can watch every execve, connect, or openat call across every container on a host from one privileged agent, with no code changes, no library injection, and no restart of the monitored application. Projects like Cilium's Tetragon (2022) and Falco (originally 2016, later eBPF-native) built entire runtime security products on exactly this primitive.
How Does OpenTelemetry Fit Into the Security Picture?
OpenTelemetry fits in because it standardizes how that raw kernel-level data becomes structured traces, metrics, and logs that security tooling can actually correlate. Before OTel, every vendor — APM, tracing, security — shipped its own instrumentation SDK, its own wire format, and its own agent, which meant a security signal from a kernel probe and a request trace from an application framework had no common vocabulary. OpenTelemetry, now the second-most active project in the CNCF behind Kubernetes, fixed that with a vendor-neutral specification for spans, resource attributes, and semantic conventions, plus the OTLP protocol for shipping them anywhere. Since 2023, the OTel community has been extending semantic conventions to cover security-relevant fields — process attributes, network peer identity, and CI/CD pipeline metadata — specifically so eBPF-collected events can be exported as OTel spans and joined against normal application traces in the same backend, using the same query language, instead of living in a separate SIEM silo.
Why Are Security Teams Combining eBPF and OpenTelemetry Now?
Security teams are combining them now because supply chain attacks increasingly execute only at runtime, after every static gate has already passed. The 2018 event-stream compromise and the 2021 ua-parser-js takeover both shipped malicious code through legitimate npm accounts; static scanners saw a routine version bump, not a threat. SBOM and SCA tools, which matured rapidly after Executive Order 14028 in May 2021 pushed federal software supply chain requirements, are excellent at answering "what's in this artifact," but they answer that question before deployment — they say nothing about what a dependency's postinstall script or a compromised transitive package actually does once it's running with your production credentials. eBPF closes that specific blind spot by observing behavior directly in the kernel, and OpenTelemetry gives that behavioral data a shared, portable format so it can flow into the same pipelines security and platform teams already run, rather than requiring a bespoke runtime-security stack bolted on the side.
What Can eBPF Plus OpenTelemetry Actually Detect That SAST and SCA Miss?
They detect the specific moment a dependency does something its manifest never promised, which static and composition analysis structurally cannot see. Concretely: an eBPF probe watching execve and connect syscalls will flag a Node.js postinstall script spawning /bin/bash -c curl, a Python package opening an outbound TCP connection to an IP with no corresponding DNS record, or a build-time tool suddenly reading ~/.aws/credentials — all in real time, attributed down to the process and container. In the xz case, the payload only activated under specific SSH connection conditions, which is exactly the kind of conditional runtime behavior that a source or dependency-graph scan cannot exercise but a kernel-level trace of the actual sshd process would surface immediately as an anomalous child process and unexpected library load. Once that event is emitted as an OTel span with standard resource attributes (service name, container ID, k8s pod, CI job), it can be correlated automatically against the build pipeline that produced the artifact — answering "which commit, which pipeline run, which dependency version" in one query instead of a multi-day forensic reconstruction.
What Are the Limitations and Risks of eBPF-Based Security?
The main limitation is that eBPF sees the kernel's view of the world, which is not the same as a complete security view. Kernel version fragmentation is real: full CO-RE (Compile Once – Run Everywhere) support needs BTF metadata that only became reliable around kernel 5.2+ (2019) and is inconsistent on older enterprise Linux distributions, so fleets running mixed kernel versions get uneven coverage. Encrypted payloads are invisible to a syscall-level probe by design — eBPF sees that a connection to a given IP and port happened, not what was inside a TLS session, so it complements application-layer instrumentation rather than replacing it. High-volume tracing also has a real overhead budget: naively hooking every syscall on a busy host can add measurable CPU cost, which is why production deployments filter aggressively at the probe (only tracing execve, network syscalls, and file opens in sensitive paths, for example) rather than tracing everything. Finally, eBPF requires elevated kernel privileges to load programs, which means the security tool itself becomes a component that needs its own supply chain scrutiny — a poorly vetted eBPF agent is a very high-value target.
Should Every AppSec Team Adopt eBPF and OpenTelemetry Right Now?
Not wholesale, but every team running containerized production workloads should be piloting it, because the cost of instrumentation has dropped faster than most security roadmaps have caught up. A reasonable starting point in 2026 is narrow and additive: instrument CI/CD runners and build agents first, since that's where malicious postinstall scripts and compromised build tooling actually execute, before extending to production services. Export events as OTel spans into whatever backend already ingests application traces, so security gets a unified timeline instead of a parallel dashboard nobody checks. Start with a short allowlist of high-signal syscalls — process exec, outbound connections, and sensitive file reads — rather than trying to trace everything on day one, and treat the eBPF agent itself as a first-class artifact subject to the same SBOM and provenance checks as any other production binary.
How Safeguard Helps
Safeguard treats runtime behavior as a first-class supply chain signal rather than a bolt-on. Our platform ingests eBPF-derived, OpenTelemetry-formatted runtime events from build agents and production workloads and correlates them directly against the SBOMs, commit history, and dependency provenance we already track for every artifact — so an anomalous execve from a build step is automatically tied back to the specific package version, pull request, and pipeline run that introduced it, not left as an isolated alert. Because we consume standard OTLP spans, teams don't need to run a separate Safeguard-specific sensor stack; existing eBPF collectors and OpenTelemetry pipelines feed straight into our detection and provenance graph. That combination is what turns a raw kernel event — a suspicious outbound connection, an unexpected child process — into an actionable finding with full supply chain context: which dependency, which version, which commit, and which build produced it, in minutes instead of days.