188 vulnerabilities.
That's where we started.
After the modernisation, the jjwt migration, the targeted remediations, and the documented suppressions, here's where we ended up: 6 open findings.
All suppressed with documented reasons. 0 unaddressed.
But "188 to 6" is a headline, not a measurement.
This article is about what meaningful security posture measurement actually looks like — the metrics that tell a real story versus the ones that just make a dashboard look good.
Why Raw Finding Count Is a Weak Metric The most common way teams measure SCA progress is finding count.
Before:
188.
After:
6.
Improvement: 182 findings resolved. 97% reduction.
That number is real but it's also misleading in isolation.
Here's why.
If I had suppressed all 188 findings without fixing anything, my finding count would also be
6.
The dashboard would look identical.
The actual security posture would be unchanged.
Finding count measures activity, not outcomes.
What you need to measure is: What risk was actually reduced — not just what got closed What risk remains and why — the documented residual risk How the remediation was achieved — fix vs. suppress breakdown What the exploit exposure looks like — before and after exploit maturity These four dimensions together tell a story that a single number can't.
Metric 1: Risk Reduction by Severity The most important before/after comparison is severity distribution, not total count.
Severity Before After Fixed After Suppressed Remaining Critical 10 10 0 0 High 99 93 6 0 Medium 59 29 23 0 (7 in 4.x backlog) Low 20 0 20 0 Total 188 132 49 0 unaddressed Every Critical finding was fixed — not suppressed, fixed.
That's the number that matters most.
No Critical vulnerability was accepted as residual risk.
The 6 suppressed High findings are all in the "no known exploit" category with documented unreachability justifications.
The 23 suppressed Medium findings are split between test-scope dependencies and unreachable code paths.
What to say when presenting this: "We eliminated all Critical exposure and resolved 94% of High findings through active remediation.
The remaining 6 High findings are suppressed with documented justifications — unreachable code paths verified by codebase analysis — and have review dates set for Q2." Metric 2: Fix vs.
Suppress Breakdown This metric distinguishes genuine security improvement from metric manipulation.
Resolution Type Count % of Total Fixed — BOM upgrade 89 47% Fixed — targeted remediation 43 23% Suppressed — unreachable code path 23 12% Suppressed — no known exploit 18 10% Suppressed — test scope 9 5% Tracked — accepted residual risk 6 3% 70% of findings were actively fixed. 30% were suppressed with documented reasons.
Zero were closed without a reason.
The 47% resolved by BOM upgrade is worth highlighting specifically — it demonstrates the leverage of keeping framework versions current.
Nearly half the entire vulnerability backlog was resolved by a single architectural change.
What this tells a hiring manager or security team: You didn't just run a scanner and close tickets.
You made architectural decisions, did targeted remediations, and applied security judgment to suppression decisions.
The breakdown shows the difference.
Metric 3: Exploit Exposure Before and After Raw CVSS scores don't tell you how much real-world attack risk exists.
Exploit maturity does.
Before remediation: Exploit Maturity Count What It Means Mature (working exploit exists) 8 Anyone with the tool can exploit this Proof of concept 43 Requires effort but exploit path is known No known exploit 137 Theoretical vulnerability, no public exploit After remediation: Exploit Maturity Count Status Mature 0 All fixed Proof of concept 0 All fixed No known exploit 6 Suppressed with documentation Every finding with working exploit code was fixed.
Every finding with a published proof of concept was fixed.
The 6 remaining findings are all in the "no known exploit" category — the lowest practical risk tier.
This is the metric that matters most for communicating real risk reduction.
Going from 8 mature exploits to 0 means an attacker with a public tool can no longer trivially compromise this application.
That's a concrete, meaningful security improvement.
Metric 4: Priority Score Reduction Snyk's priority score (0-1000) combines CVSS, exploit maturity, reachability, and other factors into a single number per finding.
It's more nuanced than CVSS alone.
Before: Highest priority score was 919 (spring-web RCE, spring-context RCE, spring-boot-starter-security auth bypass — multiple findings at maximum score) After: Highest priority score among remaining findings is 329 — the Improper Handling of Case Sensitivity finding in spring-core that requires a major version upgrade to resolve and is suppressed with justification.
The maximum priority score dropped from 919 to
329.
The most critical attack vectors have been eliminated.
Metric 5: Dependency Health Score Beyond individual vulnerabilities, the modernisation improved the overall health of the dependency tree in ways that reduce future vulnerability accumulation.
Before: Spring Boot: 2.0.3/2.0.4 — released May 2018, EOL Spring Framework: 5.0.7 — released June 2018, EOL jjwt: 0.9.1 — released November 2018, unmaintained Java target: 1.8 — EOL for free Oracle support Dependencies: 8 manually pinned, no BOM After: Spring Boot: 3.2.5 — current LTS, actively maintained Spring Framework: 6.1.x — current, actively maintained jjwt: 0.12.0 — current, actively maintained Java target: 17 — current LTS Dependencies: BOM managed, version alignment enforced This isn't just about current CVEs.
A project on EOL dependencies accumulates new CVEs constantly as researchers continue to find vulnerabilities in old versions that never receive patches.
Moving to actively maintained versions means future CVE disclosures will have patches available.
The dependency health score is a leading indicator — it predicts future vulnerability accumulation, not just current state.
Metric 6: Mean Time to Remediate (Simulated) In a production environment, MTTR (Mean Time to Remediate) by severity is a standard AppSec programme metric.
For this project I can simulate what it would have looked like: Severity Discovery Date Remediation Date MTTR Critical (RCE) Day 1 — scan Day 3 — BOM upgrade 2 days Critical (Auth bypass) Day 1 — scan Day 3 — BOM upgrade 2 days High (jjwt) Day 1 — scan Day 5 — jjwt migration 4 days High (Tomcat) Day 1 — scan Day 3 — BOM upgrade 2 days Medium (MongoDB MitM) Day 1 — scan Day 7 — driver patch 6 days Average MTTR for Critical: 2 days Average MTTR for High: 3 days Average MTTR for Medium: 6 days Industry benchmarks for production systems typically target Critical remediation within 24-72 hours and High within 7-14 days.
This project would have met those benchmarks.
The Dashboard View If you were presenting this to an engineering team or security leadership, here's how the story looks in dashboard format: What These Metrics Don't Measure Honest measurement includes acknowledging the gaps.
Code-level vulnerabilities.
Snyk SCA scans dependencies, not your code.
The metrics above say nothing about whether the application code itself has injection vulnerabilities, authentication bypasses, or insecure cryptography.
That requires SAST — which is exactly what the SAST tool series was about.
Runtime behaviour.
A dependency can be vulnerable without being exploitable in a specific application's runtime configuration.
The metrics above are conservative — they count vulnerabilities as present even when compensating controls exist.
New vulnerabilities.
The scan represents a point in time.
New CVEs are disclosed daily.
Without a recurring scan schedule and a process to act on new findings, the posture degrades over time.
The metrics are only meaningful if they're refreshed regularly.
The MongoDB 4.x backlog.
The 6 tracked residual risk items from the MongoDB driver partial upgrade aren't reflected in these metrics.
They'r