| 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.
https://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. |
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