TL;DR: Semver drift can cause package managers and upgrade automation to misjudge risk, letting breaking changes slip through as minor updates, according to FOSSA’s analysis of lodash version changes. The practical problem is not version numbers themselves, but whether your dependency tooling can verify compatibility against actual application usage.
At a glance
What this is: This analysis shows that incorrect semantic versions can make dependency tools assume upgrades are safe when breaking changes are already present.
Why it matters: For security and identity practitioners, semver drift matters because software supply chain controls, release gates, and dependency review workflows depend on accurate change signals to prevent unstable or unsafe upgrades.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
👉 Read FOSSA's analysis of semantic versioning drift and dependency risk
Context
Semantic versioning is a release governance signal, not a guarantee of compatibility. When that signal is inaccurate, automation that trusts version numbers can approve upgrades that introduce hidden breakage, especially in dependency-heavy software supply chains and CI/CD workflows.
The same governance problem shows up in identity and access programmes when controls trust labels instead of validating behaviour. In NHI, agentic AI, and software delivery contexts, the lesson is consistent: lifecycle decisions need evidence from actual change impact, not just published metadata.
Key questions
Q: How should security teams handle dependency upgrades when semver is unreliable?
A: Treat semver as a hint, not a decision rule. Require behavioural testing, package usage analysis, and rollback readiness before allowing upgrades into shared or production environments. The goal is to stop version labels from driving change approval when the consuming application has not been validated against the new release.
Q: What breaks when automation trusts version numbers too much?
A: Automation can promote packages that look like safe minor updates but actually contain breaking changes. That creates application instability, wasted engineer time, and reduced trust in dependency tooling. The failure is not just technical. It is a governance failure caused by relying on metadata instead of validated compatibility.
Q: How do you know if dependency governance is actually working?
A: You know it is working when risky upgrades are caught before deployment, automated changes correlate with successful tests, and engineering teams stop discovering hidden breakage only after release. Strong governance produces fewer surprise failures and more predictable upgrade decisions across the software supply chain.
Q: What is the difference between semver checking and usage-aware analysis?
A: Semver checking reads the version label and assumes it reflects compatibility. Usage-aware analysis examines how the application really uses the dependency and tests whether the specific change will break those code paths. The second approach is more reliable because it measures effect, not declared intent.
Technical breakdown
Why semver fails as a compatibility signal
Semantic versioning encodes intent through major, minor, and patch numbers, but it depends on human discipline. When maintainers misclassify breaking changes or downstream tooling interprets releases mechanically, the version becomes a weak proxy for actual compatibility. That creates a mismatch between the package contract and the code reality. In dependency ecosystems such as npm, this can distort automated update policies, release confidence scoring, and rollback expectations. The core failure is not versioning itself but blind trust in a label that has no enforcement layer.
Practical implication: treat semver as input to review, not as a control that can replace compatibility testing.
How dependency automation amplifies versioning errors
Tools such as upgrade bots and policy engines often optimize for speed by using version ranges and release metadata. If a package is mislabeled as non-breaking, automation may raise the change priority too late or suppress deeper review. That is useful when maintainers are consistent, but risky when the ecosystem is noisy or the package has unstable release discipline. In practice, dependency automation converts a metadata mistake into a governance decision, which is why testing and behavioural validation matter more than the version bump itself.
Practical implication: align automated upgrade rules with test evidence and package behaviour, not with version numbers alone.
Why usage-aware analysis is the better control
Usage-aware analysis looks at how an application actually consumes a dependency, then determines whether a change will break real code paths. That is stronger than relying on changelogs or version labels because it links the package delta to the consuming application’s behaviour. For security teams, this is analogous to validating effective access rather than declared access. The control question becomes whether the change affects the exact functionality your workload depends on, not whether the release looks safe on paper.
Practical implication: prioritize usage-based compatibility checks for critical dependencies and release gates.
Threat narrative
Attacker objective: The practical objective is not theft but to hide breaking changes inside trusted update channels and disrupt software delivery confidence.
- Entry occurs when a package publishes a misleading semantic version that suggests a safe update path.
- Escalation follows when automation, bots, or policy rules treat the mislabeled release as low risk and expand it into production.
- Impact is application breakage, noisy upgrade processes, and reduced trust in dependency automation.
NHI Mgmt Group analysis
Semver drift is a governance problem, not just a packaging problem. When version labels no longer match the actual compatibility surface, dependency policy becomes detached from runtime reality. That matters because release automation, review queues, and change risk scoring all rely on the same metadata. Practitioners should treat semver as a signal that must be validated, not as evidence that a release is safe.
Usage-aware compatibility is the named control gap this article exposes. The central failure mode is assuming that version movement predicts impact on the consuming application. In reality, breakage depends on which functions, code paths, and runtime behaviours are in use. That is why application-level analysis is stronger than package-level classification, especially in CI/CD environments where speed pressures can override scrutiny.
Dependency governance is increasingly a trust verification problem. Open source ecosystems scale faster than manual release discipline, so organisations need controls that test the effect of change rather than the declared intent of change. In security terms, this is the same logic that underpins stronger identity and access governance: validate the effective state, not the label.
Identity programmes should notice the pattern here because trust labels fail in the same way across domains. Whether the control is a package version, a service account entitlement, or an AI workflow permission, the risk comes from trusting a declared state that is not continuously verified. Practitioners should build controls that measure actual behaviour before they let automation decide for them.
What this signals
Teams should read this as a reminder that governance fails when automation trusts labels more than evidence. In software delivery, that means dependency policy has to be tied to test outcomes, runtime observations, and rollback controls, not just release metadata.
Declared-state drift: when the published state and the effective state diverge, every downstream control becomes weaker. The same pattern appears in identity programmes when entitlements, secrets, or service account states are assumed to be correct without validation.
For organisations running high-change pipelines, the next maturity step is to combine version policy with behavioural verification and better control mapping. That is where supply chain safety starts to look more like continuous assurance than static approval.
For practitioners
- Validate dependency changes against observed application usage Run compatibility analysis on the code paths that actually invoke each library, then gate upgrades on behavioural evidence rather than minor or patch labels.
- Separate release metadata from upgrade approval Require a test or policy checkpoint that confirms the change does not break the consuming application before automated tools can promote it.
- Review high-impact packages for hidden breakage patterns Prioritize packages that underpin authentication, parsing, signing, or serialization workflows, because those are the places where a small change can produce broad runtime impact.
- Tune dependency bots to reflect real risk Configure automation to treat version numbers as a starting point and to escalate packages that show behavioural drift, unusual release cadence, or inconsistent changelog quality.
Key takeaways
- Incorrect semver turns release metadata into a false signal, which can hide real breaking changes from automation.
- The practical control gap is reliance on version labels instead of usage-aware compatibility evidence.
- Security and platform teams should gate upgrades on behavioural validation, not on declared compatibility alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-3 | Version drift affects secure change management and release validation. |
| NIST SP 800-53 Rev 5 | CM-3 | Semantic version errors belong in configuration and change control governance. |
| CIS Controls v8 | CIS-16 , Application Software Security | Dependency upgrades are part of secure application delivery and testing. |
| ISO/IEC 27001:2022 | A.8.32 | Change management controls apply when software updates can introduce breakage. |
| MITRE ATT&CK | TA0042 , Resource Development; TA0005 , Defense Evasion | The article reflects supply chain abuse patterns where trusted updates conceal harmful change. |
Map risky package workflows to ATT&CK supply chain tactics and monitor for deceptive release behaviour.
Key terms
- Semantic Versioning: A release numbering scheme that uses major, minor, and patch values to communicate compatibility expectations. In practice, it is only as reliable as the maintainer’s discipline, which is why governance must validate actual behaviour instead of assuming the number tells the full story.
- Usage-Aware Analysis: A method that tests how an application really uses a dependency before deciding whether an upgrade is safe. It is stronger than version-based review because it connects code-path behaviour to release impact, which is where most breakage actually appears.
- Dependency Bot: An automated service that opens, updates, or merges dependency changes on behalf of a repository. In NHI terms, it is a machine identity with the authority to modify code paths and should be governed with scoped access, review boundaries, and clear ownership.
What's in the full article
FOSSA's full report covers the operational detail this post intentionally leaves for the source:
- The resemver methodology used to detect breaking changes and recalculate the effective semantic version.
- The full lodash version-by-version comparison, including the specific function changes that drove the 2.0.0 jump.
- How usage-aware analysis can replace version-number assumptions in dependency upgrade workflows.
- The practical implications for teams using automation such as dependency bots and minors-only policies.
👉 FOSSA's full post covers the version-by-version example and the resemver method in detail.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a common control language for identity programmes that need stronger lifecycle and access discipline.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
