Canonicalisation Drift

A mismatch between the name a policy engine checks and the name a runtime or installer actually resolves. In package governance, this can let a blocked item pass through under a different spelling, creating a fail-open condition even when controls appear to be in place.

Expanded Definition

Canonicalisation drift describes a security gap where one component evaluates a name, path, or package identifier differently from the component that later resolves or installs it. In NHI and supply-chain governance, that mismatch can undermine policy enforcement even when the control logic appears correct. The risk is not limited to typos. It also appears when one system normalises case, separators, aliases, version strings, or registry prefixes differently from another system. In practice, the policy layer may block one spelling while the runtime accepts another spelling that resolves to the same artifact. This is why the issue is closely related to normalisation, allowlist integrity, and resolver trust. The broader security principle aligns with the identity discipline in the NIST Cybersecurity Framework 2.0, where assets and protections only work when the system of record matches operational reality. Definitions vary across vendors on whether canonicalisation drift is a packaging issue, a parser issue, or a policy bypass class. The most common misapplication is treating string comparison as sufficient enforcement when the installer or runtime performs its own name resolution.

Examples and Use Cases

Implementing canonical name controls rigorously often introduces compatibility constraints, requiring organisations to weigh strict allowlisting against the operational cost of maintaining exact normalisation rules.

• A package governance engine blocks a library by its repository name, but the installer accepts an alias or mirrored namespace that resolves to the same code.
• A policy checks lowercase package identifiers, while the runtime normalises mixed-case input before resolution, allowing a blocked dependency to pass.
• A build pipeline approves one canonical URI for a container image, yet a tag rewrite or registry prefix change causes deployment to fetch a different artifact.
• A service account policy validates one secret reference format, but the application library resolves a second equivalent format and loads a disallowed credential.
• The Salesloft OAuth token breach illustrates how drift between expected and actual resolution paths can turn a control gap into live access.

For implementation guidance on consistent trust boundaries, teams often cross-check package and identity resolution behavior against the NIST Cybersecurity Framework 2.0 and then test whether every enforcement point uses the same canonical form.

Why It Matters in NHI Security

Canonicalisation drift matters because NHI controls are only as strong as the exact identifier the system enforces. If a package policy, service account policy, or agent tool policy is written against one representation but execution occurs through another, the result can be a fail-open condition that looks compliant in logs while still allowing unapproved access. In environments where secrets, API keys, service accounts, and agent tool chains are already overexposed, that kind of mismatch becomes a practical route around governance. NHI Mgmt Group notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations such as code, config files, and CI/CD tools, which means any name-resolution inconsistency can amplify an already fragile control plane. Strong handling requires consistent normalisation, resolver tracing, and testing across policy, installer, and runtime layers. Where the term intersects with broader identity governance, the concern is not merely correctness but enforcement integrity across the full access path. Organistions typically encounter the consequence only after a blocked artifact is still deployed or a disallowed credential is still accepted, at which point canonicalisation drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift
• Privilege Drift