Many of the most serious supply chain issues are caused by flaws built into applications during the CI/CD build process. A build application firewall may be the solution.
The SolarWinds supply chain attack of 2020, resulting in around 18,000 affected organizations, should have been a learning point. It demonstrated a key style of supply chain attack – but we didn’t learn how to prevent them. The same approach of compromising the development cycle of a widely used tool has been successfully repeated many times since then.
In March 2026, North Korean actors hijacked an Axios npm library maintainer’s account and published two malicious versions. Axios is widely trusted and usage is usually automated. During the brief period before the malicious versions were removed, it is believed they were downloaded by around 3% of the Axios userbase. The endgame was a remote access trojan, ultimately delivered via CI/CD.
Separately, but also in February/March 2026, TeamPCP compromised Aqua’s Trivy vulnerability scanner, BerriAI’s LiteLLM, and Checkmarx/kics. The successful purpose was to get into the CI/CD of widely used tools. On March 31, Mercor announced itself to be ‘one of thousands of companies impacted by a supply chain attack involving LiteLLM’. In early April, the European Commission lost 300Gb of data to hackers using an API key compromised in the Trivy supply chain attack.
The problem is bad code being introduced into the CI/CD application build process. This could be invisible to the developer. Most build systems pull in npm or PyPI automatically from the repository. But a compromised package, a typo squatted dependency, or a malicious version will still get included in the build.
Scanners are designed to check what goes into CI/CD, and again at the end of the build. They can often detect problematic code, but sometimes they cannot. There are two primary reasons: the bad intent may not appear to be bad (for example, a post to GitHub when GitHub is not considered a dangerous destination since it is the source of many npm packages), and the presence of an unknown zero day that simply isn’t detected.
The latter could be called the ‘Mythos effect’. The power of contemporary AI frontier models is likely to unearth a multitude of vulnerabilities that can be inserted into the build, and then help bad actors generate stealthy exploits to use against the built application. Standard CI/CD scanners are unlikely to find these, nor highlight the unrequired distribution of secrets to a usually acceptable IP address. This type of supply chain attack will only increase.
“If we don’t know there’s a vulnerability, we just let the package in,” comments David Pulaski, co-founder at InvisiRisk. “The scanner is like a doorman letting someone in because their invitation looks good. But once inside, that vulnerability does something malicious – like post a secret to a bad location or post a secret it shouldn’t post to a good location. Once the vulnerability gets inside, it goes to work fulfilling its malicious purpose.”
Pulaski’s solution is not to scan but to inspect each and every package that enters the build process. InvisiRisk has developed a firewall for the CI/CD process: a BAF or build application firewall. “The guest the doorman lets in might walk out with our jewels. But we’re watching inside the build, and we can see what is happening.”
Hardened runners are commonly used to prevent bad stuff getting into the build and secrets being sent to malicious destinations, but they can only see DNS. “They don’t do deep packet inspection like a real firewall,” says Pulaski. “So, if you’re stealing jewelry and you’re taking it right back to GitHub, it’ll say, yeah, go ahead and take it.” The firewall’s deep packet inspection, however, will see the jewels being stolen, and will understand exactly where they are being sent.
Similarly, it doesn’t need to know a vulnerability to detect its presence – it will detect any activity that is not precisely what is expected.
InvisiRisk’s BAF is designed to enforce policy during the build rather than just scan the content or finished build. That policy can be defined by the user with the help of a wizard, or it can be developed over time by using the firewall. It will make suggestions on what it considers to be risky actions. The firewall’s own AI will explain in detail why it considers an action worrisome, and the potential risk from it.
An added bonus from this BAF will help the entire software ecosphere. SBOMs are mandatory for successful software sales. The requirement has long been apparent, but Biden’s EO 14028 formalized it as necessary for all software sold into the federal government. A major purpose of this has always been to reduce supply chain issues by understanding exactly what is included in a software application. The formal SBOM idea spread globally and is now supported by several regulations.
But the quality of SBOMs can leave much to be desired.
“We believe our SBOM tool is the finest SBOM tool there is,” claims Pulaski. “We watch the software being built. We’re not looking at lists and manifests and other documents to see what’s in the software, we see and check everything ourselves. So, if there is an open source library in your code, we know exactly what it is and where it came from. We know the provenance and dependencies of everything. If anything is pulled or pushed somewhere it shouldn’t be pulled or pushed from, we can stop it.”
From this process, the InvisiRisk TruSBOM tool will build a 100% full and accurate 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
