By David Pulaski, CXO & Co-founder, InvisiRisk
TL;DR
A Build Application Firewall (BAF) does for CI/CD pipelines what a WAF does for web applications: it sits inline, inspects live traffic, and enforces policy in real time. WAFs became mainstream because traditional network firewalls could not see application-layer attacks. BAFs address the same kind of visibility and enforcement gap in CI/CD, where pipelines have become high-value targets for software supply chain attackers. A BAF defines expected build behavior and blocks policy violations during the live build, including unapproved registries, unauthorized egress, unexpected tooling, and encoded credential exfiltration, activities that code scanners and application runtime monitors do not see.
Claim boundaries: The InvisiRisk claims below are limited to build-time enforcement inside CI/CD pipelines. InvisiRisk does not replace SCA, SAST, or DAST. It enforces policy on network and API behavior during the build itself.
In the early 2000s, web application attacks were surging and network firewalls couldn’t stop them. The traffic was HTTP, the ports were allowed, and the payloads were buried in application-layer requests that packet filters weren’t designed to read. The industry responded with the Web Application Firewall, a new category of inline security built specifically for the protocol and the environment it needed to protect. PCI-DSS later recognized web application firewalls as one way to protect public-facing applications from common web-based attacks. Over time, WAFs became standard infrastructure for many organizations running critical web applications.
CI/CD pipelines are in the same position today. The traffic is HTTPS to registries and APIs. The ports are allowed. The malicious behavior is buried in build-time execution that code scanners and runtime monitors weren’t designed to see. And the industry is responding with the same pattern: a purpose-built, inline firewall for the environment that needs it.
A Build Application Firewall (BAF) is that build firewall. It sits in the network path of a CI/CD pipeline and enforces policy on what the build is allowed to do while it runs. It’s the layer of CI/CD pipeline security that monitors what the pipeline actually executes, not what’s in the source code, not what’s in the deployed app, but what happens in the live build itself.
Why Traditional Application Security Misses Build-Time Threats
The Comfortable Complacency Problem
Most security teams have invested heavily in the tools the market taught them to buy: SAST for code, SCA for dependencies, DAST for deployed applications, secret scanning for committed credentials, CSPM for cloud posture. These tools are real and necessary. The dashboards are green, the backlogs are managed, and the team feels covered.
But coverage has a boundary. Every one of those tools operates either on code at rest or on applications after deployment. Most of them were not designed to govern what happens during the build itself, the live execution phase where the pipeline downloads dependencies, runs install scripts, injects secrets as environment variables, signs artifacts, and makes network calls to external services.
This creates what the InvisiRisk CI/CD Firewalls white paper calls comfortable complacency: the state where an organization’s tooling creates the feeling of coverage while leaving the most privileged execution environment in the SDLC completely ungoverned.
What Happens When the Dashboard Is Green but the Build Is Compromised
A compromised dependency passes SCA because the version number is valid and the CVE database hasn’t caught up. SAST doesn’t flag it because the malicious code isn’t in the repository, it arrives at install time via a preinstall hook. DAST can’t help because the damage is done before the application is ever deployed.
The Ultralytics GitHub Action compromise (December 2024) followed exactly this pattern. Attackers exploited a pull_request_target misconfiguration to inject malicious code into a trusted CI workflow, poisoning four official PyPI releases of a library with 60 million downloads. The malicious payload was a cryptocurrency miner fetched via curl during the build. The package versions looked legitimate enough to publish and spread, but the build path had been compromised. We’ll come back to this one, it’s the cleanest worked example of why this category had to exist.
How a Build Application Firewall Works
A Build Application Firewall is an inline security control deployed as a protocol-aware proxy in the CI/CD pipeline’s network path to inspect build-time traffic and enforce policy during build execution. It watches what the build actually does on the network while it runs, and it blocks violations in real time.
The Inline Broker Model
A BAF operates as a real-time broker for CI/CD communication. When a build step makes a network request, fetching a dependency from npm, calling an API, pushing an artifact to a registry, posting data to an external endpoint, the request passes through the BAF before reaching its destination. The BAF inspects the request against the organization’s defined policies and either allows it, logs a warning, or blocks it.
The implementation pattern is a protocol-aware HTTPS proxy placed in the runner’s network path. Because the BAF understands CI/CD protocols (registry APIs, Git operations, artifact uploads), it can make enforcement decisions that generic network firewalls can’t: distinguishing a legitimate npm install from an unexpected runtime download, or a normal artifact push from an encoded credential being smuggled out in a POST body.
Allowlists, Not Blocklists
WAFs historically operated on blocklists, signatures of known attacks. A BAF inverts the model. Instead of trying to enumerate every possible bad behavior, it defines what a build is expected to do and blocks everything else.
This is the allowlist (positive security) model applied to builds:
- Approved registries. A Python build fetches from PyPI and your private Artifactory. A request to an unknown registry gets dropped.
- Approved egress. Builds push artifacts to your store and report status to your CI provider. They cannot POST encoded payloads to a fresh GitHub repo or a domain registered yesterday.
- Approved tooling. A Node build runs Node, npm, and the tools you’ve defined. Pulling an unrelated runtime mid-build trips a violation.
- Approved data patterns. Outbound requests carrying Base64-encoded credentials, even to allow-listed destinations, get intercepted.
This matters because build-time attacks are overwhelmingly novel. They use zero-day compromises of trusted packages, hijacked maintainer accounts, and fresh infrastructure. Blocklists struggle with this kind of novelty. Allowlists reduce the problem by defining what the build is allowed to do in the first place.
Build Application Firewall vs. Web Application Firewall
How WAFs Became Mainstream
The WAF didn’t start as a standard tool. In the late 1990s, web applications were exploding and so were the attacks against them, SQL injection, XSS, parameter tampering. Traditional network firewalls couldn’t help because the traffic was legitimate HTTP on allowed ports. The attacks lived in the application layer.
Early WAFs were brittle CGI filters. By the early 2000s, dedicated WAF appliances appeared from a handful of pioneering vendors, most of which were eventually absorbed by the Imperva, F5, and Akamai of today. ModSecurity launched in 2002 as an open-source Apache module. Then PCI-DSS 1.0 arrived in December 2004, explicitly calling out WAFs as a compensating control for protecting public-facing web applications from common web-based attacks. That regulatory push helped move WAFs from niche tools to mainstream infrastructure for organizations running critical web applications.
Today, PCI-DSS 4.0 Requirement 6.4.2 goes further: it mandates “an automated technical solution that continually detects and prevents web-based attacks.” In practice, that has made WAF protection part of the standard security architecture for organizations handling payment card data.
Where the Analogy Holds
|
WAF |
BAF |
|
|---|---|---|
|
What it protects |
Web servers / applications |
CI/CD pipelines / build systems |
|
Where it sits |
Inline between client and server |
Inline between build runner and network |
|
What it inspects |
HTTP/S traffic at Layer 7 |
CI/CD traffic (registry, API, git, artifact) at Layer 7 |
|
How it enforces |
Policies on request/response patterns |
Policies on build-time network behavior |
|
Security model |
Blocklist + allowlist hybrid |
Allowlist-first (expected behavior model) |
|
Why it was created |
Network firewalls couldn’t see application-layer attacks |
Code scanners can’t see build-time execution behavior |
|
Compliance driver |
PCI-DSS Requirement 6.6 / 6.4.2 |
NIST SSDF, CISA secure software attestation, EO 14028-driven procurement requirements |
The structural parallel is direct: both exist because a general-purpose tool couldn’t protect a specific, high-value environment. Both sit inline. Both enforce policy on live traffic. Both became necessary when the attack surface they protect became too active to leave ungoverned.
Where the Analogy Breaks
A WAF protects a long-running server that handles millions of requests over months. A BAF protects a short-lived build that runs for seconds to minutes, then disappears. That difference drives the design:
- Ephemeral environments. A BAF must deploy and attach per-build, not per-server. It needs to be a lightweight build step, not a persistent appliance.
- Protocol diversity. WAFs primarily parse HTTP/S. BAFs need to understand registry protocols (npm, PyPI, Maven, Docker Hub), Git operations, API calls, and artifact uploads.
- Allowlist-first. WAFs evolved from blocklists because web traffic is open-ended, you can’t predict every legitimate request. Build traffic is constrained, you can define expected behavior. That makes allowlists practical in a way they aren’t for general web traffic.
Key Capabilities of a Build Application Firewall
Deep Packet Inspection of Build Traffic
A BAF performs Layer 7 inspection of all traffic flowing through the CI/CD pipeline during execution. It decrypts TLS, parses protocol-specific payloads (registry requests, API calls, Git operations), and evaluates each transaction against policy before allowing it to proceed. This is not log analysis after the fact, it’s inline inspection while the build is running.
In the Ultralytics case, that’s the difference. The malicious cryptominer was fetched via curl to a domain the legitimate build had no business calling. A BAF inspecting Layer 7 traffic against an allowlist of approved download sources would have dropped that request before the payload ever hit the runner.
Policy Enforcement via OPA and Rego
InvisiRisk’s BAF uses Open Policy Agent (OPA) with policies written in Rego for fine-grained, customizable enforcement. Organizations can define rules at any granularity: block packages published less than 48 hours ago, deny egress to domains registered in the last 30 days, require all downloads to originate from approved registries. Policies can run in warn mode (visibility) or deny mode (enforcement), allowing teams to audit before they block.
Encoded Secret Interception
Attackers increasingly encode stolen credentials, Base64, double-Base64, hex, or split across multiple requests, to evade source-level secret scanners. A BAF inspects outbound request bodies and headers in real time and detects encoded secrets being exfiltrated, even when hidden inside API calls to allow-listed destinations. InvisiRisk’s v1.1.38 release specifically targets these patterns.
SBOM Reconstruction and Build Attestation
Because a BAF observes every dependency the build actually fetches, not just what the manifest declares, it can reconstruct a complete software bill of materials (SBOM) based on real network traffic, what InvisiRisk calls TruSBOM™. It also generates cryptographic SBOM attestation evidence, recording inputs, outputs, and actors for each build. This evidence satisfies NIST SP 800-218 (SSDF) and CISA’s secure software attestation requirements. It shifts SBOM generation from a documentation exercise to a verifiable, evidence-based practice.
For a full catalog of the build-time attacks these capabilities address, see InvisiRisk Build & CI/CD Security Alerts →
Where a Build Application Firewall Fits in the Security Stack
A BAF is additive. It covers the phase your scanners can’t see.
Your existing tools continue to do their jobs:
- SAST catches insecure coding patterns in source code
- SCA (Software Composition Analysis) flags known vulnerabilities in declared dependencies
- Secret scanning finds committed credentials in repos
- DAST tests deployed applications for exploitable flaws
- CSPM monitors cloud posture and configuration
A BAF adds inline enforcement during the phase those tools were not designed to control: the live build. It watches what actually happens on the network when the pipeline runs, and it blocks violations before secrets leave the runner or compromised artifacts get signed.
It’s the same architectural decision the industry made with WAFs. You don’t stop running your application scanner just because you deployed a WAF. You deploy both because they cover different attack surfaces. A BAF is that logic applied to CI/CD.
The Future of Application Security Is Build-Time Enforcement
This is the category InvisiRisk operates in. InvisiRisk released the industry’s first Build Application Firewall in 2025, purpose-built for inline build-time enforcement in CI/CD pipelines. Today, InvisiRisk performs deep packet inspection of CI/CD traffic, enforces policy via OPA/Rego, intercepts encoded secret exfiltration, reconstructs TruSBOM™ from real build traffic, and generates attestation evidence. It works with GitHub Actions, GitLab, Jenkins, Azure DevOps, and more.
The software supply chain security landscape has shifted permanently. Web applications adopted WAFs because the attack surface demanded inline protection and compliance frameworks reinforced the need for it. CI/CD pipelines are moving in the same direction. Attacks targeting build systems, package ecosystems, and developer automation are already happening, and the frequency and business impact are increasing. At the same time, compliance frameworks such as NIST SSDF, CISA’s secure software attestation requirements, and EO 14028-driven procurement expectations are raising the bar for software producers.
The question is not whether build pipelines will need inline enforcement. It’s whether organizations will adopt it before or after the next major incident.
Put a firewall on your build. Get Started →
