Back to browse
GitHub Repository

Secure your Docker builds against supply chain attacks — restrict outbound network access to only the domains you allow

6 starsJavaScript

Buildcage – Restrict outbound network access during Docker builds

by dash14·Feb 14, 2026·1 point·2 comments

AI Analysis

●●SolidSolve My ProblemNiche Gem

Network allowlist firewall for Docker builds, zero Dockerfile changes, GitHub Actions ready.

Strengths
  • Zero Dockerfile modifications required; integrates as remote BuildKit driver
  • Audit and restrict modes let teams discover then enforce build dependencies
  • Directly addresses real supply chain risk: blocking exfiltration during npm/apt installs
Weaknesses
  • Only blocks connections to unapproved domains; malicious packages via approved registries still pass through
  • Nascent project with 2 stars and minimal adoption; unproven at scale
Category
Target Audience

DevOps engineers and CI/CD pipeline maintainers concerned with supply chain security

Similar To

Aqua Security solutions · Snyk supply chain tools · BuildKit network policies

Post Description

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.

Similar Projects