As a team that has historically managed cloud infrastructure costs with a high degree of granularity, we found the transition into application security compliance presented a similar challenge: a lack of transparent, actionable metrics. Our procurement of Veracode left us with a platform that was effective at finding flaws, but our internal stakeholders lacked visibility into the operational tempo, cost efficiency, and progress trends of our Software Security Program (SSP). To address this, we built an internal metrics dashboard that pulls data from Veracode's APIs, which we are sharing here for community critique and inspiration.
Our primary objectives for this dashboard were to move beyond the simple "pass/fail" status and answer more nuanced business questions:
* What is the actual velocity of flaw remediation across different business units?
* Are we optimizing the cost of our Veracode scans (e.g., are we running excessive manual scans when policy could be tightened)?
* What is the trend in flaw density (flaws per MB of code scanned) over time, and how does it correlate with developer training initiatives?
* Which application categories consistently exhibit the highest rates of Critical/High severity flaws?
The dashboard is built using a combination of AWS services (reflective of our core expertise), but the pattern is portable. We extract data nightly using a scheduled AWS Lambda function written in Python that calls the Veracode APIs. The data is transformed and loaded into an Amazon Aurora PostgreSQL instance. Grafana is used for visualization.
Below is a simplified version of our key data aggregation query, which calculates a "Remediation SLA Adherence" metric per business unit. This looks at flaws with a status of `OPEN` or `REOPENED` and determines if they are past their policy-defined SLA deadline.
```sql
WITH sla_violations AS (
SELECT
a.business_unit,
COUNT(DISTINCT f.issueid) as flaws_past_sla
FROM veracode_facts.flaws f
JOIN veracode_dims.application a ON f.app_id = a.id
JOIN veracode_dims.policy p ON a.policy_id = p.id
WHERE f.status IN ('OPEN', 'REOPENED')
AND f.severity IN (4,5) -- Critical and High
AND f.discovered_date Application -> Severity 5/4 Flaws.
The implementation has allowed our FinOps and AppSec teams to have data-driven conversations about resource allocation for remediation sprints and has provided clear evidence for adjusting scan policies to reduce costs without compromising security posture. We are interested in hearing how others have approached measuring the operational efficiency and ROI of their Veracode implementation. Specifically, are there other key performance indicators (KPIs) or data points you have found instrumental that we may have overlooked?
-cc
every dollar counts
This is a really interesting approach, and I think you've hit on a key pain point that many teams face with SAST platforms. The move from simple compliance gatekeeping to measuring operational health and cost efficiency is a huge step forward for any security program.
I'm particularly curious about how you're handling the data normalization for cost optimization, especially around differentiating necessary policy-driven scans from habitual or redundant ones. Have you found the Veracode API data granular enough to make that distinction clearly, or did you have to layer in additional contextual data from your CI/CD pipeline? I've seen teams struggle to get a clean signal there without that extra integration.
Also, tracking flaw density as a trend is brilliant, but I hope you're also considering the potential lag between a training initiative and its visible impact on the codebase. That correlation can be tricky to prove without controlled release cohorts.
Stay curious.
Great questions. The API data alone isn't sufficient for cost attribution. To classify scans as necessary or redundant, we had to correlate the scan metadata with our CI/CD pipeline's event logs. Without that, you can't differentiate between a PR-triggered scan and a manually re-run scan of the same commit, which skews the cost-per-fix metric significantly.
On your point about training impact lag, that's critical. We graph flaw introduction rate against training completion dates, but you're right, the signal is noisy. We've started tagging features developed by recently trained teams to create those controlled cohorts, though it's a manual process. The dashboard shows correlation, but we're careful not to present it as direct causation.
CloudCostHawk
Your point about tagging cohorts manually really resonates. We tried something similar to track training ROI and the overhead became a blocker for adoption. Teams just wouldn't keep the tags updated, so the data aged poorly.
Have you considered using your Jira/planning tool's team field as a proxy? It's noisier, but it auto-populates and gives you a directional, if imperfect, view of which groups are improving over time.
Moving beyond pass/fail to focus on velocity, cost optimization, and trended flaw density is exactly the mindset shift we try to encourage here. It transforms security from a checkbox to a managed business process.
I'm particularly keen on your goal to track remediation velocity by business unit. In my experience, publishing those comparative metrics internally can be a double-edged sword. It creates healthy competition if the culture supports it, but can also lead to gaming the system where units delay scanning to artificially inflate their fix rates. Have you built any safeguards against that into your dashboard logic?
Also, linking flaw density trends to training is powerful, but the lag and noise can make it a hard story to tell. How are you planning to visualize that correlation for stakeholders without implying a direct cause-and-effect?
—HR