So the VP is asking for "data-driven insights" into our application security posture. Naturally, this means someone has to build a dashboard. Semgrep itself gives you a nice JSON output, but staring at a terminal scroll by or a CI log isn't exactly boardroom material.
I got tired of the weekly manual "find, grep, awk, pray" routine for our team's Semgrep runs, so I threw something together. The goal was simple: track over time what rules we're triggering most, which repos are the noisiest (or most clean), and whether the "critical" findings are actually getting fixed or just aging like fine wine. All the usual vendor dashboards show you this *for their own platform*. I wanted ours.
The stack is straightforward: a scrappy Python script that parses the JSON output from `semgrep scan --json`, tosses the findings into a PostgreSQL database (time-stamped, repo-tagged, rule-categorized), and a Grafana instance on top to visualize it. No fancy SaaS, just our own infrastructure.
The immediate, somewhat depressing, insight? Our top five firing rules haven't changed in three months. We're either perfectly consistent or hopelessly stagnant. Also, the "high-severity" findings in the `dockerfile` ruleset are almost entirely in deprecated microservices nobody touches anymore. So much for "actionable intelligence."
The real value isn't in the pretty graphs—it's in being able to call out that we're wasting cycles on a rule that flags a "vulnerability" in a library we don't even use in production, or proving that Team A's "clean" repo is only clean because they've disabled half the rule set. It turns the abstract "we run Semgrep" into "here's what it's actually doing for us, and here's where it's just generating busywork."
If anyone else has gone down this path, I'm curious about the metrics you found useful (or completely useless). Bonus points for horror stories of misleading data.
cg
cg
Nice approach. That "consistent or stagnant" feeling hits close to home. Seeing the same top rules month after month is a powerful, if uncomfortable, piece of data to put in front of the team. It forces the conversation from "we have findings" to "why aren't these specific things getting fixed?"
Any thoughts on adding a simple metric for "mean time to remediate" for those high-severity docker findings? That's the number that really gets management's attention, turning a static dashboard into a tool for accountability. It can be a bit sobering to calculate, though. 😅
Keep it constructive.
Haha, "consistent or hopelessly stagnant" is painfully relatable. Love that you built this yourself instead of buying another SaaS panel.
I'm curious about the "scrappy Python script" part. Do you have it running on a schedule, like in a container on a cron job? I'm trying to think about the infra side for doing something similar.
Also, PostgreSQL for this is a great call. Way easier to query later than a pile of JSON files. Did you run into any issues with the schema changing between Semgrep versions?
Great question about the infra side. I'm using Apache Airflow to run it as a DAG on a weekly schedule. Honestly, I started with a cron job, but the dependency management and error alerts got messy fast.
I haven't hit a schema-breaking change yet, but it's a real concern. The script does some basic validation and will fail the pipeline run if certain expected top-level keys are missing, which at least gives us a heads up. Do you know if Semgrep publishes a formal schema spec for their JSON? I couldn't find one.
null