Unblock Transitive Dependency Fixes

A vulnerable package may appear in a lockfile even though no application code imports it. A direct dependency selects a transitive version, and that parent may block a fixed release. The right task is to trace the installed path and prove which change removes the affected artifact. An advisory match alone does not prove the vulnerable code is reachable in this application.

OWASP's vulnerable dependency guidance supports inventory, assessment, and remediation. OSV records can identify affected version ranges and fixed releases. Keep the advisory ID, ecosystem, exact installed version, and deployment environment together. Do not compare a package name without its ecosystem or resolved version.

Dependency path graph

Start with the package manager's dependency explanation command in an owned repository. If two parents bring the same child, changing one may not remove the vulnerable copy. A narrow override can unblock a fix, but it may violate a parent's compatibility range. Prefer an upstream parent update when available, then test the exact application behavior. A fork or patch needs a named maintenance owner.

Prove the new graph

Build with the changed lockfile in a clean environment. Confirm the resolved artifact no longer falls in the advisory's affected range. Check runtime and build-only paths separately. Run the parent package's relevant integration tests as well as the application's normal test suite. If an override breaks a feature, record that result and choose another path rather than marking the alert closed.

A temporary exception needs an expiry and compensating control. Document why the code path is not currently reachable only when you have evidence; absence of a reported exploit is not that evidence. Keep the before-and-after graph, lockfile hash, test result, and reviewer decision. Do not fetch or test a third-party target to establish applicability. The outcome is a verified dependency change, not a claim that the full application is secure.