Why do build systems make supply-chain attacks worse?

Build systems amplify attacker reach because they routinely hold credentials, sign artefacts, and push code across trusted repositories. Once a malicious package lands in that environment, it can spread through ordinary build steps and inherited permissions. The problem is not just initial infection, but the reuse of trusted automation to propagate it.

Why This Matters for Security Teams

Build systems are not just compilers and test runners. They are high-trust automation layers that often hold signing keys, deployment tokens, repository write access, and secrets for internal services. That makes them an ideal propagation point for supply-chain attacks: once a malicious dependency, plugin, or pipeline step is trusted, the build can turn a single foothold into broad compromise. NHIMG’s 52 NHI Breaches Analysis shows how compromised machine identities and automation credentials repeatedly expand attacker reach across environments. For a broader view of secret exposure patterns, see the The State of Secrets in AppSec research.

The risk is not limited to source code tampering. Build infrastructure can sign artefacts, publish packages, inject environment variables, and mirror changes into downstream repositories. Once that trust is abused, defenders often discover the issue after artefacts have already been distributed. Guidance from the OWASP Non-Human Identity Top 10 is especially relevant here because build systems rely on non-human identities that are rarely governed as tightly as human accounts. In practice, many security teams encounter build-system abuse only after malicious artefacts have already been released, rather than through intentional control testing.

How It Works in Practice

Build systems worsen supply-chain attacks because they compress trust, privilege, and automation into a single execution path. A build agent may fetch dependencies, resolve packages, run scripts, sign outputs, and publish to multiple targets. If an attacker compromises any step in that chain, the build process can amplify the malicious change without requiring the attacker to manually move through each downstream system.

The practical control problem is identity and authorization, not just malware scanning. The build workload should have narrowly scoped, short-lived credentials, preferably issued per task and revoked when the job ends. Current guidance suggests treating build runners as workload identities rather than static service accounts, with policy evaluated at request time instead of relying on long-lived role assignments. That aligns with emerging practice in the OWASP NHI Top 10 and the Anthropic report on AI-orchestrated cyber espionage, both of which reinforce that automated actors can chain actions faster than traditional detective controls can respond.

• Use ephemeral credentials for each pipeline run, not shared build secrets.
• Separate signing, packaging, and publishing into distinct identities and trust boundaries.
• Restrict outbound network access so a compromised build cannot fetch arbitrary payloads or exfiltrate tokens.
• Require provenance, reproducible builds, and artefact attestation before release.
• Monitor for secret access, unexpected dependency changes, and unusual publish activity.

For implementation detail, the Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack show how trusted automation can be used to spread secrets exposure and compromise at scale. These controls tend to break down in monolithic CI/CD environments where one runner identity can both build and publish, because a single credential then becomes a transitive trust key for the entire release chain.

Common Variations and Edge Cases

Tighter pipeline isolation often increases build latency and operational overhead, so organisations must balance release speed against blast-radius reduction. There is no universal standard for this yet, but current best practice is to separate duties as much as the platform allows and to reserve standing privilege only for the narrowest possible control plane functions.

Some environments are harder to harden than others. Self-hosted runners, containerised builds with privileged Docker access, and legacy release jobs that rely on long-lived repository tokens all create conditions where compromise spreads quickly. In those cases, simply rotating secrets is not enough if the same identity can still sign, publish, and modify pipeline definitions. The LiteLLM PyPI package breach and Shai Hulud npm malware campaign illustrate how fast this can move once a trusted package path is abused.

For teams evaluating control maturity, the most useful question is whether the build system can be safely assumed breached without granting it the power to distribute compromise. If the answer is no, the architecture still depends on static trust. The Ultimate Guide to NHIs frames this as a non-human identity governance issue, but the operational fix is a build design that limits who can publish, what can be signed, and how long any credential can survive.

Related resources from NHI Mgmt Group

• Why do cloud and NHI secrets make supply chain attacks more dangerous?
• Why do stolen publishing credentials make supply chain attacks worse?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do non-human identities make supply chain attacks harder to contain?