Why do compromised maintainer accounts create such large NHI risk in software pipelines?

Why This Matters for Security Teams

Compromised maintainer accounts are high-value because they often sit at the intersection of human approval, automated publishing, and trusted build infrastructure. Once an attacker inherits that trust, the blast radius is rarely limited to one repository or one token. It can extend into package registries, CI/CD runners, release artifacts, and downstream consumers that assume the maintainer path is legitimate. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why a single maintainer compromise can become a supply chain event instead of a routine account incident.

The risk is amplified when legacy access tokens remain valid alongside newer provenance checks. In that situation, the account can still publish, sign, or trigger workflows even after the organisation believes modern controls are in place. Current guidance from NIST Cybersecurity Framework 2.0 stresses governance and access control, but software pipelines often fail because identity, secret, and build trust are managed as separate problems. In practice, many security teams encounter package tampering only after the compromised maintainer has already pushed trusted artifacts downstream.

How It Works in Practice

A maintainer account becomes dangerous when it can act as both a person and a machine trust anchor. The human side may approve releases, while the non-human side carries API tokens, signing keys, and CI permissions that outlive any single login session. If an attacker takes over the account, they can use that standing trust to publish a malicious release, rotate or reuse secrets, or alter pipeline configuration so the compromise persists.

Effective control starts by separating those powers. Release approval, package publishing, and secret access should not all ride on one identity. Instead, organisations should use short-lived credentials, scoped workload identities, and explicit workflow approvals for sensitive actions. The question is not just whether the account is authenticated, but whether it should be allowed to perform that specific operation at that moment.

• Use JIT access for publishing and signing, then revoke it automatically when the task ends.
• Bind CI jobs to workload identity rather than reusable human tokens.
• Store secrets in a managed vault and rotate them after maintainer changes, suspicious logins, or token exposure.
• Separate package ownership, code review, and release authority so one compromise does not grant full pipeline control.

This aligns with lessons from NHIMG’s 52 NHI Breaches Analysis and the Cisco DevHub NHI breach, both of which show how trusted identities can be leveraged far beyond their original scope. These controls tend to break down when organisations keep long-lived tokens in developer tooling and allow automated release paths to inherit maintainer privileges without fresh authorization.

Common Variations and Edge Cases

Tighter maintainer control often increases release friction, requiring organisations to balance supply chain integrity against developer velocity. That tradeoff is real, especially for open-source projects, distributed maintainers, and emergency hotfix pipelines. Best practice is evolving, and there is no universal standard yet for exactly how much human intervention every release should require.

Some environments need broader exceptions. A low-risk internal package may tolerate a narrower review path, while a public dependency or signing account should face stricter controls, shorter token lifetimes, and stronger anomaly detection. Incident response also needs to account for post-compromise persistence: revoking the maintainer login is not enough if package registry tokens, CI secrets, and release keys were already copied. NHIMG’s Guide to the Secret Sprawl Challenge is especially relevant here, because secret sprawl is what turns an account compromise into a pipeline compromise.

For organisations adopting stronger provenance, the key is to treat maintainer identity as one control plane and automation trust as another. That means continuous review of who can publish, what tokens still exist, and which workflows can sign or deploy. The most common failure mode is assuming a successful login is the only thing that needs to be blocked, when the real risk is the durable machinery left behind by that login.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do build pipelines create such a large NHI risk?
• Why do build pipelines create such a large NHI compromise risk?
• Why do non-human identities create more audit risk than human accounts?