Just wasted 3 hours - Snyk's npm audit fix doesn't fix transitive dependencies?

cloud_cost_optimizer · 2026-08-04T01:36:04Z

I've encountered a significant and time-consuming discrepancy between Snyk's advertised remediation capabilities and its actual behavior in a CI/CD pipeline, specifically regarding transitive dependency vulnerabilities. This post details my findings, as I believe this impacts the core value proposition of automated fix workflows for many teams. During a routine pipeline execution, Snyk CLI (`snyk test --severity-threshold=high`) flagged a high-severity vulnerability in a transitive dependency nested three levels deep within our Node.js project's dependency tree. Following standard protocol, we executed the recommended remediation command: `snyk fix`. The tool ran, output indicated successful fixes, and our `package.json` was updated. However, a subsequent `snyk test` revealed the *exact same* high-severity vulnerability persisted. Upon investigation, I discovered the root cause: **`snyk fix` primarily operates on direct dependencies listed in `package.json`.** It attempts to upgrade those direct packages to versions where the transitive vulnerability is patched. However, this strategy fails if: 1. The direct dependency has not released a version that uses a patched version of the vulnerable transitive dependency. 2. The vulnerability is introduced by a transitive dependency that is locked by a *different* direct dependency's own version constraints. Here is a simplified breakdown of the dependency tree and the observed behavior: ``` Our package.json depends on: └── library-a@2.1.0 └── library-b@1.5.0 └── vulnerable-library@2.2.0 (HIGH SEVERITY CVE-2023-XXXX) ``` `Snyk fix` analyzed this and updated `package.json` to `library-a@2.2.0`, based on the assumption that this newer version would use a safe `vulnerable-library`. However, the actual tree for `library-a@2.2.0` was: ``` library-a@2.2.0 └── library-b@1.5.0 # Unchanged, still pins the vulnerable version. └── vulnerable-library@2.2.0 (HIGH SEVERITY CVE-2023-XXXX) ``` The tool's algorithm did not—and arguably cannot—force a change to `library-b`'s version because it is not a direct dependency of our project. This creates a remediation deadlock without manual intervention. **Workaround & Required Manual Steps:** To actually resolve this, I was forced to: * Use `npm ls vulnerable-library` to fully trace the inclusion path. * Identify which direct dependencies ultimately pulled it in. * Manually research if newer versions of those direct dependencies had updated *their* subdependency constraints. * In some cases, the only recourse was to add the transitive dependency as a *direct* dependency in our `package.json` to pin a non-vulnerable version, using npm overrides or yarn resolutions. This process negates the promised efficiency of automated fixing. For teams operating at scale with hundreds of dependencies, this limitation means `snyk fix` provides a false sense of security and can waste considerable engineering cycles. My question to the community: Has anyone developed a robust pipeline strategy to handle these transitive fix failures? Are you coupling Snyk with other tools or scripts to analyze the remediation PRs it generates for completeness? I am particularly interested in approaches that can be integrated into a FinOps-oriented pipeline where unresolved vulnerabilities can lead to compliance delays and, indirectly, cost implications from blocked deployments. -cc

Page 2 / 2 Prev

Snyk Reviews

Last Post by helenj 2 months ago

16 Posts

16 Users

0 Reactions

53 Views

RSS

helenj

(@helenj)

Reputable Member

Joined: 3 months ago

Posts: 458

04/08/2026 1:47 pm

That's a very clear breakdown of the failure mode. You've pinpointed exactly where the automated workflow breaks down, which is so helpful for others running into this.

I'd add that this isn't just about the tool's technical limitation, it's about the expectation gap you mention. Teams hear "automated fix" and reasonably assume the vulnerability is resolved, not that they've just been handed a possible first step in a manual chain of decisions. The silent pass on the subsequent test is what really sows distrust.

Have you found any reliable way, beyond the manual test step, to document or flag these "partially fixed" states for your team?

ReplyQuote

Page 2 / 2 Prev