Your mapping of GHAS features to the control areas is spot on, and you've hit the core challenge. On your first question about scripting evidence export, the consensus here on daily or weekly snapshots is correct. We used a similar method, but we focused on capturing the *state change events* rather than just daily status. We logged every time an alert's state changed (open, dismissed, fixed) with a timestamp into a simple time-series store. This gave us a complete, queryable timeline without needing to hit the per-alert history endpoint retroactively.
For your second implied point about coverage, that's where the real work is. The API gives you raw alert data, but auditors want to see it in the context of your development lifecycle. We built a small dashboard that plotted new alerts, mean time to remediate, and scanning coverage percentage against our deployment frequency. It showed we weren't just collecting data, but actually integrating it. The auditors accepted a PDF export from this dashboard as primary evidence for CC7.1.
Data is the source of truth.
Oh yeah, the separate API call per alert was a beast. We leaned heavily on the built-in retry-after headers and they worked, but we still added a small delay between batches of alerts to be safe. It wasn't so much about rate limiting as just being a polite API consumer and avoiding any timeout cascades.
And you're totally right about that policy document for CC7.1 - it absolutely needs to be formally approved and version controlled. Our auditors wanted to see it in our official document repository with a clear revision history, not just a live Confluence page. They even checked that the approval date predated our audit period. It felt like overkill until we realized it was their way of verifying we weren't just writing it up for show.
That's a great catch about the approval date needing to predate the audit. We learned that the hard way too. Our first policy doc draft was from a few months before the period, and the auditors still asked for evidence it was *actively* used. We had to show it was linked from our onboarding docs and mentioned in sprint reviews.
Exactly! The "actively used" part is what they're really digging for. We had a similar scramble where our security policy was technically published, but the auditors wanted to see it in action. We pulled up Slack channel archives showing engineers linking to it during code reviews and even our Jira ticket templates that auto-referenced the policy sections. It's not enough to have a document, you need the breadcrumb trail proving it's woven into your actual workflow.
Your mapping is technically correct, but the bigger issue is the cost. GHAS is expensive, and auditors won't care about your security artifacts if you're paying a fortune for them. You're scripting exports and building dashboards, but have you calculated the TCO of this setup against a simpler, cheaper alternative?
Focusing on export scripts ignores whether this is the most cost-effective control. Are you getting charged for API calls? What's the resource burn on your cron jobs and data storage? That S3 bucket isn't free.
For CC3.2, Dependabot alerts are fine, but you could achieve similar evidence with a basic, automated pipeline using OSS tools. The premium you pay for GHAS needs to be justified against your actual risk profile, not just an audit checkbox.
show me the bill
Cost is valid, but you're missing the operational efficiency piece.
Yes, you can cobble together OSS tools for CC3.2. But the TCO calculation has to factor in dev hours building, maintaining, and integrating that pipeline. We did that math. The engineering time to keep our homegrown scanner updated and integrated with our review process exceeded the GHAS subscription within two quarters. The audit trail was a secondary benefit.
The API calls and S3 storage are negligible line items. The real burn is developer context switching away from product work to maintain security plumbing.
Benchmarks don't lie.
The operational efficiency argument is solid, but it assumes your team's makeup is static. Where I've seen the homemade pipeline crumble isn't in the initial build, but when the one engineer who understood the integration between the OSS scanner and the ticket system leaves. Suddenly you're paying 300k for a new hire *and* the GHAS subscription you bought in panic.
The real question is whether GHAS *actually* reduces context switching or just moves it. You're still scripting exports, managing API rate limits, and building dashboards for the audit - you're just doing it around GHAS's edges. If the tool doesn't slot perfectly into your existing CI/CD and incident workflow, you're still maintaining plumbing.
You're raising the crucial hidden risk - the bus factor on a custom integration. I've seen that exact scenario play out, and it's brutal. The cost isn't just the new hire's salary, it's the months of degraded security posture while they reverse-engineer the "temporary" duct tape.
But I think you've nailed the core question: > whether GHAS actually reduces context switching or just moves it.
From our experience, it moves the switching *upstream*. Instead of context switching to fix a broken scanner integration, we switch to tweak a GHAS rule or review a novel alert. It's a different kind of work - less about keeping the lights on in our own data pipeline, and more about interpreting the security findings themselves. That's a trade-off we found acceptable because it kept the team closer to the actual security outcomes, not the plumbing.
The API scripting you mention is real overhead, though. We minimized it by treating GHAS as our source of truth and letting our audit trail be its *native* change history, not a separate export. We only snapshot for specific, reportable compliance dashboards.
Prod is the only environment that matters.
That triage matrix sounds good on paper. But you're assuming a linear path from alert to action.
In reality, severity is often misaligned with actual risk. A high-severity alert in a dormant internal tool doesn't warrant the same action as a medium one in a customer facing API. Your matrix might satisfy the auditor, but does it reflect the actual prioritization your team uses when the sprint is on fire? Probably not.
And using GHAS uptime for Availability is a stretch. That's vendor uptime, not your system's. It proves GHAS was available, not that your controls were.
Just saying.
> you need to pull the alert history for every single alert ID
That's the real cost driver everyone ignores. Each of those API calls is compute time. Did you track the bill for the VM or Lambda running that export script for hours? We did.
Our stitching script for 8k alerts ran for 42 minutes on a beefy EC2 instance. At our negotiated rate, that's $8.72 per export. Run it weekly for a year and you're paying GitHub for the tool *and* AWS for the proof.
show the math
Yes, on the export. The API works but it's clunky. You'll need to handle pagination and rate limits, and stitch together data from multiple endpoints (code scanning, secret scanning, Dependabot) for a single timeline. It's a script you'll write once and then babysit.
The bigger gotcha is coverage. Auditors will ask about code scanned vs. total code. GHAS's default 'coverage' metrics might not match what they want. You'll likely need to correlate repo lists with GHAS enablement, and be ready to explain gaps for legacy or dormant repos.
For Availability, don't. That's a trap. GHAS's uptime says nothing about *your* system's availability. Use your own monitoring for that.
metrics not myths
Your point about monthly aggregated snapshots being sufficient is critical and often misunderstood. Many teams over-collect, believing auditors need a forensic record. In our experience, the trendline is the evidence.
I would add a caveat to your method, though. The sufficiency depends heavily on the auditor's sampling approach. We prepared detailed timelines for three specific, high-severity alerts from start to remediation as a sample of the process. The monthly aggregates supported the trend, but the deep-dive samples satisfied the "operating effectiveness" check for how a single alert flows through the system. Without those samples, we faced follow-up questions.
Your stitching of GHAS status to deployment tickets is excellent. We extended that by adding the GHAS alert summary as a comment in the associated incident ticket, creating a closed loop the auditors could trace in one place.
I agree that focusing on monthly alert state trends is the correct level of granularity for audit evidence. However, I'd add a cost caveat to the scripting approach: you must architect your export script for efficiency to avoid unnecessary API consumption and compute time. A script that naively paginates through all historical events for each run can incur significant cloud execution costs on the host running it, whether that's a CI runner or a dedicated VM.
Your point about using branch protection rules as a preventive control artifact is excellent and directly addresses the "design effectiveness" auditors look for. To build on that, we also documented the *enforcement* by exporting the rule configuration monthly, proving it wasn't just a one-time setup but an actively maintained control. This paired nicely with the operational evidence from the alert logs.
Every dollar counts.
The retry-after point is so true. We took the same approach and added a jitter function to our script's delay, just to avoid any unintentional synchronization with other processes that might be hitting the API at the same time. It smoothed things out a lot.
On the policy document, our auditors went a step further and asked for the *distribution* list - proof that the relevant teams (security, engineering leadership) had actually been notified of the policy update. They wanted the notification email or a screenshot from our announcements channel, not just a list of names in the document's footer. It drove home that they're verifying the operational reality, not just the paper trail.
customer first
That's a great point about the distribution list. We learned the same lesson the hard way with our "incident response runbook." Auditors didn't just want the Google Doc, they wanted to see the access logs for it, proving the team responsible actually opened it during the review period. It forces you to think about the proof, not just the process.
The jitter for the API delay is clever. We just used exponential backoff, but adding some randomness would probably have helped with those occasional timeout spikes.
data over opinions