Who is accountable when CI identities are abused to publish malicious packages

Accountability sits with the teams that own workflow design, package release permissions, and identity governance for automation. In practice, that means engineering, platform security, and IAM must share control over who can publish, what can run, and which tokens can be minted. Frameworks such as NIST CSF and OWASP-NHI help structure that ownership.

Why This Matters for Security Teams

When CI identities are abused to publish malicious packages, the failure is rarely just “a compromised token.” It is usually a governance gap across build automation, release approvals, and secret issuance. Package registries trust CI systems by design, so a stolen pipeline credential can turn a routine build into a supply chain intrusion. NHI Management Group has documented how often organisations miss this class of risk, including the fact that 96% store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools in the Ultimate Guide to NHIs.

This is why accountability cannot stop at the developer who merged a change or the operator who ran a job. Security teams need clear ownership for workflow design, token minting, package publishing rights, and revocation paths. NIST controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls are useful because they force the question of who is authorized, who reviews, and who can stop a bad release. In practice, many security teams discover this only after a malicious package has already been published, not through a deliberate control review.

How It Works in Practice

Accountability for abused CI identities should be split across the people who can actually prevent, detect, and revoke misuse. Engineering owns the pipeline logic and release process. Platform security defines guardrails for runners, signing, and secrets handling. IAM governs which identities can mint tokens, assume roles, or publish to registries. That division matters because CI identities are not static human users; they are workload identities with task-scoped authority.

In practice, the strongest pattern is short-lived, purpose-bound access. A pipeline should receive only the minimum token needed for a single build or release, and that token should expire quickly after use. Static publishing credentials, shared service accounts, and broad registry permissions make abuse much easier. Current guidance from NHI and supply chain security research suggests combining policy-as-code, tight release approvals, and provenance checks with workload identity standards such as OIDC-based federation rather than long-lived secrets. Relevant incident patterns are visible in the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign, where compromised automation and exposed secrets became distribution channels.

• Use separate identities for build, test, and publish stages.
• Issue JIT credentials for release actions, not reusable long-lived tokens.
• Require signed provenance and enforce registry-side policy before publication.
• Log who approved, what pipeline ran, and which identity minted the publish token.
• Revoke access immediately when CI behavior deviates from expected release paths.

These controls tend to break down in highly federated CI/CD environments where multiple teams share runners, registry permissions, and secret stores because attribution and revocation become too fragmented to act on quickly.

Common Variations and Edge Cases

Tighter release controls often increase operational friction, so organisations have to balance speed against the risk of automated abuse. That tradeoff is real in monorepos, ephemeral runner fleets, and multi-tenant build systems where one identity may support many products. Best practice is evolving, but there is no universal standard yet for how much autonomy a CI identity should have before it becomes a governance problem.

Edge cases usually appear when the “publisher” is not a person at all, but a chain of tools. For example, a bot may open a release, a workflow may generate a package, and a separate signing service may push it to a registry. In that model, accountability still stays with the owning teams, but the control evidence must show each handoff. Organisations also need to treat package signing keys, registry tokens, and GitHub or GitLab automation credentials as distinct assets, not one shared trust boundary. The JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions show how quickly toolchain trust can be inverted when credentials are embedded where automation can reach them.

Where teams rely on inherited permissions from cloud roles or broad “release admin” groups, current guidance suggests breaking those privileges apart and tying them to explicit workflow states. That keeps the accountable owner visible even when the system is highly automated.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• How should teams reduce the risk of exposed AI credentials being abused?