Never promise zero vulnerable dependencies, fixes within a fixed time for every finding, coverage of everything you run, or a certification you do not hold. Promise a process you already follow, with a date and an owner, and state what it does not cover.
The promises that cause trouble
Under deal pressure, small teams stretch. The stretched sentence then lives in a signed document or a questionnaire for years. These are the usual ones, with a safer version.
| Risky promise | Why it fails | Safer wording |
|---|---|---|
| "We have no known vulnerabilities" | A new advisory can change this overnight | "We scan on every pull request and review open findings weekly" |
| "We patch all critical issues in 24 hours" | Not all fixes exist yet, and not all findings are reachable | "We triage critical findings within a set period and track fix dates" |
| "All of our code is scanned" | Forgotten repositories and vendored code are common | "We scan these named repositories; the list is in the evidence pack" |
| "We are SOC 2 compliant" | SOC 2 is an independent report, not a state you declare | State only what an auditor has actually issued, or say work is in progress |
| "Our supply chain is secure" | Unprovable and absolute | Describe controls, not outcomes |
| "We never use unmaintained packages" | You probably do somewhere | "We review maintainer activity before adoption and track end of life packages" |
Why absolutes are a legal and trust risk
This is not legal advice, and contract language should be checked by your counsel. The practical point is simple: an absolute statement can be disproved by one counterexample, and a reviewer who finds one will question every other answer. Specific, limited statements are harder to disprove and read as more honest.
How to phrase a commitment you can keep
Use a three part pattern: what you do, how often, who owns it.
- "We generate a dependency inventory for each production repository on every release. The platform lead owns it."
- "We review findings with a severity we rate critical within an agreed target and record the outcome in the ticket."
If a customer asks for a hard remediation time in a contract, take it to a person who can agree to it with open eyes. Do not let a questionnaire answer become a contract term by accident.
Mind the verbs
Words like "ensure", "guarantee", "eliminate" and "prevent" promise outcomes. Words like "monitor", "review", "scan" and "track" describe activity. Choose activity verbs for supply chain controls, because outcomes depend on attackers and maintainers you do not control.
Say what is out of scope
Name the exclusions: internal tools, a recent acquisition, customer built plugins, third party services you cannot inspect. A reviewer would rather read an honest scope line than discover the gap later.
Fix the record when facts change
If an answer becomes untrue, tell the customer and update it. Quietly leaving a stale answer in place is worse than a short correction.
Safeguard can help you keep the claims honest by producing dated scan and inventory evidence you can point to, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can we say we follow a framework?
Say you align certain practices to it, and name the practices. Do not say compliant or certified unless an independent party has issued that result.
What if the customer demands a promise anyway?
Escalate to the person who signs contracts, with a clear note of what you can actually deliver and measure.
Is "reasonable efforts" acceptable wording?
It is vague. A named process with an owner and a frequency is more useful to both sides.
Last reviewed: 19 October 2026.
