Many of the most severe supply chain vulnerabilities stem from weaknesses introduced into software during the CI/CD build process. A build application firewall could offer a powerful solution.
The 2020 SolarWinds supply chain breach—impacting roughly 18,000 organizations—should have served as a critical wake-up call. It exposed a major attack vector: infiltrating the development lifecycle of widely adopted tools. Yet, despite its scale, we failed to implement effective defenses. Since then, attackers have repeatedly exploited the same strategy with success.
In March 2026, North Korean threat actors took over the account of an Axios npm library maintainer and released two malicious versions. Because Axios is highly trusted and typically integrated automatically, these compromised packages were downloaded by an estimated 3% of its user base before being taken down. The ultimate payload was a remote access trojan delivered through the CI/CD pipeline.
Around the same time—in February and March 2026—the group known as TeamPCP targeted Aqua’s Trivy vulnerability scanner, BerriAI’s LiteLLM, and Checkmarx/kics. Their goal was identical: gain access to the CI/CD pipelines of widely used development tools. On March 31, Mercor disclosed it was “one of thousands of companies affected by a supply chain attack involving LiteLLM.” Shortly after, in early April, the European Commission suffered a data breach involving 300GB of sensitive information, traced back to an API key exposed during the Trivy compromise.
At the heart of these incidents is flawed or malicious code slipping into the CI/CD build process—often without the developer’s knowledge. Most modern build systems automatically fetch dependencies from repositories like npm or PyPI. However, a hijacked package, a typo-squatted dependency, or a tampered version can still be pulled into the build unnoticed.
Security scanners are meant to catch such threats both at the start and end of the build. While they often detect suspicious code, they’re not foolproof. Two key limitations explain why: first, malicious behavior may appear benign (for example, posting data to GitHub—a common source for npm packages—might not raise alarms); second, unknown zero-day vulnerabilities simply evade detection.
This second issue is sometimes referred to as the “Mythos effect.” Advanced AI models are increasingly capable of uncovering hidden vulnerabilities and crafting stealthy exploits that blend into legitimate workflows. Traditional CI/CD scanners are unlikely to flag these—or notice when secrets are sent to seemingly trusted IP addresses. As a result, this class of supply chain attack is expected to grow.
“If we don’t know a vulnerability exists, we let the package through,” explains David Pulaski, co-founder of InvisiRisk. “It’s like a doorman checking an invitation that looks valid. But once inside, the intruder acts maliciously—say, exfiltrating a secret to a harmful destination or sending it to a legitimate one it shouldn’t access. Once embedded, the code executes its harmful purpose.”
Pulaski’s approach shifts from passive scanning to active inspection of every package entering the build. InvisiRisk has created a Build Application Firewall (BAF)—a real-time guard for the CI/CD pipeline. “The guest the doorman admits might walk off with our valuables. But with our firewall, we’re monitoring activity inside the build itself and can see exactly what’s happening.”
While hardened runners are commonly used to block unauthorized access and prevent secret leaks, they only monitor DNS traffic. “They lack deep packet inspection like a true firewall,” notes Pulaski. “So if someone steals data and sends it back to GitHub, the runner says, ‘Go ahead.’ Our firewall, however, inspects the actual content and destination—and recognizes the theft in real time.”
Crucially, the BAF doesn’t need to recognize a specific vulnerability to detect malicious behavior. It flags any action that deviates from expected norms.
InvisiRisk’s BAF enforces security policies during the build—not just scanning inputs or final outputs. Users can define these policies using a guided wizard, or let the system learn and refine them over time. The firewall’s built-in AI provides clear explanations for why certain actions are flagged as risky, along with detailed assessments of potential impact.
An added benefit of this approach strengthens the broader software ecosystem. Software Bills of Materials (SBOMs) are now essential for software sales, especially after being formalized under Biden’s Executive Order 14028 for all software sold to the U.S. federal government. Their primary goal is to improve supply chain transparency by documenting every component in a software product. This standard has since gained global traction and is supported by multiple regulatory frameworks.
However, the quality of many SBOMs remains inconsistent.
“We believe our SBOM tool is the most accurate available,” asserts Pulaski. “We observe the software as it’s being built—not just reviewing manifests or documentation. We verify every open-source library, its origin, and its dependencies. If anything is pulled from or pushed to an unauthorized location, we can block it immediately.”
Through this real-time monitoring, InvisiRisk’s TruSBOM tool generates a complete, precise, and trustworthy SBOM.
Related: Are SBOMs Failing? Supply Chain Attacks Rise as Security Teams Struggle With SBOM Data
Related: New Class of CI/CD Attacks Could Have Led to PyTorch Supply Chain Compromise
Related: Trellix Source Code Repository Breached
Related: CISA, NSA Share Guidance on Securing CI/CD Environments
