How can a build produce a backdoored artifact when every source file is clean?

## The repository is not the artifact Almost every control an engineering organisation is proud of operates on **inputs**: pull-request review, required approvals, protected branches, signed commits, a green check on the PR. All of them answer the question "is the source we intend to build acceptable?" None of them answers "does the thing we published correspond to that source?" Build-time injection is the attack that lives in that gap. The attacker does not modify a source file, because modifying a source file is the one thing your process is built to catch. Instead they arrange for something that runs *during* the build to change what comes out. ## What actually runs during a build A build is not a pure function of the repository. It is a program - usually a long one - executing on a machine with write access to the output. The places code can enter without touching application source include: - **The build configuration itself** - build scripts are code, and a build script can rewrite files, download something and execute it, or swap an output. - **Build plugins and their transitive dependencies.** A plugin is code you run at full privilege on your own source tree. Its own dependency graph is usually nobody's job to review. - **Post-compilation steps** - annotation processors, bytecode rewriters, obfuscators, shading and relocation, minifiers, resource packers. These exist to modify compiled output; that is their normal function, which is what makes a malicious one so easy to hide. - **Build-time-only dependencies** - code generators, linters that run in-process, test infrastructure that shares the build JVM or interpreter. - **The environment** - the base image or runner the build executes on, the language toolchain installed on it, an interpreter or agent injected via an environment variable, a pre-existing file in the workspace. - **The packaging and publishing step**, which handles the finished bytes last and is often the least-reviewed part of the pipeline. A concrete shape: a build plugin in a payments SDK's build rewrites compiled classes after compilation, so the published library contains a call to an attacker-controlled endpoint. That call exists in no source file and in no reviewed diff. Every consumer that embeds the SDK now handles card data next to attacker code, and the source repository they could inspect is genuinely clean. ## Why the usual signals stay green - **Tests pass**, because tests exercise code built by the same compromised build, and because the payload is typically dormant - gated on the environment, a date, or a target it is looking for. - **The diff is small and correct**, because the attacker did not author it. - **Static analysis on the source finds nothing**, because the source is not where the code is. - **A signature verifies**, because the signing step is at the *end* of the build. Signing after injection produces a validly signed backdoored artifact. A signature says who vouches for these bytes and that nobody altered them afterwards; it never says the bytes correspond to any particular source. - **A component inventory can also look clean.** An inventory answers what is *inside* the artifact; injected code that adds no new component simply does not show up as an entry. ## The direction that matters Keep the three claims straight, because mixing them up is the canonical wrong answer in this area. An inventory of contents tells you *what is inside*. A signature tells you *who vouches for it*. Neither tells you *how it came to be* - and build-time injection is entirely a question of how it came to be. That is why the countermeasures for this class are about the build rather than about the code, and why "we reviewed the repository" is never a complete answer to "is this release safe?". ## What this changes in practice When you suspect it, you work from the artifact backwards, not from the repository forwards: get the published bytes and their digest, build the declared source yourself somewhere you control, and compare - even a coarse comparison of what classes or symbols exist localises the injection. Then enumerate everything the release build was permitted to execute and check what changed between the last release you trust and this one. And treat the build machine as compromised: every credential it could read is burned, so rebuilding and republishing from the same machinery is not a fix.