Trusted Release Drift

Trusted release drift is the condition where a legitimate update path can be repurposed after compromise. In supply chain attacks, tags, package versions, and workflow references stay trusted even after the underlying maintainer account or token has been stolen, letting attacker-controlled code inherit that trust.

Expanded Definition

Trusted release drift describes a failure mode in software supply chains where a release path remains trusted after its source of authority has been compromised. The tag, package version, workflow reference, or deployment pointer still looks legitimate, so downstream systems continue to accept attacker-controlled code as if it were approved.

In NHI and agentic AI environments, the issue is not only code integrity but also the identity behind the release mechanism. A stolen maintainer token, compromised CI credential, or hijacked automation account can preserve the appearance of legitimacy while changing the contents being published. That makes trusted release drift a governance problem as much as a technical one. It overlaps with supply chain assurance, secret hygiene, and release provenance, and it is closely related to controls described in the NIST Cybersecurity Framework 2.0, even though no single standard governs this exact term yet.

NHIMG research on Salesloft OAuth token breach shows how trusted paths can be abused after token compromise. The most common misapplication is assuming a signed tag or familiar version label is still trustworthy after the maintainer credential or workflow secret has been stolen.

Examples and Use Cases

Implementing release trust rigorously often introduces friction, because stronger validation can slow publishing and force teams to maintain more explicit provenance data. Organisations must weigh delivery speed against the cost of tighter verification and revocation discipline.

• A package registry continues to accept updates from a maintainer account after its API token is stolen, allowing malicious versions to inherit the package’s established trust.
• A GitHub Actions workflow reference stays pinned to a familiar branch or tag, but the underlying repository access is compromised and the automation publishes altered artifacts.
• A container image tag remains unchanged while the image behind it is replaced, so deployment pipelines pull attacker-controlled content from a trusted label.
• A CI/CD service account is not rotated after a breach, and the attacker keeps using the normal release path to push poisoned builds.
• NHIMG’s coverage of the Salesloft OAuth token breach is a reminder that compromised release or integration credentials can preserve trusted access long enough for tampering to look routine.

Teams often pair these checks with provenance guidance from the NIST Cybersecurity Framework 2.0 and identity-aware build controls, but terminology still varies across vendors. In practice, the goal is to confirm that the thing being trusted is still controlled by the right identity at the moment of release.

Why It Matters in NHI Security

Trusted release drift matters because NHI compromise often turns a normal automation channel into an attacker’s delivery system. When release credentials, tokens, or workflow identities are not revoked quickly, downstream systems continue to trust what is effectively hostile code. That creates a durable breach path across CI/CD, artifact registries, package ecosystems, and agent toolchains.

The risk is amplified by weak visibility and slow remediation. NHIMG reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, which means trusted pathways often outlive detection by days. In the same research set, NHIMG notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how release trust becomes an identity problem once credentials are stolen.

For governance, the practical response is provenance verification, rapid credential rotation, scoped release authority, and explicit revocation of compromised automation identities. Organisations typically encounter the full impact only after a malicious update has already propagated through internal pipelines, at which point trusted release drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised workflow changes trusted release artefacts?
• Who is accountable when a release workflow publishes malicious code through trusted publishing?
• Trusted Continuity Drift
• Trusted Automation Drift