What are the signs that release and publishing identities are being abused?

How to tell release and publishing identities are being abused

Abuse shows up when the actor behind a release or publish path is no longer behaving like the normal build or maintainer identity for that repository. The giveaway is not only that a release happened, but that it happened through unusual credentials, unusual workflows, or an unexpected trust path. That is a publishing-identity problem, and it often appears before anyone confirms artifact tampering.

One common sign is a release or publish action that succeeds with a token, key, or OIDC assertion that does not belong to the usual release lane. Another is a build or signing event that looks valid on the surface, yet originated from a workflow, branch, runner, or commit history that does not match the repository’s normal release process.

What suspicious release activity looks like in practice

Watch for orphaned commits, release tags, or package uploads that cannot be traced cleanly to the expected maintainer path. If a publish event is tied to a token request, build job, or automation account that was not part of the normal release cadence, treat it as an identity anomaly first, not just a pipeline oddity.

Unexpected OIDC token use is especially important because it can indicate a trusted exchange was completed from the wrong context. A workflow that can still obtain a valid-looking token, but is not the approved release workflow, may be using stolen access, misplaced trust, or an overbroad publishing grant.

Another warning sign is provenance that validates technically but does not make operational sense. If the artifact signature, attestation, or provenance chain appears intact while the source workflow is unfamiliar or untrusted, the control failure is often in the publishing identity and release authorization path, not in the artifact itself.

Why publishing identity abuse is hard to spot

Publishing abuse is subtle because the attacker wants the release to look routine. They do not need to break every control if they can borrow a legitimate lane, reuse an approved token path, or trigger automation that already has publish rights. That means the surface symptoms often resemble normal delivery activity until you compare them with expected identity, workflow, and ownership patterns.

This is also why teams miss the early signal when they focus only on package contents. A clean checksum or a signed release can still come from the wrong actor if the release identity was compromised, overprivileged, or used outside its intended context. The identity path, not just the artifact, has to be trusted.

Risk and Threat Considerations

Release and publishing identities are attractive because they can convert a single compromise into widespread downstream trust. If an attacker can impersonate the release lane, they may be able to publish malicious artifacts, replace legitimate builds, or seed users and downstream systems with content that appears authentic.

Failure mechanism: The attacker abuses a trusted publishing credential, workflow token, or automation path to make an unauthorized release look legitimate, often by preserving the expected signatures or provenance format.

Impact: Consumers may install or promote a tampered package, and the organisation may not detect the compromise until the release history, workflow logs, or token usage patterns are audited after the fact.

Practitioner Guidance

What to verify: Confirm that each release event can be tied to the expected maintainer identity, the approved workflow, and the normal release lane. If the publish path used a token, check who issued it, where it was minted, and whether that context matches the repository’s release policy.

What to measure: Track publishing events that occur outside standard release windows, originate from unapproved runners or branches, or use credentials that are not scoped to the release function. A small number of exceptions can be normal, but repeated mismatches between release identity and release activity are a strong indicator of abuse.

Common mistake: Teams often treat a valid signature or successful package upload as proof of legitimacy. For this question, the more reliable test is whether the identity behind the release had the right context, privilege, and provenance to perform that action.

Practitioner takeaway: When release activity looks valid but the identity path does not, assume the publishing lane may be compromised and investigate the credential, workflow, and provenance chain together rather than in isolation.

Related resources from NHI Mgmt Group

• What signs suggest npm or GitHub publishing identities are being abused?
• 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?