Only the contract's own wording decides. If it says every critical must be patched, a reachability decision is a reason to ask for a written interpretation, not a reason to skip the patch. Read the clause, record how you read it, and get the customer's agreement on any carve out before relying on it. This is not legal advice.
Read the clause before you read the tool
Contracts differ in ways that matter. Look for these words.
- Which severity? Vendor published score, your own score, or a named scheme.
- Patch or remediate? Some clauses allow mitigation or a documented exception.
- From when? Disclosure, discovery, or availability of a fix.
- In what scope? The product delivered to this customer, or your whole estate.
A clause that says "remediate or mitigate in line with your vulnerability policy" leaves room. A clause that says "patch all critical vulnerabilities within a fixed number of days" leaves little, and no scan label changes that.
What reachability can and cannot do here
Reachability analysis tells you whether a call path to the vulnerable code exists in your build. It helps you rank work and explain choices. It does not rewrite a contract.
NIST's Secure Software Development Framework describes making a risk based decision on whether each vulnerability is remediated or addressed by other means, and updating records of approved exceptions. That is a sound internal process. It is not a promise to a customer unless the contract says so.
Three honest paths
- Patch anyway when it is cheap. If an upgrade is a minor version bump with passing tests, do it and avoid the argument. Automated fix pull requests can shorten this.
- Ask for an interpretation. Send the customer a short note: the finding, the product version, the analysis date, the finding that no call path exists, and your proposed treatment. Ask them to confirm in writing.
- Propose a policy rider. If the same question will recur, offer a standing definition, such as treating a critical with no call path as monitored with a review date.
What to send the customer
Keep it factual and short.
| Field | Example content |
|---|---|
| Finding | Advisory, package, version |
| Product scope | Version shipped to you |
| Analysis | Tool, date, commit |
| Result | No call path found, or call path found |
| Proposed treatment | Patch by a date, or monitor with next review |
| Request | Please confirm this treatment satisfies clause number |
Share it as a VEX statement if the customer can read one. The CISA minimum elements describe VEX as a status statement about a product or component, and note that it can be authored by the supplier or a third party.
What not to do
Do not quietly treat "critical" as "critical and reachable" and hope nobody asks. Do not write that the finding "does not apply" in a customer report. Do not cite the document you wrote as if it were the contract.
Try it yourself
Click through it at your own pace, or open it full screen. Notice where severity, status and due dates sit together.
Quick check
Can I rely on my internal policy over the customer contract?
Not where they conflict. The contract governs the relationship. Ask your own counsel if the wording is unclear.
Does a VEX statement waive a contract obligation?
No. It communicates status. Only an agreed written change alters the obligation.
Safeguard offers policies and gates plus autonomous remediation with fix pull requests, off by default and with every category on Manual, so a team can choose when to patch quickly. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
