The earlier approval may no longer be valid, even if the package name stays the same. That creates governance drift, because the decision recorded at review time no longer matches the current risk. Automated rescanning is needed so version changes trigger a fresh policy evaluation before the updated dependency is trusted.
What changes when approval no longer matches the dependency?
Approval is a point-in-time decision, not a permanent property of the package. If the dependency’s license changes after review, the original acceptance may no longer reflect current legal, procurement, or policy constraints, so the dependency has effectively moved into a new governance state even though the artifact name has not changed.
That matters because teams often track packages by name and version, but license obligations are tied to the exact released artifact. When a library publisher reissues or relicenses a version, the risk is not theoretical drift, it is a change in what your organisation is permitted to ship, redistribute, or embed.
For dependency governance, the right mental model is that approval attaches to the evaluated release, not to the project identity. A dependency can remain technically functional while becoming non-compliant, which is why license metadata, transitive inclusion, and update workflows all need to be rechecked when the package version changes.
Why license drift creates a governance problem
A license change can invalidate earlier sign-off without changing build success, test results, or runtime behaviour. That makes it easy for the issue to slip through ordinary engineering controls, especially when dependency updates are treated as routine maintenance rather than a policy event.
This is a classic governance drift pattern: the recorded decision no longer matches the current facts. In practice, that means policy evidence, legal review notes, and automated allowlists can all become stale unless the organisation has a mechanism to revisit approval when a dependency is updated.
That is also why supply-chain governance needs to treat software provenance and release metadata as control inputs, not just operational details. Projects such as OpenSSF exist to strengthen open source supply chain security, which includes the broader problem of keeping dependency trust decisions aligned with changing upstream conditions.
What a control failure looks like in practice
The failure mode is usually not that the dependency becomes immediately malicious. More often, the organisation continues using an updated package because it appears to be the same trusted component, while the new license terms or licensing history would have led to a different decision if the update had been reviewed again.
Automated rescanning is the practical control that closes that gap. When version changes trigger a fresh policy evaluation, teams can detect when an approved package has moved outside the organisation’s acceptable license set and pause promotion before the updated dependency is trusted in build or release pipelines.
That aligns well with the supply-chain lesson captured in LiteLLM PyPI package breach, where the important issue is not just package identity, but the trust placed in a dependency that can change in ways users do not expect.
Risk and Threat Considerations
License drift can create both compliance exposure and downstream business risk. If an unreviewed version is adopted, the organisation may distribute software under terms it never approved, inherit obligations it cannot meet, or discover the issue only after the dependency has spread across multiple products.
Failure mechanism: The control decision is bound to an old review record while the package version, licensing terms, or transitive composition has changed, so the dependency remains “approved” in tooling even though the current release is not.
Impact: Teams can ship non-compliant software, trigger legal or procurement escalation, and lose confidence in the dependency approval process because the inventory no longer reflects the real risk state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, SLSA and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Covers secure dependency governance and verification of third-party software changes. |
| Recommendation — Rescan dependencies on update and block release until licensing and policy checks pass. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk management strategy established | License drift is a governance risk that needs a repeatable decision process. |
| Recommendation — Define a dependency review trigger for every version change and require renewed approval. | ||
| SLSA | Supply-chain integrity | Version changes and provenance checks are central to trusted software dependency decisions. |
| Recommendation — Verify provenance and re-evaluate trust whenever a dependency release changes. | ||
| ISO/IEC 27001:2022 | A.5.21 — Managing information security in the ICT supply chain | Third-party software updates create supply-chain governance obligations that include continued assurance. |
| Recommendation — Extend supplier and component review to updated dependency releases before adoption. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Dependency changes require supply-chain controls that reassess trusted components over time. |
| Recommendation — Require update-triggered revalidation for third-party software and components. | ||
Practitioner Guidance
What to verify: Treat the exact artifact version as the approval unit. Verify that your dependency scanner checks for license changes on every update, not only on first introduction, and that transitive dependencies are included in the same review path.
Decision rule: If the updated package has a different license, different publisher history, or unresolved policy status, force a fresh approval before release. If your tooling cannot detect that drift automatically, treat the workflow as incomplete rather than “mostly covered.”
What good looks like: The build pipeline can show that an approved dependency was rescanned after version change, that the current license state matched policy at the time of release, and that any exception carried an explicit owner and expiry.
Practitioner takeaway: Approval should follow the version, not the package name. If you cannot prove that each dependency update revalidated licensing and policy, you do not really have dependency governance, you have a stale exception list.
Related resources from NHI Mgmt Group
- Who is accountable when a FedRAMP-authorized system changes after approval?
- What breaks when a browser extension changes behavior after approval?
- What happens when an MCP tool description is changed after approval?
- What happens when cloud security validation is still based on a snapshot test after deployment changes?