Introduction to Build Application Firewalls
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 to prevent these types of attacks. The SolarWinds supply chain attack of 2020, resulting in around 18,000 affected organizations, should have been a learning point.
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.
Supply Chain Attacks
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.
Bad Code in CI/CD
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, and the presence of an unknown zero day that simply isn’t detected.
Solution: Build Application Firewall
David Pulaski, co-founder at InvisiRisk, comments, “If we don’t know there’s a vulnerability, we just let the package in. 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.
How BAF Works
The firewall’s deep packet inspection 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.
SBOMs and BAF
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.
Pulaski claims, “We believe our SBOM tool is the finest SBOM tool there is. 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. This will help to reduce supply chain issues and ensure the security of software applications.
Source: SecurityWeek