To measure the return on application security posture management (ASPM), take a baseline before you start, then track a few operating numbers: triage hours per week, time to fix serious findings, share of findings that are real, and duplicate alerts removed. Convert hours to cost using your own rates, not a vendor average.
What problem is ASPM supposed to solve?
Teams run several scanners: code analysis, dependency checks, container and cloud scans. Each reports in its own format, with overlapping and conflicting results. Someone has to merge, deduplicate, assign and chase them. ASPM tools aim to collect results in one place, add context such as whether a component is deployed and reachable, and route work to owners.
There is no formal standard that defines ASPM, so scope varies. Check what a product does against the list above rather than relying on the acronym.
NIST's Secure Software Development Framework, SP 800-218, is a useful yardstick for outcomes. Its practices include reviewing code and identifying and confirming vulnerabilities on an ongoing basis, and responding to them. ROI is the cost of doing those things before and after.
Which numbers actually show a return?
Triage time. Hours the security and engineering teams spend per week reading, merging and sorting findings. Sample two typical weeks before the change and two after.
Time to fix. Median days from detection to closure, split by severity. Report the median and the slowest decile, because averages hide stuck items.
Signal share. Of findings handed to developers, what percent were accepted as valid and fixed. A rising share means fewer wasted developer interruptions.
Duplicate reduction. How many raw alerts collapse into how many unique issues. Count it, do not estimate it.
Coverage. Percent of repositories and services scanned by each required check. Return that comes from catching previously unscanned code is real but hard to price.
Escaped issues. Serious flaws found in production or by outsiders, per quarter. Treat with caution: counts are small and noisy.
How do you turn them into money?
Use cost per hour from finance for the roles involved, including loaded costs. Multiply hours saved per week by that rate and by working weeks. Subtract tool, integration and maintenance effort. Avoid adding in "breaches avoided" using industry cost averages, since the probability is not measurable from your data and the estimate becomes the argument.
Where you can, express benefits as capacity: "two engineers' worth of triage hours returned to feature work". Finance understands that, and it is harder to dispute.
A constructed example
A team of 40 developers receives 3,000 scanner alerts a month. Before the change, a security engineer and a lead spend 25 hours a week on triage. After consolidation and reachability filtering, they spend 9. The raw count falls to 900 unique findings, and the median time to fix high severity items drops from 31 days to 12. At an internal loaded rate of 90 per hour (invented for this example), 16 saved hours a week over 46 weeks is about 66,000 a year in capacity, before tool cost. Your figures will differ, and the method is the point.
How to check or apply this
- Pick five measures from above and record a four-week baseline now.
- Agree the definitions with engineering and finance before you start, such as what counts as fixed.
- Define the cost per hour with finance, and write down what the tool, setup and upkeep cost.
- Run the change on a subset of teams first so you have a comparison group.
- Re-measure after one full quarter. Short windows catch novelty effects.
- Report both the numbers and the caveats, including quality changes you could not price.
- Check that faster closure did not come from lowering the bar. Sample closed items for correctness.
Where can reachability help?
Reachability analysis checks whether vulnerable code in a dependency is actually called by your application, so that unreachable findings can be deprioritised. Safeguard includes reachability analysis, and it affects the signal share and triage time measures above. Test it against your own repositories before you count on a number.
Quick check
Should ROI include breaches prevented?
Be wary. You cannot measure what did not happen, and generic cost-per-breach figures invite disputes. Lead with measured time, capacity and fix speed.
How long before the numbers mean anything?
At least one quarter, with a baseline taken beforehand. Shorter windows mostly show onboarding effects.
Sources
Last reviewed: 18 October 2026.
