Rewrite a weak question by adding three things: the specific object it applies to, the condition under which it must hold, and the evidence you will accept as proof. "Do you support SBOMs?" becomes a question a vendor can answer with a file, a format name and a version.
Why weak questions fail
A weak question can be answered "yes" by every vendor, so it separates nobody. It also invites long marketing paragraphs that you cannot score. The fix is not a longer question. It is a more specific one.
The three additions
- Object. Which thing? A repo, a container image, a pull request, an export file, a role.
- Condition. Under what circumstances? In CI, within one working day, for transitive dependencies, on a self-hosted install.
- Evidence. What will you accept? A sample file, a screenshot of the setting, a documentation link, a reference customer who can confirm.
Eight rewrites
| Weak question | Testable version |
|---|---|
| Do you support SBOMs? | Which SBOM formats and versions can the product export, and can you attach a sample export for a repo with 200 or more dependencies? |
| Is your vulnerability data up to date? | Which advisory sources feed the product, and how long after a source publishes does the data appear? Show one recent example with both timestamps. |
| Do you reduce false positives? | For findings on a repo we supply, how does the product mark a vulnerable component as not reachable, and what evidence does it show for that decision? |
| Do you integrate with CI? | List the CI systems with a documented, maintained integration, and link the setup guide for ours. |
| Is the platform secure? | Provide your most recent independent assessment summary and describe how you handle a vulnerability reported in your own product. |
| Do you offer automated fixes? | State whether fixes are proposed as pull requests, which categories are on by default, and how a team turns them off. |
| Do you have good support? | State support hours, response targets by severity, and the channel used for each. |
| Can you scale? | State the largest customer deployment by repository count you are willing to reference, and the scan time for a repo of our size. |
Notice that every rewrite can be checked. If a vendor cannot answer, that is information too.
Run a quick test on each question
Before sending the RFP, read each question and ask:
- Could two vendors give different, comparable answers? If not, sharpen it.
- Could a vendor answer yes while delivering nothing useful? If yes, add evidence.
- Do I know what a good answer looks like? Write it down next to the question, privately, as your scoring note.
- Could I verify the answer in a trial? If so, plan the check.
Keep the question count honest
Testable questions take longer to answer, so ask fewer. Thirty sharp questions beat one hundred vague ones. Keep a bank of extras for the follow-up round with shortlisted vendors.
A worked example: rewriting one question three times
Take the weak question: "Do you reduce false positives?"
Draft 1. Add the object: "For findings in dependencies, how do you reduce false positives?" Better, but the vendor can still write a paragraph about machine learning.
Draft 2. Add the condition: "For a repository we supply, how does the product decide that a vulnerable dependency is not reachable from our code, and what does it show a developer to explain the decision?" Now the vendor has to describe a mechanism.
Draft 3. Add the evidence: "Include a screenshot or a documentation link showing that explanation, and say which languages the reachability analysis supports today." Now you can check the answer in a trial, and you can compare vendors on the supported languages.
Each draft takes a minute. The final version is easier to score because both the question and the expected answer have a shape.
How to build a bank of rewrites
Keep a shared document with three columns: the weak phrasing you see in templates, the testable version, and a note on what a good answer looks like. Over time it becomes a library you can reuse across purchases. Cover the usual topics: coverage, data handling, integration, reporting, support, exit and the vendor's own security.
Phrases that signal a weak question
| Phrase | Problem | Fix |
|---|---|---|
| Do you support | Yes covers anything | Name the versions, formats or workflows |
| Industry leading | Not checkable | Ask for the measurement and its method |
| Comprehensive | Undefined | Ask for the list |
| Real time | No unit | Ask for the delay in minutes or hours, with an example |
| Seamless integration | Unverifiable | Ask for the setup guide link |
| Best practice | Whose? | Ask which standard or document |
Test your questions on a colleague
Hand ten rewritten questions to someone outside the project and ask, "What would a good answer look like?" If they cannot say, the question needs work. This five minute exercise often improves a draft more than another round of expert review.
Avoid the opposite problem
A question can also be too narrow. If it names a specific vendor's term or a specific feature name, other vendors cannot answer fairly. Phrase questions in terms of outcomes and behavior, such as "reports in the pull request," not product jargon.
Where Safeguard fits
If you are testing vendor answers on reachability, SBOM export or policies and gates, you can run Safeguard on one of your repos through the free scan at https://gold.safeguard.sh/scan and apply the same questions to its output. It is one candidate among several, and the same evidence rules apply to it.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how reachability changes the findings list, then use what you see to sharpen your own question about false positives.
Quick check
What is the fastest way to improve an RFP question?
Add the evidence you will accept, such as a sample file or a setup guide link.
Should we send our scoring notes to vendors?
Share the criteria and weights, not your private notes about what a perfect answer looks like.
How do we avoid favoring one vendor's wording?
Write questions in terms of outcomes and observable behavior, such as what a developer sees in a pull request, and avoid product specific terms. Have someone from outside the project read the draft.
Last reviewed: 19 October 2026.
