What breaks when developer accounts can publish packages and expose credentials at the same time?

The main failure is that one identity becomes both a delivery channel and a secret reservoir. If maintainers can publish code that executes on install and also hold reusable tokens, an attacker who compromises that account can move from software distribution into cloud and source control access very quickly. Segregating publishing rights, tokens, and runtime secrets reduces that blast radius.

Why This Matters for Security Teams

When a developer account can both publish packages and hold reusable credentials, the account stops being a simple human identity and becomes a high-trust distribution point. That combination collapses separation of duties: a single compromise can turn package publishing into code execution, then into access to source control, cloud APIs, and internal tooling. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge both point to the same operational flaw: secrets and execution authority should not share the same trust boundary.

The risk is not just theft of one token. Package ecosystems often allow install-time scripts, transitive dependency reach, and automation hooks that amplify a single account compromise into multi-stage intrusion. Once credentials live alongside publishing rights, attackers do not need to choose between software supply chain abuse and secret abuse because both paths are available through the same identity. Current best practice is to treat publishing, secret storage, and runtime access as separate controls, even when the same person owns the code. In practice, many security teams encounter this failure only after a package publish has already been used to extract credentials and expand access.

How It Works in Practice

The safer pattern is to split the identity into distinct functions. A maintainer may authenticate as a human developer, but package publication should use tightly scoped release automation, not long-lived personal tokens. Runtime secrets should be issued separately, ideally as short-lived credentials with clear task boundaries. The Ultimate Guide to NHIs — Static vs Dynamic Secrets captures the core operational rule: dynamic, ephemeral secrets reduce the window in which a compromise can be reused.

For package pipelines, that means using dedicated release identities, limited package-scoped permissions, and just-in-time access where possible. For cloud and source control, it means avoiding shared tokens and replacing them with workload identity, federation, or narrowly scoped service credentials. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces least privilege, credential management, and separation of duties as baseline expectations, while NIST SP 800-63 Digital Identity Guidelines helps distinguish identity proofing from authorization design.

• Separate publishing credentials from operational secrets.
• Use short-lived tokens for build and release actions.
• Restrict package publication to dedicated automation or approved release roles.
• Rotate or revoke any token that can reach both code and infrastructure.
• Log package publish events and secret access as distinct security events.

This guidance breaks down when legacy CI/CD systems require shared long-lived credentials across build, publish, and deploy steps because the same token becomes both the delivery mechanism and the standing privilege.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring teams to balance developer convenience against blast-radius reduction. That tradeoff is real, especially in small engineering orgs or in ecosystems where package tooling was designed around personal access tokens. Best practice is evolving, not settled, for how much automation should be delegated versus how much human approval should remain in the release path. NHIMG’s 2024 Non-Human Identity Security Report shows that most organisations still lag in non-human IAM maturity, which explains why ad hoc token reuse remains common.

Edge cases include open-source maintainers who need broad publishing access, internal developer platforms that federate dozens of repos, and incident-response scenarios where a maintainer must ship a hotfix quickly. In those cases, the right answer is not to merge privileges permanently. Instead, use time-bound elevation, approval gates for release actions, and separate recovery credentials that are stored and audited differently. The 52 NHI Breaches Analysis and the Shai Hulud npm malware campaign both illustrate how quickly published code and exposed credentials can be chained together once a maintainer boundary is crossed.

Where organisations cannot yet adopt full workload identity, the immediate priority is to make secret access independent from publish authority and to ensure package credentials cannot be reused outside the release path.

Related resources from NHI Mgmt Group

• What breaks when malicious npm packages are allowed to run on developer endpoints?
• What breaks when malicious npm packages are reviewed only at publish time?
• Who is accountable when CI identities are abused to publish malicious packages
• What are the risks of using static credentials in MCP servers?