Source code access is one of the more consequential permission surfaces in a SOC 2 audit, and it's also one of the most commonly under-reviewed. GitHub organization permissions accumulate the same way most access does — someone gets added as an admin to unblock a task, a contractor's access outlives the contract, a former employee retains org-owner status because nobody remembered to check. The difference with source code is that the blast radius of an overlooked permission tends to be larger than most other systems.
Where GitHub's Native Access Controls Fall Short of Audit Evidence
GitHub gives you the raw data — organization members, team memberships, repository-level permissions, and org-owner lists are all queryable through the REST and GraphQL APIs. What it doesn't give you natively is a structured, point-in-time review workflow with a decision log per person, which is what a SOC 2 auditor actually wants to see when sampling source code access controls.
Teams often end up doing this review manually by exporting a member list to a spreadsheet once a quarter — a process that works until someone forgets, or until the spreadsheet drifts from what's actually configured in GitHub by the time the auditor asks for it.
The Review Pipeline We Build
// GitHub org access snapshot for quarterly review cycle
const { Octokit } = require("@octokit/rest");
const octokit = new Octokit({ auth: process.env.GITHUB_APP_TOKEN });
async function snapshotOrgAccess(org) {
const members = await octokit.paginate(octokit.orgs.listMembers, { org });
const owners = await octokit.paginate(octokit.orgs.listMembers, { org, role: "admin" });
const repos = await octokit.paginate(octokit.repos.listForOrg, { org });
const snapshot = [];
for (const repo of repos) {
const collaborators = await octokit.paginate(
octokit.repos.listCollaborators,
{ owner: org, repo: repo.name, affiliation: "direct" }
);
snapshot.push({ repo: repo.name, collaborators, isPrivate: repo.private });
}
return { members, owners, repoAccess: snapshot, capturedAt: new Date().toISOString() };
}
This snapshot feeds a review workflow that pairs the raw access data with HR status (via the same identity source used for other access reviews) to auto-flag terminated employees who still show up as org members, contractors past their engagement end date, and org-owner assignments that haven't been re-certified in the current cycle.
The Org-Owner Problem Specifically
Org-owner status in GitHub grants far broader capability than most individual repository roles — billing access, the ability to delete repositories, and the ability to modify security settings org-wide. Auditors increasingly ask specifically about org-owner sprawl because it's a common finding: teams start with two or three founding owners and never revisit the list as the team scales, leaving five or six people with full organizational control long after their role justified it.
Our review pipeline treats org-owner status as its own high-priority review track, separate from standard repository access, with a tighter recertification cadence than lower-privilege roles.
Handling Team-Based Permission Inheritance
GitHub's team structure lets permissions cascade from parent teams to child teams, similar to Snowflake's role inheritance problem — a person's actual repository access can be several team-memberships removed from what's directly visible on their profile. The pipeline resolves this by walking the team hierarchy for each member and producing an effective-repository-access list, not just a team-membership list, so the review actually reflects real access rather than an intermediate abstraction.
Evidence Output for the Audit
Each review cycle produces a structured artifact: point-in-time snapshot of members, teams, and effective repository access; the reviewer's decision (retain, revoke, escalate) per flagged item; and a remediation timestamp showing when a revoke decision was actually executed in GitHub. This closes the loop auditors specifically test — not just that a review happened, but that flagged issues were actually fixed within a reasonable window.
This review pattern extends naturally from the approach we take in privileged access review automation for AWS admin paths, part of our broader security automation capability.
Book a technical call to talk through your specific GitHub org structure: 907-841-8407 or contact@rutagon.com.
See what an Access & Credential Governance Diagnostic finds in your environment →
Frequently Asked Questions
Does this require a GitHub Enterprise plan?
No — the review pipeline works against the standard GitHub REST/GraphQL APIs available on Team and Enterprise plans; Enterprise Cloud adds SCIM support that can extend automated deprovisioning further, but the review-and-evidence layer works without it.
How often should GitHub org access be reviewed for SOC 2?
Quarterly is the common cadence auditors expect, matching most other access review controls, though org-owner status specifically benefits from tighter review given its blast radius.
Can this catch access granted through GitHub Apps or personal access tokens, not just human users?
Yes, with an extension — GitHub App installations and their granted permissions, along with active PATs and fine-grained tokens, can be pulled into the same review pipeline as a separate machine-identity track.
What happens when someone is flagged but their access is still legitimately needed?
The reviewer's decision log captures "retain" with a justification note, which becomes part of the audit evidence showing the access was actively reviewed and deliberately kept, not just overlooked.
Does this integrate with our existing GRC platform, or is it a standalone tool?
It's built to export into whatever GRC platform you already run (Vanta, Drata, Secureframe) as structured evidence, rather than replacing your compliance tooling.