A build-only plugin has a critical finding but never ships in your artifact - why still rate it high?

### Two runtimes, not one A project has at least two execution environments, and dependency scope is largely a statement about which one a package belongs to: - **The deployed artifact** - runs in production, faces whatever traffic your service faces, holds the production data and secrets. - **The build machine** - runs plugins, annotation processors, code generators, test frameworks and every script the build invokes. It holds a checkout of the source, network access, package-manager credentials, often a cloud role used to deploy, and sometimes signing material. 'It never ships' is a true and useful statement about the first environment only. It says nothing about the second, and the second is the one a compromised dependency in build scope actually lands in. ### What a build-scope compromise gets Work the scenario concretely. A settlement service builds with a plugin and an annotation processor; the build runs on a runner whose identity can push images and deploy. Malicious code inside a build-scope dependency, executing during the build, can: - read or exfiltrate the runner's credentials - the deploy role, registry tokens, any secret injected into the build environment; - read the source tree, including anything checked in that should not be; - modify the artifact after compilation, so what is published is not what the source says - and if the publish step signs, the modified artifact gets a valid signature; - persist into caches or generated code so the effect survives the run. The consequence is not 'a vulnerable library in production'. It is a compromised identity and, worse, an artifact that downstream consumers verify successfully and trust, because every control after the build attests to a thing that was already tampered with. That is why 'not shipped' does not translate to 'low'. ### Rate by environment and identity, not by packaging A usable triage rule: 1. Classify by execution environment: deployed artifact, build machine, developer workstation. 2. For each environment, ask what an attacker who achieves code execution *there* gets. For the build machine that is the runner's identity and the output artifact. 3. Rate the finding against that, not against a base severity score computed for a generic deployment. A base score is deliberately environment-agnostic; it cannot know that this runner holds a production deploy role. Under that rule, a build-scope finding that permits code execution during a build on a runner with broad standing credentials is a high rating. The same finding on a runner with a short-lived, narrowly scoped identity, in an environment where the artifact is verified afterwards, is genuinely lower - and that downgrade is defensible because it is an argument about the environment rather than about packaging. ### The code-generation trap There is a second reason build scope resists the 'never ships' argument: some build-scope tools *produce what ships*. An annotation processor, a code generator, a bundler or a minifier is not in the artifact, but its output is. A compromised generator that emits one extra line into generated code has put itself into production without ever appearing in the dependency list of the deployed artifact. Any inventory built by reading the deployed artifact's dependencies will show it as absent, correctly and uselessly. Reviewing generated output, and comparing builds, is what catches that class - not the dependency list. ### The same logic reaches test scope Test-scope packages do not ship either, and they also execute on the build machine, frequently with the same credentials in the environment. So the environment-based rating applies to them too. The distinction between test and build scope matters for what is packaged; it does not create a boundary in what executes during CI. ### What good sounds like in the room A strong answer separates the two claims cleanly: *the finding is not exploitable by a production attacker, because the component is not in the artifact; it is exploitable by anything that can influence what the build resolves, and I rate it by what the build identity can do.* Then it names the consequence for controls: the question stops being 'when do we patch and redeploy' and becomes 'what does the build identity hold, how long do those credentials live, and can we tell whether what we published matches what we built'. A weak answer sorts build scope to the bottom of the queue and moves on, which is exactly the reasoning an attacker choosing where to hide is counting on.