Drift is a security risk when the older side carries a known vulnerability, the package is reachable from your code, and the environment is exposed. It is mostly noise when both versions are fixed releases, the package is a test or build tool, or the environment holds no real data and no exposure.
A simple scoring approach
Ask four questions for every difference between two environments:
- Does either version have a known advisory?
- Where does the vulnerable version run?
- Can your code reach the affected function?
- Is there a fix available that is safe to take?
Then sort.
| Pattern | Treatment |
|---|---|
| Prod has a vulnerable version, staging has the fixed one | Fix first. The risk is live. |
| Staging has a vulnerable version, prod has the fixed one | Fix soon. Do not let a rebuild promote it. |
| Both vulnerable, versions differ | Fix both, check that the fix works in both |
| Both fixed, versions differ by patch | Low priority, align on next release |
| Differences only in dev tooling | Usually noise |
Direction matters
Teams often assume prod is the only environment that counts. The reverse case is a trap. If staging runs a vulnerable package that production does not, the next deploy may carry it into production through a rebuild. Treat that as a pre-incident.
Exposure and data
Staging is not always safe to ignore. If it is internet facing, holds real data copies, or has credentials that reach other systems, drift there has real impact. Our post on staging vs production vulnerability priority goes through how to weigh this.
What to do with the noise
Do not delete it. Record it as accepted for now with an owner and a review date. Noise today becomes risk when an advisory is published for one of the versions. Because you already have the comparison, you can answer which environments are affected within minutes.
Signals that something is off
- The same package at three different major versions across environments.
- A package present in prod and missing in staging. That means prod contains something nobody tested.
- A version in prod that no longer exists in your repository history.
The last two deserve an investigation, not a ticket.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how filtering by reachability shrinks the list. Apply the same filter to drifted packages.
What Safeguard does here
Safeguard runs reachability analysis on dependency findings and monitors continuously, which helps separate a drifted package that your code calls from one it never touches. The free scan is at gold.safeguard.sh/scan.
Quick check
Should all drift be fixed?
No. Fix the risky drift quickly, and align the rest on a regular cadence.
What if I cannot tell if a package is reachable?
Treat it as reachable until you know. Unknown is not the same as safe.
Last reviewed: 19 October 2026.
