# Build Application Firewalls: The Next Frontier in Supply Chain Attack Defense


Supply chain compromises have become the attack vector of choice for sophisticated threat actors, and traditional code scanning is proving inadequate. A new class of security tools—Build Application Firewalls (BAFs)—aims to catch threats that static analysis misses by monitoring runtime behavior within the CI/CD pipeline itself.


## The Threat: Stealth in the Supply Chain


The SolarWinds attack of 2020 was supposed to be a watershed moment. When North Korean and Russian threat actors compromised the software development process of one of the world's most trusted infrastructure monitoring tools, the attack eventually touched approximately 18,000 organizations, including multiple U.S. government agencies. The impact was measured not just in breach scope, but in the erosion of trust: if one of the industry's most respected companies could be weaponized, what couldn't?


Yet six years later, we're still learning the hard way that the supply chain lesson remains unlearned.


## Recent Attacks: A Pattern of Persistence


2026 is shaping up to be a critical year for supply chain security failures. In March, North Korean actors successfully hijacked an Axios npm library maintainer's account—a critical JavaScript HTTP client used in countless applications. They published two malicious versions before the compromise was detected. Though the window of exposure was brief, researchers estimate the poisoned packages were downloaded by approximately 3% of the Axios user base before removal, translating to hundreds of thousands of installations.


The payload was unambiguous: a remote access trojan delivered through the CI/CD pipeline, ready to persist in production systems.


