The five runs below come from different ecosystems — npm, PyPI, GitHub Actions — and different incidents. Each was replayed or installed on a Garnet-instrumented runner. The records carry the same shape of evidence in every case: process ancestry, network egress, file activity, and the per-check results. Public reporting on each incident is linked from the individual field notes; the focus here is what the records contain.
Five runs. Three ecosystems. One shape of record.
The pattern
The shape repeats in any environment that executes code the operator did not author:
- A trusted surface executes first — dependency install, action resolution, or automation task kickoff.
- Payload code reaches a high-trust runtime context — secrets, cloud identity, signing material, and unrestricted egress.
- Post-hoc artifacts are partial by design — self-deleting scripts, in-memory stages, and clean log output beside hostile branches.
CI is the most visible slice right now because workflows routinely execute third-party code at scale. The same structure appears in AI-agent sandboxes and transitive runtime dependencies. Prevention controls reduce exposure; runtime records answer what actually executed when prevention misses.
What runtime visibility changes
For each of the five incidents, we detonated the compromised package or action inside a GitHub Actions runner instrumented with Garnet's eBPF sensor. The sensor records every process spawn, file access, and network connection at the kernel level — not from logs, not from the application layer.
The results are consistent:
| Run | Ecosystem | What the record carries |
|---|---|---|
| Axios npm | npm | postinstall → sh → curl → python3 chain to sfrclak.com; on-disk traces rewritten on exit |
| LiteLLM | PyPI | .pth startup chain reaching IMDS, Kubernetes secrets, and workspace credential files |
| Trivy Action | GitHub Actions | Sibling /proc/<pid>/mem branch and typosquat egress, held in one workflow tree |
| KICS Action | GitHub Actions | Parallel branch reaching checkmarx[.]zone alongside a clean scanner log |
| Telnyx | PyPI | Base64 child spawn, open TCP to 83.142.209.203:8080, child reparented to systemd(1) |
Every record carries the per-check delta between clean and replayed installs: zero signals on clean, multiple signals on the replay. The split is in the lineage, not in the workflow source.
The structural gap
The industry response to this wave has focused on prevention: pin commits, audit dependencies, enforce release age. Those are good defaults. They reduce the attack surface.
But they do not answer the question that matters most when prevention fails: what actually happened on the runner?
Which process chain led from install to execution? What files were touched? What network connections were made, and from which ancestor process? Was there evidence of attempted exfiltration, or only potential access?
Those questions require a runtime record. Not inference from package metadata. Not reconstruction from incomplete logs. A kernel-level audit trail of what code actually did during the build.
The evidence trail
Each field note linked below contains the full execution lineage for one incident — the interactive run profile, the process tree, the network connections, the behavioral signals. They are the evidence behind this argument.
- Axios npm — record carries the postinstall chain and the flagged outbound after on-disk evidence is rewritten
- LiteLLM PyPI — record carries a
.pthstartup chain that fires before anylitellmimport - Aqua Trivy Action — record carries a sibling
/proc/<pid>/membranch alongside a green-exit Trivy scan - Checkmarx KICS Action — record carries a parallel branch reaching
checkmarx[.]zonenext to a clean scanner log - Telnyx PyPI — record carries a child process that outlives the workflow step and reparents to
systemd(1)
Explore any run profile above, or start observing your own workflows with Garnet.
