The full hardening toolchain, free and open.
The eBPF sensor, image builder, CLI, Helm chart, and GitHub Action are all open source. Profiles are plain JSON, hardened images are standard OCI, and nothing phones home.
What’s in the repo
eBPF Sensor
CO-RE kprobe sensor written in pure Go using cilium/ebpf. Attaches to openat(), filters by cgroup/namespace, ships events over a ring buffer. Runs as a DaemonSet pod. No kernel module, no DKMS, no side-cars.
Image Builder (hardener)
Takes the sensor manifest, resolves ELF shared-library dependencies recursively via readelf + ld.so.conf, applies language-runtime companion rules, then emits a new OCI image layer containing only the files that were actually observed.
harden CLI
Static binary that builds and pushes the minimised image from a sensor profile: ELF resolution, confidence scoring, SBOM generation, registry push. Needs nothing besides the profile JSON. Built for linux and darwin on amd64 and arm64. (The tracepod CLI is also in the repo; its commands talk to the platform controller.)
Helm Chart
Official Helm chart for Kubernetes deployment: DaemonSet for the sensor with the RBAC (ClusterRole + ServiceAccount) it needs, values for kernel and runtime tuning. Exercised end-to-end on kind in CI.
GitHub Action
Add a uses: tracepod/tracepod@v0 step to your release workflow. Give it a recorded profile and a source image; it builds, smoke-tests, and SBOMs the hardened image, and can push it alongside the original.
SBOMs + removal manifest
CycloneDX and SPDX SBOMs produced by syft, with optional cosign signing. Every build also records a removal manifest: the exact set of packages the hardening dropped. Seccomp and AppArmor profile generation is on the roadmap.
Install with Helm from the repo.
The chart ships in the repository; a hosted chart repo is on the roadmap. You need Kubernetes 1.25+, nodes on kernel 6.8 or newer, and containerd NRI enabled – a one-line config change if it isn’t already, and theinstallation guide covers it.
Full installation guide →# Kubernetes: sensor + controller via the Helm chart
$ git clone https://github.com/tracepod/tracepod
$ helm install tracepod ./tracepod/helm/tracepod \
--namespace tracepod --create-namespace
# CLI binaries from GitHub releases
$ curl -fsSLO https://github.com/tracepod/tracepod/releases/download/v0.1.2/tracepod_tracepod_0.1.2_linux_amd64.tar.gz
$ sudo tar xzf tracepod_tracepod_0.1.2_linux_amd64.tar.gz -C /usr/local/bin
# Verify
$ tracepod version
tracepod v0.1.2 (2f8a41c)
Is it safe to run eBPF on production nodes?
The sensor only observes: it reads openat() events from kprobes and never modifies workload behaviour. eBPF programs are bounds-checked by the kernel verifier before they load, so a sensor bug cannot panic a node. Under event pressure the ring buffer drops events rather than blocking your workloads, and the profile records the loss counters so you know it happened.
What if profiling missed a code path?
Then the confidence score is lower and the manifest shows the gap; you profile longer or add the paths by hand. This is the honest limit of runtime profiling, and it is why the platform exists: sandbox validation runs the hardened image before it ships, and the auto-fix loop rebuilds with anything that turns out to be missing.
Does AGPL affect my images?
No. You run Tracepod as a tool; you do not link against it. The images it produces are yours, with no license obligations attached. AGPL obligations apply only if you modify Tracepod itself and offer it to others as a service. Commercial licenses are available if your legal team prefers one.
Want the full platform?
The Tracepod platform adds a web dashboard, sandbox validation, auto-fix, CVE delta reports, and more.