{"id":47016063,"title":"Show HN: Buildcage – Restrict outbound network access during Docker builds","points":1,"user":"dash14","time":1771088176,"time_ago":"8 hours ago","type":"link","content":"

Hi HN,

I built buildcage as part of our supply chain security efforts at work. The problem we kept running into: when you run `RUN npm install` in a Dockerfile, that command can connect to anywhere on the internet, and you have no visibility into where it actually goes. Even with pinned dependencies, a compromised package could still exfiltrate build secrets or phone home to a C2 server during the build itself.

buildcage is a Docker container that wraps BuildKit with an internal proxy. You give it a list of allowed domains, and only connections to those domains go through — everything else is blocked and logged. Your Dockerfiles stay exactly the same.

If you use GitHub Actions, it's a few lines to add to your workflow — see the quick start guide.\nhttps://github.com/dash14/buildcage#quick-start

I want to be upfront — this is not a silver bullet. If a malicious package is delivered through a legitimate registry, the connection goes to an allowed domain and buildcage can't catch it. You should still pin dependencies, use lock files, and scan for vulnerabilities.

The way I think about it: buildcage is a last line of defense. If something slips through all your other measures, at least it can't call home to an attacker's server.

That framing is exactly why I focused on making it easy to adopt. A security tool that's hard to set up doesn't get set up. With buildcage, you add a few lines to your GitHub Actions workflow and everything just works — no certificate injection, no Dockerfile changes, no special build flags.

Would love to hear your thoughts — whether it's about the approach, the limitations, or how this fits into your own workflow.","url":"https://github.com/dash14/buildcage","domain":"github.com","comments":[{"id":47016229,"level":0,"user":"vict00r99","time":1771089329,"time_ago":"7 hours ago","content":"

Hey!Really interesting approach

I’m going to try it in one of my CI pipelines

Quick question: how granular is the allowlist matching, is it exact domain only or do you support wildcards and subdomain patterns","comments":[]}],"comments_count":1}