The first time we needed yesterday's CodeQL findings for a tracking ticket, I clicked through the Code Quality UI for about ten minutes, copied a rule name, opened a new tab, and gave up trying to keep my place. The dashboard was right there, the data was right there, and the only path between it and Jira was my own attention span. That little annoyance just got an escape hatch.
GitHub's Changelog on June 23 announced two new read-only REST endpoints for Code Quality findings, both in public preview:
-
GET /repos/{owner}/{repo}/code-quality/findings, which lists findings for a repository with filtering and pagination support. -
GET /repos/{owner}/{repo}/code-quality/findings/{finding_number}, which returns the details for a single CodeQL finding.
The endpoints are available on github.com today and are not yet available on GitHub Enterprise Server. GitHub describes the intent in plain terms: broader access to Code Quality results, with explicit mention of supporting "tooling and agentic remediation workflows."
Why a read endpoint is a bigger shift than it sounds
Since Code Quality entered preview, the findings have been visible mostly in a place a human pointed a browser at. That is fine for a reviewer in the moment. It is not fine for any workflow that wants to do something with a finding the next morning: open a ticket, tag the right team, ship a metric, gate the next release on a trend rather than on the absolute count.
A read API turns the dashboard into a queryable surface. The pipeline can ask the same questions the UI already answers, on its own schedule, with its own filters. That is what a CI/CD primitive actually looks like in practice: a small piece of data that lots of other automation can lean on.
Wiring it into a job
A first job is usually some flavor of "list the findings that landed on this repo, then post them somewhere." The shape is roughly this:
curl -sSL \
-H "Authorization: Bearer $GH_TOKEN" \
-H "Accept: application/vnd.github+json" \
"https://api.github.com/repos/$OWNER/$REPO/code-quality/findings?per_page=100"
The single-finding endpoint slots in when something wants the full body: a remediation agent, a ticket bot, a custom severity dashboard. The exact response schema is not something I will quote here, because the changelog does not, and inventing field names in print is a great way to send someone down a debugging hole that is not their fault. The honest move is to fire one call, save a response, and write your code against the shape you actually got back.
Rough edges to plan around
Public preview is the headline caveat, and the practical one too. Field names may move before GA, so any pipeline that depends on this should keep the integration in a job you would not mind disabling for a week, log unknown fields rather than crash, and stay willing to redo the parsing pass.
The GitHub Enterprise Server gap matters if your code lives there. The endpoints are github.com only at announcement time, which means a multi-instance shop will have one pipeline that can call the new API and another that cannot. Worth knowing before you write a script that assumes both.
The endpoints are also read-only. Triage state, dismissals, and remediation status are not part of this preview. If your dream is a closed loop where an agent both reads a finding and marks it fixed, this is the first half of that loop.
How the wider category handles the same job
Programmatic access to static-analysis findings is not a new idea. Most established code-quality and SAST products have offered REST or GraphQL surfaces for years, often with richer write paths than what GitHub is shipping today. What is new here is location: the engine producing the finding, the merge gate that may block on it, and the API exposing it now all live on the same platform. For teams already standardized on one provider for code hosting, that closeness is the whole point. For teams that deliberately keep their scanner separate from their host, it is a reason to keep the alternative around.
What I am watching next
Two things. Whether the GA cut adds anything to write back: a way to mark a finding triaged, or attach a remediation note, would expand what kinds of automation are possible. And whether GitHub Enterprise Server gets the endpoints before too long. The on-prem audience is where the agentic-remediation pitch will get its hardest stress test, and a preview that stops at the github.com perimeter is going to feel half-built until that gap closes.
