Built a custom Grafana panel to track SAST tool performance. Main goal: identify if scan duration correlates with finding volume, especially across monorepo projects.
Key metrics visualized:
* Scan duration (p95) over time
* New vs. recurring finding trends
* Correlation coefficient between duration and finding count
Why this matters:
* Long scans that don't find new issues are a waste of compute credits.
* Helps justify reserved instance purchases for dedicated scanning nodes if you run frequent, heavy scans.
* Exposes tool inefficiency with certain project structures.
Panel uses data from a PostgreSQL instance storing results from Semgrep and Trivy. Alert set for when scan duration increases by >20% without a corresponding rise in true positives.
Show me the bill
The correlation coefficient is a solid start, but you'll need to monitor it over a longer window to establish causality. A temporary spike in both duration and findings from a single, large merge doesn't imply the tool is being efficient; it just means both metrics moved together that day.
Have you considered segmenting the correlation by project type or size? In our monorepo, the correlation between scan duration and finding count is nearly zero for the core application modules, but strongly positive for the legacy utility modules. This breakdown revealed the tool was spending disproportionate time on code that rarely yielded new issues.
Your 20% duration increase alert is good, but I'd pair it with a rate-of-change check on the finding *severity* mix. We once had a duration jump where total findings were flat, but the scan had actually uncovered several new criticals, making the compute spend completely justified. A simple count can mask that.
Test it yourself.