Who is accountable when a compromised package publishes additional trojanized versions?

Why This Matters for Security Teams

When a compromised package begins publishing additional trojanized versions, the incident is no longer limited to source code integrity. It becomes an NHI governance problem because the maintainer identity, release credentials, CI/CD tokens, and registry publish rights are all part of the attack surface. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why publish-path abuse is often discovered late.

The practical accountability question is important because package ecosystems reward automation and speed, but attackers exploit exactly those same controls when secrets are reused or release rights are too broad. The issue is not just who pushed the malicious version. It is who owned the credentials, who approved the release path, and who failed to constrain the automation that could republish at scale. The same pattern shows up in the 52 NHI Breaches Analysis, where identity and lifecycle failures turn a single compromise into repeated downstream exposure. In practice, many security teams encounter accountability confusion only after a package has already been mirrored, pinned, or deployed into multiple environments.

How It Works in Practice

Accountability should be assigned across the full publish chain, not to a single individual. The maintainer identity owns code changes and release intent, the automation owner governs how builds are signed and published, and the platform or IAM team controls the secrets and permissions that make publication possible. For modern supply chains, current guidance suggests using separate identities for code authoring, build execution, and release publication so that compromise in one stage does not automatically grant control of the others.

In practice, the strongest control is to narrow publish rights to short-lived, scoped credentials and to bind them to workload identity rather than a human-owned token. Standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls support least privilege, separation of duties, and auditability, while the operational lesson from the LiteLLM PyPI package breach is that exposed secrets can turn a normal release channel into a distribution mechanism for malware.

• Use distinct identities for maintainer activity, CI/CD execution, and registry publishing.
• Issue JIT tokens for each release job and revoke them immediately after publication.
• Require signed builds and verify provenance before any package reaches the registry.
• Log who approved the release, which automation ran it, and which secrets were used.
• Review publish permissions separately from code commit permissions.

This guidance tends to break down in legacy release pipelines where long-lived tokens are shared across teams, because the same credential can both build and publish without any meaningful separation of duties.

Common Variations and Edge Cases

Tighter publish control often increases release overhead, requiring organisations to balance deployment speed against assurance. That tradeoff is real, especially for open-source maintainers, small platform teams, and multi-maintainer projects where emergency fixes must move quickly. Best practice is evolving, but accountability should still follow control ownership: if a maintainer key is stolen, the maintainer process is implicated; if a CI token is abused, the release automation owner is accountable; if registry permissions were too broad, the IAM or platform team shares responsibility.

There are also edge cases where responsibility is shared across organisations. Third-party build services, delegated publishing, and package mirror automation can obscure who actually triggered publication. In those cases, incident handling should map every credential to a named owner and every automation path to a control owner, then compare that map against what actually happened at publish time. The broader NHI security lesson from the Ultimate Guide to NHIs — Why NHI Security Matters Now is that reusable machine identities create durable blast radius unless they are bounded by lifecycle controls.

There is no universal standard for this yet across ecosystems, but the decision should always favour the party that controlled the credential, the release path, and the publish right at the moment of compromise.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised build identity poisons downstream software?
• What actions should I take if my OAuth tokens are compromised?
• How should teams reduce risk from malicious npm package installs?
• Who is accountable when a compromised package exposes cloud or developer secrets?