dpndncY

The four BPF programs

The runtime agent attaches four CO-RE BPF programs to your CI runner. Together they answer: what ran, what it talked to, what it read, and what it resolved — correlated back to the exact workflow step that caused each event, and bound into a signed trace at the end of the job.

The hooks

HookSees
connect (connect4/connect6)Every outbound TCP/UDP connection — destination IP, port, address family (IPv4 + IPv6). The enforcement point in enforce mode.
exec (sched_process_exec)Every process exec — argv, cwd, parent pid, and ancestry back to the workflow step.
file open (security_file_open)Opens of sensitive paths against an allowlist — SSH keys, /etc/shadow, /proc/self/maps, cloud credential files.
DNS (getaddrinfo uprobe)Every name resolution with the resolved address family — so egress to a host is visible even before the connect.

What it does not see

The agent captures syscall-level metadata, not payloads. It records that a connection to a host occurred and which process caused it — not the contents of TLS traffic, file bodies, or environment values. It is an evidence recorder, not a wiretap.

Event correlation

Every event is tagged by pid and cgroup and walked up the process ancestry to the CI workflow step that spawned it. That’s what turns a raw syscall stream into “step build ran curl which connected to x” — the line an investigator actually needs.

Kernel requirements
The programs use BTF + CO-RE, so they need a reasonably modern kernel with BTF enabled (typical of current GitHub/GitLab runners and mainstream distros). The agent verifies support at startup.

Output

The full event stream is written as NDJSON; its SHA-256 is bound into the job’s signed runtime-trace/v1 attestation, so the evidence is tamper-evident and verifiable offline.