But the Axios incident was not an isolated spike. In February and March 2026, a coordinated campaign attributed to the TeamPCP threat group systematically compromised three critical development tools:


  • Aqua's Trivy – a widely-used vulnerability scanner
  • BerriAI's LiteLLM – an increasingly popular LLM abstraction library
  • Checkmarx/kics – a code quality and security scanning framework

  • The goal was consistent: gain access to the CI/CD pipelines of organizations using these tools. By March 31, Mercor announced it was one of thousands of companies impacted by the LiteLLM compromise. In April, the European Commission disclosed that threat actors had stolen 300 gigabytes of sensitive data using API credentials compromised in the Trivy supply chain attack.


    The escalation is stark. These weren't boutique tools with limited adoption—they are industry-standard components of modern software development infrastructure.


    ## Background and Context: Why Supply Chain Attacks Work


    ### The Automated Trust Problem


    Modern software development operates on a principle of cascading trust. A developer specifies a dependency—perhaps npm install axios—and the build system automatically fetches the latest version from a public repository. This automation is essential for velocity and maintainability. But it's also a vulnerability.


    Three attack vectors dominate:


    1. Direct account compromise – Hijacking maintainer credentials (as with Axios)

    2. Typosquatting – Publishing malicious packages with names similar to legitimate ones

    3. Compromised infrastructure – Infiltrating the build pipeline of widely-used tools (Trivy, LiteLLM)


    When a compromised package enters the build, it is incorporated into the application without explicit developer review. The malicious code may be obfuscated, delayed, or designed to avoid detection by static analysis tools. It then propagates downstream to every organization using that tool.


    ### Existing Defense Gaps


    Traditional supply chain security relies heavily on code scanning: tools that analyze source code and dependencies for known vulnerabilities and suspicious patterns. These include Software Composition Analysis (SCA) tools, Software Bill of Materials (SBOM) generation, and static application security testing (SAST).


    These tools are necessary. They are not sufficient.


    ## Technical Details: How Compromises Evade Traditional Scanning


    ### The Zero-Day Problem


    David Pulaski, co-founder of InvisiRisk, articulates the core limitation: "If we don't know there's a vulnerability, we just let the package in."


    Scanner-based defense operates on signature-matching and rule-based detection. If a piece of malicious code uses a novel technique—an unknown zero-day in the build environment, or a post-build exfiltration channel—scanners have nothing to compare it against. The vulnerability simply isn't in their database.


    This challenge is compounded by AI-assisted attack engineering. Contemporary frontier models (GPT-4, Claude 3, and others) can identify novel software vulnerabilities, reason about their exploitability, and generate stealthy exploitation code. The "Mythos effect"—referring to the legendary likelihood of buried vulnerabilities in large codebases—suggests that AI-assisted attackers can discover and weaponize zero-days faster than security research can detect them.


    ### Legitimate-Looking Malicious Activity


    A second evasion vector is behavioral legitimacy. A compromised package might exfiltrate API secrets to a GitHub API endpoint. Legitimate npm packages make requests to GitHub regularly (they are, after all, hosted there). A scanner examining the code may flag it as suspicious—or may not, depending on its rules. The distinction between "legitimate outbound API call" and "secret exfiltration" requires semantic understanding that static analysis struggles with.


    Similarly, hardened CI/CD runners—containers with restricted network access and minimal tools—can only inspect DNS queries and top-level network traffic. They lack deep packet inspection, making it impossible to detect whether a "legitimate" outbound connection is actually stealing secrets or credentials.


    ## The Build Application Firewall Solution


    Rather than asking "Is this code malicious?" (a question scanners answer), BAFs ask "What is this code doing?" during execution.


    ### How BAFs Work


    A Build Application Firewall monitors the runtime behavior of every package and build step within the CI/CD pipeline. It acts as a guardian inside the build process, observing:


  • Network connections – Where is traffic being sent, and on what ports?
  • File system operations – What is being read, written, or deleted?
  • Secret handling – Which credentials are being accessed, and are they being exfiltrated?
  • Process execution – What external commands are being invoked?
  • Timing and triggers – When do suspicious actions occur?

  • Unlike traditional runners that can only block certain network destinations (a crude allowlist approach), BAFs perform deep packet inspection and behavioral analysis. They can distinguish between a legitimate GitHub API call and a secret being posted to an attacker-controlled server disguised as a GitHub call.


    ### Key Advantages Over Scanning


    | Approach | Detection Method | Known Zero-Days | Legitimate-Looking Attacks | Deployment Complexity |

    |----------|-----------------|-----------------|---------------------------|----------------------|

    | Static Scanning | Signature/rule matching | ❌ Miss unknown exploits | ❌ High false-negative rate | Low |

    | Build Firewall | Runtime behavior observation | ✅ Detects anomalous activity | ✅ Detects intent regardless of legitimacy | Medium |


    ## Implications for Organizations


    ### Who Is at Risk?


    Every organization using open-source software is exposed. The attack surface includes:


  • Direct dependencies – Packages you explicitly use
  • Transitive dependencies – Packages your packages depend on
  • Build-time tools – Scanners, linters, and plugins invoked during the build

  • The January 2026 discovery that security tools themselves (Trivy, kics) were compromised is particularly damaging: organizations using these tools to defend themselves were instead introducing the attack vector.


    ### Supply Chain Maturity Assessment


    Organizations should evaluate their current posture:


    1. Immature – No SBOM generation, no dependency scanning, no supply chain oversight

    2. Basic – SCA tools and SBOM generation in place, but no behavioral monitoring

    3. Advanced – Hardened runners, network segmentation, and allowlisting of dependencies

    4. Resilient – BAFs monitoring build-time behavior, automated response to anomalies, rapid incident response capabilities


    Most enterprise organizations today operate at the "Basic" level and are vulnerable to the attacks we've seen in Q1 2026.


    ## Recommendations for Defenders


    ### Immediate Actions


  • Audit all open-source dependencies – Generate SBOMs and identify versions used during the Trivy, LiteLLM, and Axios compromise window (January–April 2026)
  • Review access logs – Check for exfiltrated credentials or unusual API activity
  • Patch and rebuild – Rebuild all software artifacts using clean, verified package versions
  • Rotate secrets – Assume that any credentials accessible to the build process may have been compromised

  • ### Medium-Term Hardening


  • Implement supply chain security policies – Lock dependency versions, require approval for transitive updates, and establish a vendor assessment process
  • Deploy hardened CI/CD runners – Use minimal-privilege build environments with restricted network access
  • Generate and monitor SBOMs – Track component provenance and flag unexpected changes
  • Implement behavioral monitoring – Evaluate Build Application Firewall solutions for your pipeline

  • ### Strategic Priorities


  • Adopt zero-trust CI/CD – Treat all dependencies and build tools as potentially hostile until proven otherwise
  • Develop incident response procedures – Establish playbooks for supply chain compromise detection and response
  • Build security culture in development teams – Train developers to understand supply chain risks and security best practices

  • ---


    ## HackWire Analysis


    The supply chain attack problem has reached a critical inflection point, and traditional defenses are demonstrably inadequate. The fact that we've now seen the *same attack methodology* successfully executed multiple times in 2026—against Axios, Trivy, LiteLLM, and kics—reveals a structural vulnerability that static scanning cannot address.


    What makes this moment different from SolarWinds is the democratization of capability. In 2020, SolarWinds was targeted by sophisticated nation-state actors. Today, we're seeing coordinated campaigns against multiple tools, suggesting that supply chain attack tradecraft has matured into a reliable technique accessible to well-resourced threat groups. The TeamPCP campaign was particularly effective because it targeted *tool infrastructure itself*—the scanners, linters, and libraries that defenders rely upon. This creates a perverse incentive: using security tools to protect your supply chain becomes a vector for compromise.


    The emergence of Build Application Firewalls addresses a real gap that static analysis cannot fill. But here's the uncomfortable truth: BAFs are a defensive escalation that assumes compromise is inevitable. Rather than preventing malicious code from entering the build, they assume it will enter and focus on detecting malicious *behavior*. This is pragmatic given the reality that zero-days and AI-assisted exploitation will continue to evade signature-based detection. But it also signals that we've moved from a "detect and prevent" security model to a "detect and respond" model in the supply chain context.


    Organizations implementing BAFs should pair them with automated incident response: the moment anomalous behavior is detected, the build should fail automatically, alerts should fire, and evidence should be collected. A firewall that warns about suspicious behavior but permits the build to complete is theater, not security.


    The broader pattern here is troubling: supply chain attacks work because they exploit trust relationships at scale. Each successful attack makes the next attack easier, because threat actors learn which tools are least likely to be scrutinized, which maintainer accounts are least well-protected, and which cloud infrastructure is most readily compromised. Until we develop detection capabilities that *match the speed and sophistication of modern attacks*, we will continue to lose. Build Application Firewalls are a necessary step forward—but they are a step, not a destination. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)