Pick the single problem that costs your team the most time each week, such as duplicate findings, unclear owners, or an unmanageable backlog, and scope the ASPM pilot to that. One use case with a before and after number beats a broad pilot that proves nothing.
What a use case is, and why the first one matters
A use case is one job you want the platform to do for a named team. "Reduce the number of tickets that arrive twice" is a use case. "Improve our posture" is not.
The first pilot sets expectations for everything after it. If it is vague, people judge the tool on feel, and feel is dominated by whichever dashboard looks busiest. If it is narrow, the result is a number someone can defend in a budget meeting.
Four candidates worth considering
| Use case | Pain it addresses | What you measure |
|---|---|---|
| Deduplicate findings | The same flaw reported by several tools | Count of unique issues versus raw findings |
| Route to owners | Tickets sit in a security queue | Share of findings with a named team |
| Cut the noise | Developers ignore the list | Findings left after exploitability filtering |
| Gate new code | Old problems keep returning | Policy violations caught before merge |
Most teams have all four problems. Choose the one a senior engineer would name first if you asked them what slows remediation down.
A simple way to choose
- Ask three engineers and two security staff to name their biggest time sink in remediation. Write the answers down.
- Pick the answer that appears most often and that you can count today.
- Record a baseline for it from the last 30 days, using your current tools and tracker.
- Pick two or three repositories or services that are representative, not the cleanest ones.
- Write the success line in advance, for example "at least half of findings carry an owner after two weeks."
Step three is the one teams skip. Without a baseline, any result is an anecdote.
What to leave out of the first pilot
Leave out integrations you do not need yet, executive dashboards, and compliance mapping. They are real needs, but they pull the pilot toward demos rather than evidence. Add them in the second phase once the core job works.
Also avoid the temptation to test every scanner connection. Pick the two or three sources your team already trusts and see whether combined data behaves sensibly.
How long it should run
Two to four weeks is usually enough to see whether a use case works. Shorter than that and you only see a clean import. Longer and the pilot turns into an unpaid rollout with no decision date. Set the decision date before you start.
A worked example
Consider a hypothetical company with eight product teams, three scanners and one security engineer. The security engineer interviews five people and hears the same complaint three times: "I get two tickets for the same library and nobody tells me which one is real."
That points to deduplication as the first use case. Here is how the pilot could be scoped.
| Item | Choice |
|---|---|
| Use case | Collapse duplicate dependency findings |
| Repositories | Three services, one old and large, one new, one mid sized |
| Baseline | Raw findings last month, unique issues after a manual count of a sample |
| Success line | Raw to unique ratio is visible, and duplicate tickets drop for the pilot teams |
| Duration | Three weeks, decision meeting booked on day one |
| Not included | Executive reports, compliance mapping, new scanner connections |
The numbers in the table are placeholders. The point is the shape: one problem, a named sample, a way to count, and a date.
What to do when the pilot finds a different problem
Pilots often surface something you did not plan for. In the example above, the team might discover that half the findings have no owner at all. That is useful. Write it down as a finding of the pilot, not as a failure, and decide whether it becomes the second use case.
Resist changing the success line halfway through. If you do change it, record the new line, the date and the reason, so that the final decision is honest about what was tested.
A scoring sheet for choosing between candidates
If the interviews leave two or three candidates, score them quickly on four questions, one point each:
- Can we measure it today with data we already have?
- Does a named team feel the pain weekly?
- Can it be tested on three repositories or fewer?
- Will a good result change a decision, such as renewal of a tool or a hiring request?
A use case that scores four is a strong first choice. One that scores two probably needs more thought before you commit time to it.
Who should be in the room
Include at least one engineer who will receive findings, one security person who will administer the tool, and one manager who can say yes or no at the end. If the manager is missing at the start, the pilot will end with a nice report and no decision.
Where Safeguard fits
If your first use case is noise reduction, Safeguard provides reachability analysis and dependency scanning, plus policies and gates for the gate-new-code case. You can try a free scan at gold.safeguard.sh/scan to see what your own repositories look like first.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the finding count changes once reachability is taken into account.
Quick check
Should the pilot include every repository?
No. Two or three representative repositories are enough to test one use case, and they make the baseline easier to measure.
What if two use cases tie?
Choose the one you can measure today with existing data. The other can be the second phase.
What if nobody can agree on the biggest pain?
Run the scoring sheet above with the whole group and pick the top scorer. A quick, imperfect choice beats a long debate, and the second candidate can follow.
Last reviewed: 19 October 2026.
