Before day one of a security tool trial, prepare five things: a short list of repositories to test, the access the tool needs, named owners, written success criteria and a baseline of what you already know. Without these, the first week is spent on logistics instead of evidence.
Why prep matters
Trials rarely fail because the tool is bad. They fail because access arrives on day six, nobody knows which repository to scan, and the team cannot say whether a finding is new or already known. A few hours of preparation fixes most of that.
The five items
1. A representative repository set
Pick three to six repositories. Include one large and messy one, one new and clean one, and one in a language you worry about. Avoid choosing only your tidiest code. A tool that looks good on a tidy project tells you little.
2. Access, requested early
List what the tool needs and who approves it:
- Read access to source, or a way to upload an SBOM
- A service account for CI, with the narrowest scope that works
- Single sign-on or a trial login for each evaluator
- Network allowances if the tool runs in your environment
Ask for these a week ahead. Security teams are slow to approve security access, and that is as it should be.
3. Named owners and time
Write one name next to each activity: setup, triage, developer feedback, integration testing, final report. Also write down how many hours per week each person can give. If the answer is "when I can", the trial is underfunded.
4. Success criteria on paper
Agree the pass marks before you see results. For example: setup under one day, at least 80 percent of triaged findings judged useful, no build slowed by more than a set number of minutes. Numbers that you pick after seeing the tool will drift toward whatever it produces.
5. A baseline
Record what you know today. How many open vulnerability tickets? Which known issues sit in your repositories? Which scanner, if any, do you run now? A baseline lets you say "the tool found 12 issues we did not know about" and, just as important, "it missed two we did".
A one page prep sheet
| Item | Owner | Due | Done |
|---|---|---|---|
| Repository list | Eng lead | Day minus 7 | |
| Access requests | Security | Day minus 7 | |
| Evaluator accounts | Vendor | Day minus 3 | |
| Success criteria | Trial lead | Day minus 3 | |
| Baseline snapshot | Security | Day minus 1 | |
| Kickoff call booked | Trial lead | Day minus 1 |
Data handling questions to settle first
Before any code leaves your network, ask where scans run, what is stored, for how long and how it is deleted. Put the answers in writing. If you are in a regulated sector, your legal or risk team may need to see them before you start. See getting approvals before a trial in a regulated company.
A fast way to get a baseline
If you have no scanner today, a free scan from Safeguard gives a quick first view of dependency findings, which you can record as your starting point. If you do run a scanner, export its current results the day before you start.
Try it yourself
Use the demo to see what a dependency inventory looks like. Note which fields you would want in your own baseline, such as package, version and ecosystem.
Click through it at your own pace, or open it full screen.
Quick check
How many repositories should a trial cover?
Three to six is usually enough if they differ in size, language and age. More than that adds triage work without adding insight.
Do we need a baseline if we have no scanner?
Yes. Count open vulnerability tickets and list issues you already know about. Even a rough list lets you judge what the tool found and missed.
Last reviewed: 19 October 2026.
