Who is accountable when a build token is used to publish malicious artefacts?

Why This Matters for Security Teams

When a build token is used to publish malicious artefacts, the issue is not simply a compromised credential. It is a failure of trust design across the software delivery chain. Build tokens often carry enough authority to sign, upload, or deploy code, which means a single misuse can move malicious content into release systems, artifact registries, or downstream environments. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that accountability depends on access control, audit logging, and system configuration, not just on whether a token was technically valid at the time of use.

Security teams often assume the blame belongs to the person who abused the token, but the operational reality is broader. If a token can publish artefacts without strong scoping, expiry, approval, or anomaly detection, then the organisation has accepted that risk into the pipeline. That creates governance, engineering, and monitoring obligations that cannot be shifted to a vendor or reduced to a single policy exception. In practice, many teams encounter this only after malicious code has already been distributed, rather than through intentional control testing.

How It Works in Practice

In modern CI/CD and supply chain environments, build tokens are usually issued to automated jobs, signing services, release workflows, or ephemeral agents. Their authority should be tightly limited to the narrowest set of actions required for the pipeline stage. If a token can do more than the build step needs, it becomes a standing pathway for abuse. That is why accountable ownership normally spans platform engineering, security operations, and IAM, with clear approval for who can mint, rotate, scope, and revoke tokens.

Operationally, strong control design usually includes the following:

• Short-lived credentials with audience and environment restrictions.
• Separate identities for build, test, signing, and publish stages.
• Immutable logs for token issuance, use, and artefact publication.
• Artifact signing and provenance checks before release promotion.
• Monitoring for unusual publish volume, out-of-band destinations, or policy bypass.

That control set aligns well with software supply chain guidance from NIST Software Supply Chain Security and Integrity and with detection practices that correlate build-system activity to downstream release events. Where agentic automation is involved, current guidance suggests treating the agent or workflow as an identity-bearing actor with constrained authority, not as a trusted administrator. That is especially important when a build token can trigger deployment, sign packages, or publish to a public registry. These controls tend to break down in highly parallel CI environments with reused runners and shared secrets because attribution and token containment become difficult to prove.

Common Variations and Edge Cases

Tighter token scoping often increases operational overhead, requiring organisations to balance release velocity against blast-radius reduction. That tradeoff becomes more visible when legacy pipelines, monorepos, or multi-tenant runners are in use. In those environments, teams may keep broad tokens for convenience, but that is a risk decision, not a control inevitability.

There is no universal standard for every pipeline pattern yet, especially where self-hosted runners, external build farms, or third-party publishing services are involved. Some teams split accountability between the application owner and the platform team, while others place primary responsibility with the system owner who can actually enforce token policy. The practical test is whether the organisation can demonstrate who approved the token scope, who monitored its use, and who could revoke it quickly if suspicious publishing occurred.

Where malicious artefacts are involved, post-incident review should also check whether the token was reused across environments, whether secrets were exposed in logs, and whether provenance validation failed to stop untrusted output. That is the point at which identity governance intersects with NHI control design: the build token is a non-human identity with delegated privilege, and it must be governed like one.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised package credential is used to spread malicious artefacts?
• Who is accountable when stolen software supply chain credentials are used to publish malicious code?
• What breaks when a stolen GitHub token is used to seed malicious repository configuration?
• Who is accountable when a former employee account or stolen token is used in a breach?