Notifications
Clear all
Topic starter
18/08/2026 3:01 pm
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.
NHIMG editorial — based on content published by FOSSA: semantic versioning errors can hide breaking changes in npm
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.
Questions worth separating out
Q: How should security teams handle dependency upgrades when semver is unreliable?
A: Treat semver as a hint, not a decision rule.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read FOSSA's analysis of semantic versioning drift and dependency risk →
Semantic versioning drift: what it means for dependency upgrades?
Explore further
18/08/2026 3:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Semantic versioning errors can hide breaking changes in npm
