Who is accountable when a CI/CD token is used to publish poisoned packages?

Why Accountability Rests with the Identity Owners, Not the Malware

When a CI/CD token is used to publish poisoned packages, the security failure is usually not the publishing event itself. It is the fact that a privileged build or package-publish identity existed, remained usable, and was trusted to act without enough lifecycle control. That makes accountability land with the teams that own the pipeline identity, token scope, rotation, revocation, and monitoring. NIST’s Security and Privacy Controls framework treats access governance as an operational control, not a one-time configuration choice.

This is especially visible in supply chain incidents, where attackers often do not need to “hack” the package ecosystem at all. They only need one weak publishing path, as seen in NHIMG’s CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack. In practice, many security teams encounter blame assignment only after poisoned artifacts have already been distributed, rather than through intentional identity ownership reviews.

How Accountability Should Be Operationalised in the Pipeline

Accountability becomes workable when each publish-capable identity has a named owner, a clearly defined purpose, and a measurable lifecycle. The owner is not just the team that created the token. It is the team responsible for proving the token is scoped correctly, rotated on schedule, revoked when no longer needed, and monitored for abnormal publish activity. That is the practical control boundary for CI/CD publish rights.

Current guidance suggests treating package publishing as privileged access. That means:

• Assign one accountable owner per build or release identity.
• Use narrow token scope, not broad repository or organisation-wide permissions.
• Prefer short-lived credentials over static secrets embedded in pipelines.
• Log every publish action with identity, build provenance, and artifact hash.
• Require revocation playbooks for compromised runners, leaked tokens, or offboarding.

This is consistent with what NHIMG reports in the Guide to the Secret Sprawl Challenge, where secrets spread across repositories, tickets, and collaboration tools, and with vendor research showing that valid leaked secrets often remain exploitable long after exposure. NIST’s control language also reinforces that access must be reviewed, enforced, and removed as conditions change. In other words, accountability is operational, not ceremonial.

For teams using package registries, build runners, or release automation, the right question is not only “who used the token?” but “who was responsible for ensuring that token could not be abused?” That is why build-system owners, release-engineering owners, and platform security owners must share a formal control model, even when the actual compromise began outside their boundary. These controls tend to break down when self-hosted runners, shared service accounts, and long-lived publish tokens are combined in high-change release environments because attribution and revocation become too slow to match attacker speed.

Where the Standard Answer Breaks Down in Real Environments

Tighter publish controls often increase release friction, requiring organisations to balance deployment speed against blast-radius reduction. That tradeoff is real, especially in monorepos, high-frequency release pipelines, and open-source ecosystems where many maintainers can legitimately publish. Current guidance suggests that accountability should still stay with the identity owner, but the implementation may vary.

Edge cases include outsourced release engineering, shared vendor-maintained runners, and cross-team package stewardship. In those environments, ownership can be split, but it cannot be vague. One team must own the token, another may own the pipeline, and a third may own the registry policy, but the accountable entity for each control must be explicit. NHIMG’s State of Secrets Sprawl 2026 and the 2025 State of NHIs and Secrets in Cybersecurity both show why this matters: secrets remain exposed, duplicated, and overused far too often.

There is no universal standard for this yet, but the emerging best practice is to make publish rights a governed NHI responsibility with named owners, short-lived credentials, and clear incident escalation paths. When poisoned packages are published, accountability should be traceable before the next release cycle, not reconstructed after the compromise has spread.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised publish token is used to tamper with packages?
• Who is accountable when CI identities are abused to publish malicious packages
• Who is accountable when a build token is used to publish malicious artefacts?
• What breaks when a CI/CD workflow can publish packages and access secrets at the same time?