Why do maintained software identities need IAM-style governance?

Why This Matters for Security Teams

Maintained software identities are not just build-system details. Package publisher accounts, CI tokens, trusted publishing bindings, and release automation all behave like Non-Human Identities because they can sign artefacts, push packages, and trigger deployments. Once those credentials are reused, over-scoped, or left unmonitored, the software supply chain becomes an easy privilege path rather than a controlled control plane. That is why NHI governance belongs here, not just developer hygiene.

Security teams often miss this because the identity is attached to a pipeline step instead of a person. The risk shows up in incidents such as the JetBrains GitHub plugin token exposure and the Hard-Coded Secrets in VSCode Extensions research, where software distribution paths carried real identity risk. NIST’s Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both point toward governance, least privilege, and continuous oversight as baseline expectations.

In practice, many security teams encounter maintained identity abuse only after a compromised token is used to publish malicious code, rather than through intentional identity review.

How It Works in Practice

The practical model is to treat each maintained software identity as a governed workload identity with a defined owner, scope, lifecycle, and detection path. That means mapping who can create, approve, rotate, and revoke CI tokens; which repositories can use a trusted publishing binding; and what signing or package-release actions are allowed. NHI lifecycle controls from Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are directly relevant here because software identities need the same accountability as other machine credentials.

Good governance usually includes:

• Scoped identities that are tied to a single pipeline, repository, environment, or package namespace.
• Short-lived or automatically rotated secrets instead of durable tokens that survive staff turnover and pipeline drift.
• Explicit separation between build, signing, publishing, and deployment privileges.
• Audit logging for token creation, publishing events, and trust-boundary changes.
• Periodic access reviews for maintainers, bot accounts, and third-party release automation.

This is where current guidance suggests using Top 10 NHI Issues as a checklist for secret exposure, over-permissioning, and weak lifecycle discipline. NIST’s control model reinforces the same direction: identity assurance is not only for humans, and software-release actors must be continuously authorised rather than assumed trusted. In incident response terms, LLMjacking: How Attackers Hijack AI Using Compromised NHIs is a useful reminder that attackers move quickly once credentials are exposed; the same speed applies to package and CI credentials. These controls tend to break down in large mono-repos with many maintainers and loosely coupled release pipelines because ownership, trust scope, and revocation paths become unclear.

Common Variations and Edge Cases

Tighter release control often increases operational overhead, so organisations have to balance publishing speed against the cost of stronger approval and rotation workflows. That tradeoff is real, especially for open-source maintainers, federated engineering teams, and multi-tenant build platforms where identity boundaries are less obvious.

There is no universal standard for this yet, but current guidance suggests a few common patterns. For internal CI, short-lived OIDC-based federation is usually preferable to long-lived static secrets. For public package publishing, trusted publishing can reduce secret handling, but only if the binding, approver roles, and rollback procedures are themselves governed. For vendor-managed automation, the relevant question is whether the external service has a scoped NHI with revocation, not whether the integration is “trusted” by default.

Edge cases matter. A bot account with repo write access may be harmless for dependency updates but dangerous if it can also publish signed releases. A maintainer token may be appropriate for emergency fixes, but only if break-glass use is logged and time bound. The 2024 Non-Human Identity Security Report shows the broader maturity gap: many organisations still lag in non-human access management, which makes software identities especially easy to under-govern. For security programs, the practical takeaway is simple: treat maintained software identities as release-time privileges, not as permanent convenience accounts.

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?
• What is LLMjacking in an IAM context?