To evaluate an application security posture management (ASPM) tool, run it on your own repositories for a fixed period and score it against questions you wrote before the demo: does it find what your current scanners find, does it merge duplicates, does it rank by real exposure, and does it get fixes into pull requests?
What is ASPM supposed to do?
ASPM is a category, not a standard. The idea is that most teams already own several scanners for dependencies, code, containers and secrets, and the problem is the pile of overlapping findings. An ASPM product collects results, removes duplicates, adds context such as whether code is reachable, and routes work to owners. Judge it on that job, not on the length of its connector list.
A four week plan
Week 1: baseline. Pick five to ten repositories that differ: one old and messy, one new, one with a large dependency tree, one with infrastructure code. Record what your existing tools report today, with counts by severity. Without a baseline you cannot tell whether the trial tool found anything new or just renamed it.
Week 2: coverage and deduplication. Connect the same repositories. Check whether the tool sees every finding your current scanners report. Then count how many distinct issues it shows against the raw total. Open ten merged findings and confirm they really are the same problem.
Week 3: prioritization. Take twenty findings the tool ranks as urgent and twenty it ranks as low. Have an engineer who knows the code check each one. You are measuring two things: urgent findings that were not real, and low findings that were. Ask the vendor how reachability or exploitability is decided and whether you can see the evidence.
Week 4: workflow and evidence. Ask it to produce a fix as a pull request for three findings. Review the diffs as you would a colleague's. Export the record an auditor would want: what was found, when, who accepted or fixed it. Confirm what leaves your environment and whether you can run without sending source out.
What to put in the scorecard
- Coverage against your baseline, in percent.
- Duplicates merged, with a sample check.
- False urgent and missed low, counted by a human.
- Pull requests that passed your own tests unchanged.
- Time from finding to owner assigned.
- Data handling: what is stored, where, and for how long.
- Whether AI features can be switched off or pointed at your own model.
Honest limits
A thirty day trial will not show you scale problems on your largest monorepo, or how the vendor behaves during an incident. Ask for references in a similar environment and ask what happens to your data if you leave. Be wary of any dashboard that improves your numbers by hiding findings rather than resolving them.
Safeguard offers reachability analysis and fix pull requests, and its CLI scans locally. Hold us to the same scorecard.
What to do
- Write the scorecard before the first vendor call.
- Choose repositories that include your hardest cases.
- Capture a baseline from current tools in week one.
- Have engineers, not only security staff, judge prioritization.
- Insist on an export of results and evidence you can keep.
- Decide the pass mark in advance, for example coverage at or above baseline and a clear drop in findings an engineer must read.
Quick check
Is ASPM a replacement for my scanners?
It depends on the product. Some orchestrate existing scanners and some include their own. Decide which model you want, because it changes cost, coverage and who owns the results.
How many repositories should a trial include?
Five to ten that differ from each other. Variety exposes more weaknesses than volume.
Sources
- NIST SP 800-218, Secure Software Development Framework
- OWASP Application Security Verification Standard
Last reviewed: 18 October 2026.
