Alright, let’s set the scene. It’s year three of our latest “enterprise-grade” SAST tool, Checkmarx, and the pattern is as familiar as a recurring vulnerability. Security owns the console, the scans, and the sprawling PDF reports that get emailed into the void. Development, meanwhile, treats the findings like a black box—vaguely threatening, mostly ignored, and completely divorced from their actual workflow. The ticket backlog grows, security grumbles about “shifting left,” and everyone loses.
So, in a fit of pragmatic annoyance, we built something stupidly simple: a read-only web UI that lets developers query their own scan results. No security team gatekeeping, no waiting for a Jira ticket to be blessed, no deciphering which project corresponds to which repository in the labyrinth of our CI/CD pipelines. The premise was embarrassingly basic: if devs can’t easily see *their* problems, in *their* context, they will never, ever own the fix.
The core of it is just a thin layer over the Checkmarx API (which is, let’s say, “comprehensively documented” if you enjoy reading API specs as a form of meditation). We wrapped the common queries a developer would actually care about:
* “Show me all high-severity findings for the `backend-service` repo on the `develop` branch from the last scan.”
* “List every open CWE-89 (SQL Injection) across all my team’s projects, sorted by newest.”
* “Give me a diff of what was fixed between scan #451 and #452.”
We slapped a bare-bones filter interface on top—dropdowns for project/ branch/ severity/ state—and a table that shows the finding, the file path, line number, and a direct link to the code in GitHub. No approval workflows, no comment threads, no “assign to” fields. Just visibility.
The outcome, predictably, was that the friction of *discovery* was the real bottleneck, not the fixing. Once developers could self-serve the data, the number of “what does this mean?” queries to the security team dropped by about 70% in the first month. They started integrating the query links directly into their PR descriptions. The security team’s role shifted from being the nagging ticket-creator to being the consultant you ping when a finding is genuinely confusing or a false positive.
Of course, it’s not a silver bullet. It exposed other, more profound issues:
* The sheer volume of legacy findings we’d been ignoring became painfully, publicly visible, forcing actual prioritization conversations.
* Checkmarx’s project naming/grouping conventions, which made sense to a security analyst, were completely opaque to developers, requiring us to build a mapping layer.
* It highlighted how many findings were duplicates or variations of the same root cause, something the native UI buries.
In the grand tradition of CRM-hopping, the lesson is the same: the most powerful enterprise tool is useless if the end-user experience is an afterthought. You can have all the compliance checkboxes ticked, but if you haven’t reduced the time-to-context for the person who needs to act on the data, you’ve just built a very expensive, very sophisticated log. This little UI side-project probably did more for our actual remediation rate than the last two “mandatory secure coding” training modules combined.