Who is accountable when stolen software supply chain credentials are used to publish malicious code?

Accountability sits across the maintainer, platform, and security functions because publishing rights, token scope, and runner governance all contribute to the failure. Under NHI governance, the owner of the credential lifecycle is responsible for limiting the blast radius of any stolen token.

Why This Matters for Security Teams

When stolen software supply chain credentials are used to publish malicious code, the problem is not just a lost token. It is a governance failure across package publishing rights, CI/CD runner trust, and secrets lifecycle ownership. The practical question is who can reduce blast radius before a compromised maintainer account or automation token becomes a distribution path for malware. OWASP’s OWASP Non-Human Identity Top 10 treats these credentials as first-class identities, not just configuration items.

NHI Management Group has repeatedly documented how secret exposure and token misuse turn routine delivery systems into attacker infrastructure, including the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. The accountability gap usually appears when teams assume platform security alone will prevent malicious publication, while maintainers assume the registry or CI system will catch abuse. In practice, many security teams encounter the failure only after a signed or trusted release has already been pushed, rather than through intentional credential-lifecycle design.

How It Works in Practice

Accountability should follow control over the credential lifecycle, because the actor who can issue, scope, rotate, revoke, and monitor the publishing identity is the one who can prevent or contain abuse. For software supply chains, that often means shared responsibility across the maintainer, the platform team, and security operations, with clear ownership for each control plane. NIST’s SP 800-53 Rev. 5 remains useful for mapping access control, audit, and incident response duties, while NIST identity guidance helps distinguish human users from workload identities.

In practice, strong programs do four things:

• Use short-lived publishing tokens or JIT access instead of long-lived static secrets.
• Bind package publishing to workload identity, not only a human maintainer session.
• Restrict token scope so a stolen credential can publish only the intended package, environment, or pipeline stage.
• Log, alert, and revoke on anomalous publishing behavior, including unusual runner origin, release timing, or artifact changes.

This is where NHI governance matters: the owner of the credential lifecycle is accountable for preventing token reuse, defining revocation triggers, and proving that publishing rights are narrower than the attacker’s likely path. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant here because static credentials extend attacker dwell time, while ephemeral secrets reduce the window for malicious publication. These controls tend to break down when legacy release systems still require manually managed tokens and no reliable runner attestation exists.

Common Variations and Edge Cases

Tighter publishing control often increases release friction, so organisations must balance fast deployment against abuse resistance. There is no universal standard for this yet, but current guidance suggests that high-trust publishing should be replaced with context-aware checks wherever feasible, especially for packages that downstream automation consumes. NIST’s Digital Identity Guidelines and the OWASP Non-Human Identity Top 10 both support the idea that identity assurance and credential handling must match the risk of the action being performed.

Edge cases matter. A solo maintainer who controls the package account, the signing key, and the CI secret may appear “accountable,” but that model concentrates failure instead of managing it. A platform provider may host the registry, yet still not own the compromised token lifecycle. Security may define policy, but if it cannot enforce scope, rotation, and telemetry on every publish path, it is not operationally accountable for the failed control. The cleanest answer is to assign responsibility by control domain: maintainer for approval and package integrity, platform for secure publishing primitives, and security for detection, governance, and response. NHIMG’s Guide to the Secret Sprawl Challenge and LiteLLM PyPI package breach show how fragmented secret handling quickly turns into shared accountability after the fact.

Related resources from NHI Mgmt Group

• What breaks when package publish credentials are stolen in a software supply chain?
• Why do stolen service credentials make supply chain incidents harder to contain?
• How should security teams govern software supply chain risk when CI/CD identities can publish code?
• Who should own response when supply chain malware reaches Kubernetes credentials?