What Is Build-Time Security for CI/CD Pipelines?

By David Pulaski, COO, InvisiRisk

TL;DR

A CI/CD pipeline is privileged, networked, and often executes third-party packages, scripts, actions, containers, or build tools as software is assembled. Traditional AppSec tools such as SAST, SCA, and DAST help secure source code, dependencies, and deployed applications, but they do not fully monitor or control what happens while the build itself is running. That’s the gap recent supply chain attacks exploit. Build-time security closes that gap with inline policy enforcement over approved registries, egress, tooling, and outbound behavior, including encoded credential exfiltration. It complements existing scanners by protecting the highest-risk phase of software delivery: when source code, secrets, dependencies, and release artifacts all converge inside the pipeline.

Claim boundaries: The InvisiRisk claims below are limited to build-time enforcement inside CI/CD pipelines. InvisiRisk does not replace SCA, SAST, or DAST. It enforces policy on network and API behavior during the build itself.

A modern CI/CD pipeline is one of the most powerful pieces of automation most engineering organizations own. It pulls code, fetches dependencies, runs tests, signs or packages artifacts, and may push software toward production hundreds of times a day. It’s also one of the most privileged automation paths in the organization, with access to source code, registry tokens, cloud credentials, signing keys, deployment systems, and other build secrets.

Build-time security is the practice of changing that. It’s the layer of CI/CD security that monitors and enforces policy on what the pipeline actually executes, not what’s in the source code, not what’s in the deployed app, but what happens in the live build itself.

Understanding build-time security starts with the pipeline itself: what runs inside it, why attackers target it, and how a Build Application Firewall (BAF) can protect the live execution phase that traditional tools often miss.

What Happens in a Typical CI/CD Pipeline

A CI/CD pipeline is a sequence of automated steps that turns a commit into a deployed artifact. The exact stages vary by toolchain, GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps, but the shape is consistent.

A typical run looks something like this:

Trigger. A developer pushes a commit, opens a pull request, or merges to main. The CI/CD system spins up a runner, a virtual machine or container that will execute the build.
Checkout. The runner clones the repository and checks out the commit being built.
Dependency resolution. The build reads package.json, requirements.txt, pom.xml, or whatever manifest applies, and downloads every declared dependency from public or private registries. Many of those dependencies have install scripts that execute automatically.
Compilation and test. Code is compiled. Tests run. Coverage reports are generated.
Artifact creation. The build produces a binary, container image, or package, often signed with a key the runner can access.
Push and deploy. The artifact is uploaded to a registry or artifact store, and downstream automation deploys it.

Every step in that sequence runs inside the runner. Every step has access to whatever secrets the runner was configured with. And every step can make outbound network calls.

Why the Build Environment Is a Critical Security Control Point

Three properties of the build environment combine to make it uniquely sensitive.

It’s privileged. A runner mid-build typically holds cloud credentials, package registry tokens, GitHub or GitLab access tokens, and code-signing keys, often all at once. In many environments, code running inside the pipeline can inherit powerful permissions from the runner.

It’s networked. Builds need the internet. They pull from npm, PyPI, Docker Hub, GitHub. They call APIs to post status updates, send notifications, upload artifacts, and report metrics. Many CI runners are configured with broad outbound access, which can allow processes inside the build to reach public internet destinations unless egress is restricted.

It’s executing untrusted-by-default code. Every dependency, package script, action, container, plugin, or build tool introduced into the build becomes part of the execution environment. When any of that code runs, it can inherit the permissions and network access available to the runner. A typical Node.js project has thousands of transitive dependencies. A typical Python project, hundreds. Each one is a potential entry point.

Put those three together and the build environment becomes the highest-leverage point in the entire SDLC. Compromise the build, and you compromise everything downstream, every artifact, every deployment, every customer install. This is why “supply chain attack” has become a category: the attackers figured out that the build is where the leverage lives.

Common Security Risks During Software Builds

A handful of attack patterns appear again and again in CI/CD and software supply chain breaches.

Malicious packages and dependency confusion. An attacker publishes or compromises a package through typo-squatting, account hijacking, or namespace confusion, then waits for builds to pull it in. In ecosystems that support install hooks, a preinstall or postinstall script can execute as soon as the package is installed, inheriting the permissions available to the runner. Example: The Mini Shai-Hulud campaign in April 2026 followed this pattern, weaponizing SAP-related npm packages with preinstall hooks that downloaded and executed an obfuscated credential stealer the moment a build ran npm install.

Credential theft from runners. Once malicious code executes inside the runner, it may be able to access the same secrets, tokens, metadata services, and credential files available to the build. Stolen credentials can be exfiltrated over HTTP, DNS, or git operations, sometimes disguised as ordinary traffi\o trusted destinations such as GitHub. Example: The April 2026 xinference PyPI compromise injected a two-stage credential collector designed to harvest cloud keys, Kubernetes tokens, and package publishing tokens, then exfiltrated them through outbound HTTP requests.

