Show three things: the dependency tree diff contains only the intended change, the tests of every affected service pass, and the resolved version is the one you meant. Attach all three to the pull request. Skeptical teams approve evidence far faster than assurances.
Why proof matters in shared builds
An override changes a package you did not choose, often in a build many teams share. The team that asked for it sees a closed advisory. Other teams see a risk of surprise. Proof closes that gap.
Step 1: capture the tree before and after
List the dependency tree before the change and after, and diff them. In npm, the ls command with the all flag shows all installed packages, and a name and range argument limits output to paths leading to that package. The explain command gives a bottoms up view of why a package is present. In Maven, the guide recommends the dependency tree goal.
What you want to see: the target package changed version, and nothing else moved. If other packages changed, find out why. An override can pull a different dependency set along with the new version, so unexpected movement is a flag to investigate.
Step 2: confirm the resolved version
Do not trust the manifest line alone. Read the resolved version from the lockfile or the tree output. Check every workspace that resolves the package. A scoped override might apply in one subtree and miss another, which is exactly the surprise to catch.
Step 3: run the affected tests
List the services that resolve the package, from the tree output, and run each one's tests. If a service lacks tests on the code path that uses the package, add a small one now. A test that calls the package's main function with representative input is enough for many cases.
Step 4: check for a major version jump
If the forced version crosses a major boundary, read the changelog for breaking changes. Note them in the PR. A major jump deserves a canary rollout, not just green tests.
Step 5: gate the pull request
Run the same dependency scan in the pull request that runs on the main branch. Confirm the advisory is gone and that no new findings appeared. A pull request gate that fails on new high severity findings keeps the override from trading one issue for another.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the gate reports a result on the pull request before anything merges.
Safeguard supports policies, gates, and guardrails on pull requests, so the agreed rules run automatically. You can try a free scan first.
A one line summary for the PR
Write it like this: package moved from the old version to the new version; tree diff shows no other changes; tests pass in the listed services; resolved version confirmed in the lockfile; owner and review date set.
Quick check
Is a passing build enough proof?
Not alone. Builds pass with the wrong resolved version or a changed set of transitive packages. Check the tree and the lockfile too.
How do I find which services are affected?
List which workspaces or modules resolve the package using the tree command for your tool, then run each one's tests.
Sources
Last reviewed: 19 October 2026.
