Replace opinions with evidence. Ask security to show whether the vulnerable code is reachable, and ask platform to run the bump in a test branch. If the tests pass, upgrade. If they fail, record a dated exception with a compensating control and a named owner.
Why both sides are acting reasonably
Security sees an advisory and a clock. Platform sees a shared build that thirty services depend on and a bump that nobody has tested. Each is protecting something real.
The standoff lasts when neither side brings new information. Another round of "it is critical" or "it is risky" changes nothing.
What each side owes the other
Security owes platform specifics.
- Which advisory, and what version fixes it.
- Which services contain the package, confirmed from the dependency tree or an SBOM.
- Whether the vulnerable function is called. Reachability analysis answers this, and so can a code search for the affected API.
Platform owes security a time box.
- A test run of the bump in a branch within an agreed number of days.
- A written reason if the bump fails, including which test and why.
The decision tree
- Is the vulnerable code reachable in any shipped service? If no, downgrade the urgency, schedule the bump with normal maintenance, and note the reasoning in the ticket.
- If yes, does the bump pass tests? If yes, ship it.
- If it fails, is there a smaller fix? Look for a patch release within the same major version, an override to a fixed version of just the vulnerable package, or an exclusion of a component that is not used.
- If none exist, record an exception. State the compensating control, such as a configuration change, input filtering, or network restriction, plus an expiry date.
Write the exception properly
A vague exception is how standoffs turn into permanent risk. Include these fields.
| Field | Example content |
|---|---|
| Package and version | Name, current version, fixed version |
| Services affected | List from the dependency tree |
| Reason not fixed | The failing test or the blocked upstream release |
| Compensating control | What reduces the risk meanwhile |
| Owner | A named person, not a team alias |
| Expiry | A date that triggers a re-review |
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings change once reachability is applied, since that is the evidence that usually ends the argument.
Safeguard's reachability analysis marks whether a vulnerable function is called from your code, and its policies and gates let teams agree in advance what blocks a build. A free scan shows how that looks on your own project.
Agree the rules before the next advisory
Write down the time box, the evidence required, and the escalation path in a short policy. When the next advisory arrives, the argument is already settled, and people follow the process instead of relitigating it.
Quick check
Should security be able to force a platform upgrade?
Security can set the deadline and the evidence bar. Platform controls how the change is tested and rolled out. Agree that split in a written policy.
Is an unreachable vulnerability safe to ignore?
Not forever. It lowers urgency, but code paths change, so keep the finding on a scheduled bump and re-check reachability when the code changes.
Last reviewed: 19 October 2026.
