How GitHub Uses eBPF to Block Circular Dependencies in Deployments

GitHub hosts its own source code on github.com, which creates an unusual circular dependency: if the platform goes down, engineers can't pull the code needed to fix it. While mirrored repos and pre-built assets partially address this, a subtler risk comes from deployment scripts themselves silently depending on GitHub or internal services. The team categorizes these as direct, hidden, and transient dependencies — for instance, a MySQL deploy script fetching an open-source tool from GitHub, or an internal service doing so on the script's behalf during an outage.

Rather than relying on manual code review to catch these dependencies, GitHub built a runtime enforcement system using eBPF, which lets custom programs run inside the Linux kernel and hook into core primitives like networking. By using the BPF_PROG_TYPE_CGROUP_SKB program type, they could monitor and restrict outbound network traffic scoped to just the cGroup running the deploy script — without cutting off network access for the stateful, customer-facing host as a whole.

Since IP-based blocklists proved impractical given GitHub's scale and rate of change, the team extended the approach to DNS. Using BPF_PROG_TYPE_CGROUP_SOCK_ADDR, they intercept DNS queries (port 53) and redirect them to a userspace DNS proxy, which checks each domain against a blocklist and communicates allow/deny decisions back to the kernel via eBPF maps. The result is a lightweight, precise mechanism for catching deployment-time circular dependencies before they turn into incidents — and a practical example for engineers looking to build their own eBPF-based observability or enforcement tools with libraries like cilium/ebpf.