By David Pulaski, CXO & Co-founder, InvisiRisk
TL;DR
AppSec tools cover code (SAST), dependencies (SCA), and deployed applications (DAST), but most do not monitor and enforce policy on live build execution, the phase where secrets are available, egress is open, and dependencies execute. Recent attacks involving Axios, TeamPCP, and the Bitwarden CLI npm compromise show how attackers exploit this blind spot. Build-time security fills that gap with inline policy enforcement during CI/CD execution. InvisiRisk’s Build Application Firewall (BAF) is purpose-built for this.
Application security has a gap, and most organizations don’t know it’s there. The tools that scan your code, check your dependencies, and test your running apps are all real and necessary. But most of these tools do not govern what happens during the build, when software is assembled, secrets may be available, and the pipeline often has access to source code, registries, signing keys, and deployment paths.
That gap has a name: build-time security. Until your AppSec model includes it, the SDLC has an unmonitored phase sitting between every tool you already own.
What AppSec Covers Today
Modern application security is a stack of tools mapped to stages of the SDLC.
SAST analyzes source code for vulnerabilities before compilation, insecure patterns, injection risks, logic flaws. Code at rest.
SCA inventories open-source dependencies and flags known CVEs. Manifests and lock files. Also code at rest.
DAST probes running applications by simulating attacks against deployed endpoints. Post-deployment.
Mature programs layer in container scanning, IaC scanning, and source-code secret scanning on top. Together these cover code quality, dependency risk, and deployed-app exposure.
Here’s what the standard model actually looks like:
| SDLC Phase | Tool | What It Sees |
|---|---|---|
| Code / Commit | SAST, secret scanning | Source code, config files |
| Dependency Resolution | SCA | Manifests, lock files, known CVEs |
| Build / CI Execution | Limited native controls | Installed packages and build logs |
| Test / Staging | DAST, IAST | Running application behavior |
| Deploy / Runtime | RASP, WAF, CSPM | Production traffic, cloud posture |
The middle row is the gap.
Why the Build Phase Is the Gap
What the standard AppSec model usually does not see is build-time network behavior: where the build connects, what it sends, and whether secrets or unauthorized commands leave the runner. SAST and SCA analyze what’s written. DAST analyzes what’s deployed. Neither sees what the pipeline does between those two moments.
During a build, CI/CD compiles code, downloads dependencies, executes install scripts, injects secrets into environment variables, signs artifacts, and makes network calls to registries, APIs, and external services. Much of this happens in a privileged execution environment that often has broad network access.
As Tom Hamilton, InvisiRisk’s CTO, puts it: a CI/CD pipeline can look secure on paper and still leak secrets or produce compromised builds in practice. The runner may hold credentials, signing keys, deployment tokens, and other build secrets. In many organizations, CI runners can reach the public internet, but there is limited enforcement over which destinations, payloads, tools, or source-control actions are allowed while the build runs.
Three Attacks That Lived in the Gap
-
- Axios npm compromise (March 2026). A maintainer account for a package with 100M+ weekly downloads was hijacked. The malicious versions could execute a cross-platform RAT at install time in environments that installed the affected packages. No CVE, no code change, no repo modification, one stolen publish account was enough.
-
- TeamPCP (March 2026). TeamPCP abused trusted paths across GitHub Actions, npm, and PyPI to steal credentials from CI runners and propagate downstream. Reported targets included Aqua Security’s Trivy, Checkmarx’s KICS, and BerriAI’s LiteLLM, turning security tools into attack vectors.
-
- Bitwarden CLI npm compromise (April 2026). A compromised Bitwarden engineer’s GitHub account and abuse of npm OIDC Trusted Publishing were used to publish a malicious @bitwarden/cli@2026.4.0 package. The package used a preinstall hook to launch an obfuscated credential stealer when installed, targeting developer secrets, GitHub tokens, Vault secrets, and AI coding assistant configurations.
Each of these attacks exploited behavior that became dangerous only during build-time execution. Static checks alone were not enough because the malicious activity happened when packages, scripts, or workflows ran inside the runner and communicated over the network. (Full catalog of build-time attacks →)
What Build-Time Security Actually Is
Build-time security monitors and enforces policy on what happens during the build, not before (code scanning) and not after (runtime monitoring). It governs the live execution phase: what the build fetches, what it executes, what it transmits, and what it produces.
Where SAST asks “is the code safe?” and DAST asks “is the app safe?”, build-time security asks: is the build doing what it’s supposed to do, and nothing else?
It’s not shift-left and it’s not runtime. Shift-left moves checks earlier into static analysis, valuable, but limited to what’s visible in code at rest. Runtime watches deployed apps, also valuable, but too late if the build itself was compromised. Build-time security occupies the space between them, where dependencies are fetched, scripts run, and secrets are present. It requires inline enforcement during execution, not scanning before or alerting after.
What Goes Wrong in CI/CD
Dependency poisoning. Typosquatting, account hijacking, and dependency confusion get malicious packages into public registries. Hooks such as postinstall and preinstall can execute the moment the build resolves. SCA can flag known-bad versions after the fact, but a net-new compromise typically passes manifest checks.
Credential exfiltration during execution. Runners hold API tokens, cloud credentials, signing keys, and registry auth in environment variables. A compromised step can read those values and exfiltrate them via HTTP POST, git push, DNS, or encoded payloads embedded in otherwise-legitimate API traffic. InvisiRisk’s recent BAF release (v1.1.38) addresses encoded secret interception, including the Base64 and double-Base64 schemes seen in recent campaigns.
Workflow and Action hijacking. Misconfigured GitHub Actions workflows (pull_request_target triggers especially) and mutable Git tags let attackers redirect trusted Action references to attacker-controlled code. The malicious code runs with the runner’s permissions, not the attacker’s.
Encoded leakage that bypasses secret scanners. Source-code secret scanning won’t catch a secret that’s never committed. If a build encodes a token in Base64, splits it across requests, or sends it to an allow-listed destination like GitHub itself, source-level scanners are blind. The leak happens on the network during execution.
What the Model Looks Like With the Gap Filled
| SDLC Phase | Tool | What It Sees |
|---|---|---|
| Code / Commit | SAST, secret scanning | Source code, config files |
| Dependency Resolution | SCA | Manifests, lock files, known CVEs |
| Build / CI Execution | Build Application Firewall | Live network behavior, policy violations, exfiltration attempts |
| Test / Staging | DAST, IAST | Running application behavior |
| Deploy / Runtime | RASP, WAF, CSPM | Production traffic, cloud posture |
Build-time security does not replace existing AppSec tools. It covers the one phase they cannot fully see.
A Build Application Firewall (BAF) sits inline in the pipeline’s network path and enforces policy on live behavior. The principle is simple: define what a build is expected to do, and block the rest.
-
- Allowed registries. Pull from npm, PyPI, your private registry. Calls to unknown registries blocked.
-
- Allowed egress. Push artifacts to your artifact store. POSTing encoded data to a fresh GitHub repo denied.
-
- Allowed tools. Run your defined toolchain. Downloading and executing an unexpected runtime, as seen with Bun in the recent Mini Shai-Hulud attack, triggers a violation.
This is also where compliance pressure is increasing. NIST SP 800-218 (SSDF) requires practices that extend beyond code scanning, and CISA’s secure software attestation requirements push software producers toward stronger evidence of how software is developed and built. Build records, SBOMs, policy decisions, and attestations can help demonstrate that software was assembled in a controlled environment.
How to Start
Audit egress. One question first: can your CI runners reach the public internet while secrets are loaded? If yes, you have an exfiltration path. Map every outbound connection your builds make. Most teams are surprised by the volume.
Define expected behavior, then enforce it. Baseline a healthy build, registries, APIs, artifacts. Anything outside the baseline (a new domain, an unexpected runtime download, a POST to an unrecognized endpoint) should alert or block. Build it yourself, use open source, or deploy a commercial BAF, the principle is the same: something has to watch the build while it runs.
Attest and monitor dependencies. Cryptographic fingerprints of every build. Continuous monitoring of the packages your builds consume, new maintainers, version churn, behavioral changes. Consider a stability buffer: a configurable delay before newly published versions are allowed into builds, so the ecosystem has time to surface bad releases before they hit your runners.
Get Build-Time Security with InvisiRisk
This is the category InvisiRisk operates in. Our Build Application Firewall sits inline in CI/CD pipelines and enforces policy on live network behavior during build execution. It performs deep packet inspection of build traffic, detects and blocks credential exfiltration (including encoded secrets), reconstructs a complete SBOM (TruSBOM™), and generates attestation evidence for compliance. It works with GitHub Actions, GitLab, Jenkins, Azure DevOps, and more.
It doesn’t replace your scanners. It covers the phase they can’t see.
See what your scanners are missing. Get started today →
