A two week ASPM proof of concept should test five things: whether your real scanner data imports cleanly, whether duplicates collapse, whether findings reach the right owner, whether the priority order makes sense to engineers, and whether you can get your data back out. Anything else can wait.
What a proof of concept is for
A proof of concept answers one question: will this work on our data with our people? It is not a demo with your logo on it. Vendors can make a polished demo easy to watch, so use your own repositories and your own tickets.
Decide before you start who signs off, what the pass line is, and what you will do if the answer is no.
The checklist
| Days | Test | Pass looks like |
|---|---|---|
| 1 to 2 | Connect source control and two scanners | Repositories and findings appear without manual fixes |
| 3 to 4 | Deduplication | Same issue from two tools shows as one |
| 5 to 6 | Ownership | Most findings carry a team name |
| 7 to 8 | Prioritization | Engineers agree the top ten are the right ten |
| 9 to 10 | Workflow | A ticket opens, updates and closes with status in sync |
| 11 to 12 | Policy | A rule blocks or warns on a test pull request |
| 13 to 14 | Exit and review | Data export works, decision meeting held |
How to run each test
Ingestion. Pick repositories with known issues. Compare the platform's count against what the source tool says. A mismatch is not automatically a failure, but you need an explanation.
Deduplication. Choose five issues you know appear in more than one tool. Check each one by hand.
Ownership. Take a random sample of twenty findings and ask whether the named team is right. Aim to learn how it figures out ownership, not just the percentage.
Prioritization. Show the top ten to two engineers who do not work in security. If they disagree with the order, ask why. Their reasons are the real requirements.
Workflow. Create, change and close a ticket. Confirm the status in both places.
Policy. Open a test pull request that adds a dependency you have decided to ban. See what the developer sees.
Exit. Ask for a full export of findings, ownership and accepted risks. A platform you cannot leave is a bigger commitment than you may realize.
Things to write down
- Every manual step you had to take. Manual steps are hidden cost.
- Every question the vendor could not answer in the session. Ask for written answers.
- Which team members actually logged in after day three.
Common mistakes
Testing on one clean repository. Letting only the security team judge usability. Skipping the exit test because it feels negative. Extending the proof of concept without a new question to answer.
A worked example of one test: deduplication
Take day three and four of the plan. Suppose the dependency scanner and the image scanner both report the same vulnerable library in one service. Here is how you could run the test.
- Choose the service and note the library, version and both findings in a small sheet before connecting anything.
- Connect both scanners and wait for the import.
- Search the platform for the library name.
- Record what you see: one record with two sources, two records, or a record missing entirely.
- If it shows two records, ask the vendor why, and whether a setting changes it.
Record the result as pass, partial or fail, with a sentence of explanation. Partial results are common and useful. A partial pass with a clear reason can be fine. A pass nobody can explain is worth questioning.
A scoring template for the final meeting
| Test | Result | Evidence | Open question |
|---|---|---|---|
| Ingestion | Pass, partial or fail | Counts compared to source | |
| Deduplication | Five known duplicates checked | ||
| Ownership | Twenty sample findings | ||
| Prioritization | Top ten reviewed by two engineers | ||
| Workflow | One ticket lifecycle | ||
| Policy | One test pull request | ||
| Exit | Export file opened |
Bring this table to the decision meeting. It keeps the discussion on evidence and stops the vote from being swayed by one impressive demo screen.
What to prepare before day one
- Test accounts and access, requested a week ahead.
- A list of repositories, including one noisy one and one quiet one.
- Two engineers who agree to spend an hour each reviewing results.
- A shared document for notes, owned by one person.
- A named person who can stop the proof of concept if it goes badly.
After the proof of concept
Write a one page summary the same week. Include what you tested, the result, the open questions and the recommendation. Send it to everyone who attended, and ask for corrections. A shared summary prevents the memory of the proof of concept from changing over the following months.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policies and gates, which map to the ingestion, prioritization and policy tests above. Begin with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a developer sees when a policy fails.
Quick check
Is two weeks too short?
For one use case on a few repositories it is enough. Longer pilots tend to drift without a decision date.
Who should be in the final review?
Security, at least one engineering lead, and whoever owns the budget.
What if the vendor wants to run the proof of concept for us?
Let them help with setup, but have your own people run the tests and judge the results. The point is to learn how it works in your hands.
Last reviewed: 19 October 2026.