Workflow and Action hijacking. GitHub Actions and similar systems often let workflows reference third-party Actions by tag instead of by immutable commit SHA. Because tags can be moved, a compromised maintainer account or repository can turn a trusted Action into a delivery mechanism for malicious code in future builds. Misconfigured triggers such as pull_request_target can make this worse by exposing elevated permissions or secrets to code paths that originated outside the trusted repository. Example: The tj-actions/changed-files attack showed how a compromised GitHub Action could expose credentials from GitHub Actions workflows.

Build script tampering. Build configuration files (Makefile, .github/workflows/, Jenkinsfile) are code, but they’re rarely reviewed with the same rigor as application code. A subtle change, such as a curl | bash line, an extra registry, or an inverted security check, can introduce a backdoor that an application-focused code review may miss.

Encoded data exfiltration. When source-code secret scanners run, they look at committed files. They don’t see what the build POSTs to a remote endpoint at execution time. Secrets can be Base64-encoded into JSON payloads, split across multiple requests, or embedded in DNS queries. Static scanners may miss this because the leak happens on the wire during execution, not in committed source code. InvisiRisk’s BAF release v1.1.38 addresses this pattern by detecting and blocking encoded credential exfiltration, including Base64 and double-Base64 schemes observed in recent campaigns.

For the full catalog of build-time attacks, see InvisiRisk Build & CI/CD Security Alerts →

Why Traditional Security Tools Lack Build-Time Visibility

The standard AppSec toolchain, SAST, SCA, DAST, is built around code at rest and applications at runtime. Those tools were not primarily designed to monitor and control live build execution.

SAST (Static Application Security Testing) parses source code looking for insecure patterns: SQL injection risks, hardcoded credentials, unsafe deserialization. It runs against files, not running processes. If the malicious code arrives during the build via a hijacked dependency, SAST never sees it.

SCA (Software Composition Analysis) is excellent at identifying known vulnerable packages and policy violations in dependency manifests and lockfiles. Some tools can also flag package reputation, provenance, or other risk indicators before a build runs. But SCA generally does not enforce what a package does once its install script, build script, or dependency code executes inside the runner.

DAST (Dynamic Application Security Testing) probes deployed applications by simulating attacks against live endpoints. By the time DAST sees an application, the build is over and the artifact has shipped. If the build was compromised, DAST is testing the attacker’s deployment.

The pattern is consistent: every traditional tool either looks at code (which doesn’t move) or applications (which run after the build is done). The build itself, privileged, networked, executing, has no native observer. That’s the visibility gap, and it’s exactly where modern attackers concentrate.

The Role of a Build Application Firewall (BAF) in CI/CD Security

A Build Application Firewall is purpose-built for the gap. It sits inline in the pipeline’s network path and enforces policy on live build behavior in real time.

The model is straightforward: define what a build is expected to do, and block anything else.

Approved registries only. A Java build can fetch from Maven Central and your internal Artifactory. A connection to a registry no one’s heard of gets dropped.
Approved egress destinations. Builds can push artifacts to your artifact store and report status to your CI provider. They cannot POST encoded payloads to a freshly created GitHub repo or a domain that didn’t exist 24 hours ago.
Approved tooling. A Node build runs Node, npm, and the toolchain you’ve defined. Pulling down an unrelated runtime mid-build (the Bun-runtime trick from Mini Shai-Hulud) trips a violation.
No silent secret leakage. Encoded credentials being smuggled out, Base64, hex, double-Base64 encoded, embedded in legitimate-looking API calls, get recognized and blocked before they leave the runner.

A BAF doesn’t compete with SAST, SCA, or DAST. It sits in a different phase of the SDLC and answers a question those tools can’t ask: is this build doing what it’s supposed to be doing right now, or is something else happening?

It also produces a side benefit that matters for compliance. Because a BAF observes everything the build actually does, it can generate audit-ready build evidence covering inputs, outputs, policy decisions, and runtime behavior, the evidence backbone for NIST SP 800-218 (SSDF) and CISA’s secure software attestation requirements.

Protect the Final Stage of Software Delivery with Build-Time Enforcement

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.

Build-time security isn’t a replacement for the AppSec tools you already run. It’s the layer those tools were never designed to cover.

The build is where source code becomes shippable software. It’s the last point in the SDLC where you can stop a compromise before it leaves the building. Once the artifact is signed and pushed, the impact moves downstream to customers, auditors, and incident response teams. Stopping a compromise during the build is usually the fastest, least expensive, and least disruptive place to stop it.

The principle here is more important than any specific product: something has to watch the build while it runs. Whether that’s a commercial Build Application Firewall, an open-source equivalent, or tooling you build in-house, the alternative, running thousands of builds a week with no observer on the live execution phase, is the gap modern supply chain attackers count on.

FAQs