Write one page listing your languages and frameworks, build systems, CI platform, data handling rules, who will triage, and the five things the tool must do. Share it with every vendor first. It stops demos drifting toward each vendor's strengths and gives you a fixed yardstick.
Why do this first
Vendor calls shape your opinion. Whoever talks first defines what seems important. A requirements page written in advance lets you steer, and it gives a quick filter: if a tool fails a must have, you spare yourself a demo.
What goes on the page
Languages and frameworks. List each language with its version, and the main frameworks. Mark which are central and which are marginal. OWASP lists language support as a prerequisite criterion, and framework understanding as a separate one, so write both.
Build and repositories. Number of repositories, rough size of the largest, whether there are monorepos, and how code is built. Note if code cannot easily be compiled in CI, since many tools need buildable code.
Where it must run. Your source host, your CI system, which editors developers use. Say if scans must run inside your network.
Data rules. Whether source code may leave your environment, whether results may be stored by a third party, and where. Include any residency requirements. Your legal team can fill this in quickly.
Workflow. Where findings should appear: pull request comments, issue tracker, chat. Say who will triage and how much time they have each week.
Output and exit. Export in a standard format such as SARIF, plus the ability to take your suppressions and history with you.
Commercial shape. Not prices, but the structure you can accept. Per developer, per application and per line of code each behave differently as you grow, so say which you can budget for.
Must haves and nice to haves. Limit must haves to five. If everything is a must have, nothing is.
Add three kinds of test
Under the requirements, list how you will test them: the pilot repositories, the seeded bugs, and the survey. Vendors then know the evaluation is real and that sales claims will be checked.
What to leave off
Do not write a hundred line checklist. Long RFP style lists encourage vendors to answer yes to everything. A short page with specific demands gets specific answers. If you also run a formal RFP, keep the one pager as the cover note.
Do not name a preferred vendor, and do not copy a vendor's own feature list into your requirements. Write from your problem, not their product.
Keep it alive
Update the page after each vendor conversation if you learn that a requirement was wrong. Date the changes. When the decision is made, the page becomes the record of why.
A realistic example of a must have list
Scans a pull request in under ten minutes on our largest service. Supports our two main languages and one framework each. Exports SARIF. Lets us baseline existing findings. Lets us run in our own network if needed.
Five lines, each testable.
Quick check
How long should the document be?
One page. Brevity forces priorities and makes vendors give direct answers.
Should I share it with vendors?
Yes, before the first call. It saves time on both sides and reduces demos built around features you do not need.
Safeguard's free scan at gold.safeguard.sh/scan can help you list the dependencies you will need to cover, and its SBOM scanning is generally available.
Sources
Last reviewed: 19 October 2026.
