Trying to prepare for a security audit and hitting a wall. I've tested a bunch of other SAST/SCA tools where this is a standard report, but I'm stuck on GHAS.
I can see suppressed alerts (dismissals) per repo via the API (`/repos/{owner}/{repo}/code-scanning/alerts?state=dismissed`). But I need a consolidated, organization-wide view.
* Is there a native way to get this, maybe in the Security Overview?
* Or is the only way to loop through every repo's API endpoint?
* If looping, any gotchas with pagination or rate limits?
This seems like a basic audit requirement, so I'm hoping I've just missed a feature. What's everyone else doing?
Demo or it didn't happen
Ah, the organization-wide suppressed alerts report. I've been down this exact audit path.
You haven't missed a feature, unfortunately. There isn't a native consolidated view for dismissals across the org. The Security Overview gives you active alerts, but the dismissed ones are siloed per repo. I ended up scripting it, looping through the repos.
On your gotchas: pagination is a must-handle, and the rate limits will bite you if you just hammer the API. Use conditional requests with `If-None-Match` headers where you can, and space out your calls. Also, watch out for the tool name parameter when fetching alerts. You'll want to specify the tool (`codeql` or whatever you use) to keep things consistent.
It's a bit of a chore, but once the script is built, you can run it for each audit cycle. I can share a skeleton if you get stuck.
Exactly. I've done the same script and hit the same walls.
> conditional requests with `If-None-Match` headers
This is the key for making it tolerable if you're running the script more than once per audit. Cuts the data transfer way down.
But the real question: what's the actual ROI of this report once you have it? For our audit, they just wanted proof that dismissals had a recorded reason (`dismissed_reason` field). The volume of data was less important than the process. Might be worth checking if a sample from your largest repos satisfies the requirement.
Ask me about hidden egress costs.
No native way, you're stuck with the API loop. The other comments covered pagination and conditional requests, but they missed the biggest cost: time.
That loop over every repo is O(n) API calls. If you've got hundreds of repos and strict rate limits, your script will run for hours. This directly hits your audit timeline and the engineer-hours billed to it.
You might consider running the collection as a background job over a few days and dumping the raw JSON to an S3 bucket first. Then process it into your report. It splits the work and gives you a cache for the next audit.
cost optimization, not cost cutting