I'm currently evaluating the role of GitHub Advanced Security (GHAS) in a compliance tech stack, specifically for SOC 2 Type II. My team is preparing for an audit, and we need to provide evidence for the "Security" and "Availability" trust service criteria.
From my initial analysis, GHAS provides tangible artifacts for several control areas:
* **Vulnerability Management (CC7.1):** Code scanning alerts and remediation histories can serve as evidence of periodic vulnerability scans and corrective actions.
* **Change Management (CC8.1):** Secret scanning alerts and the associated issue closure workflow demonstrate security controls over code changes.
* **Risk Assessment (CC3.2):** The dependency graph and Dependabot alerts can be mapped to ongoing vendor/supply chain risk monitoring.
However, I have questions about the practical implementation for audit readiness.
1. **Evidence Export:** Has anyone successfully scripted the extraction of alert timelines (creation -> remediation) and coverage metrics over a 6-12 month period? The UI is useful, but auditors typically require consolidated reports. I'm looking at the GitHub API endpoints for Code Scanning and Dependabot.
2. **Coverage Gaps:** How did you address the fact that GHAS primarily covers code *within* GitHub? For a complete SOC 2 scope, you must demonstrate coverage over all deployed systems. Did you supplement GHAS with SAST/SCA tooling for infrastructure-as-code or other repositories?
3. **Policy Configuration:** Were specific GHAS policy settings (e.g., code scanning severity thresholds, secret scanning patterns) cited by your auditor as required controls? I'm trying to determine if default settings are sufficient or if we need a hardened, organization-wide configuration.
My goal is to treat GHAS as a primary data source, not a silver bullet. I'm interested in concrete experiences integrating its outputs into a compliance framework.
BenchMark
Great breakdown. The mapping to specific CCs is super helpful.
On the evidence export part, I've heard the API is the way to go for those reports. Did you run into any rate limiting issues when pulling the historical data? That's my worry for a big repo.
Also, do you think using GHAS for Availability evidence is a stretch? I'm trying to connect it too, but it feels more security-focused.
I agree the API is the only viable method for bulk historical evidence. On rate limiting, you'll hit it with large repos. We scheduled daily incremental pulls over a month before the audit to build the dataset.
On availability, you're right. It's a stretch. GHAS is a security tool. For SOC 2 Availability, you need uptime logs, incident response timelines, and backup restoration tests from your hosting provider or platform engineering team. Trying to force GHAS data there weakens your evidence.
SLA is not a suggestion.
Totally valid question on the evidence export. We scripted exactly that for our last audit, but hit a major snag with the API's data model that your point about "alert timelines" flags perfectly.
The API gives you the current state of an alert and its *most recent* update events. For a true timeline showing the alert's full lifecycle over 6-12 months, you need to pull the alert history for every single alert ID. That's a separate API call for each one. With thousands of alerts, that multiplies your requests and complicates the script. We ended up stitching together the main alert list with the history endpoints, which was more complex than we'd hoped.
One more thing on your mapping, which is spot on: we found that for **CC7.1**, auditors really wanted to see the *policy* behind the scans, not just the data. So we paired our GHAS reports with a one-pager documenting our scan frequency, severity thresholds for breaking builds, and the role responsible for review. That closed the loop for them.
Try everything, keep what works.