GitHub access reviews for repo permission audits

Make GitHub access reviewable, manageable, and cheaper.

When repository access stops fitting in your head, GitHub turns into a slow manual audit.

Plans & Pricing

Based on our operational model, teams with 300-700 repos typically save £3.8k-£9k per year in loaded engineering cost.

For many teams, repod closes the gap between GitHub Team and Enterprise.

Frequently Asked Questions

• How do I audit GitHub repository access?

  Start with repository ownership, team mappings, direct user grants, outside collaborators, and high-privilege access. repod turns that into an org-wide access audit instead of a repo-by-repo click exercise.

  For the manual review path, read the GitHub repo access audit guide or use the GitHub repository permissions audit checklist.

• How do I find direct repository access in GitHub?

  Direct repository access is any user-to-repo grant that bypasses the normal team model. repod helps surface those grants so admins can decide whether they are justified exceptions or access drift.

  For the model decision, read GitHub Team permissions vs direct repository access.

• How do I review GitHub team permissions?

  Review the teams attached to each repository, their permission levels, inherited access paths, and whether the mapping still matches ownership. repod exports and previews repo-team access so changes can be reviewed before apply.

  For the product workflow, read how to export, review, and apply GitHub repo-team access changes.

• How do I remove stale GitHub access after offboarding?

  Check org membership, team membership, direct repository grants, outside collaborators, service accounts, and old exceptions. The goal is to remove both the obvious access and the quiet access paths that outlive the person or vendor.

  For the process, read the GitHub offboarding playbook.

• How do I find outside collaborators in a GitHub org?

  Outside collaborators should be reviewed separately from staff teams because they often represent vendor, contractor, or temporary access. repod helps make those exceptions visible during access review.

  The GitHub repository permissions audit checklist includes outside collaborators, direct grants, and other common exception paths.

• Should everyone have write access to every GitHub repository?

  Usually no. Easy contribution is good, but blanket write access changes the risk model once repos use GitHub Actions, packages, deploy paths, and sensitive branch rules.

  A better pattern is fast, reviewable access for the right repo. For the detail, read why blanket GitHub write access is risky.

• Why not just use GitHub Teams?

  GitHub Teams can express the model. The hard part is reviewing and cleaning access across many repos and teams once direct grants and exceptions have built up. repod gives you one review surface, bulk edits, and a safer change path.

  For the access model decision, read GitHub Team permissions vs direct repository access.

• Why not use Terraform or internal scripts?

  Repod provides Terraform-like governance outcomes for GitHub access management without requiring teams to adopt GitHub-as-code. Terraform is better for engineering teams that want GitHub org resources fully declared in code. repod is better for teams that need visibility, audit evidence, access cleanup, compliance workflows, and safe guided remediation.

  For the lighter operating path, read how to export, review, and apply GitHub repo-team access changes.

• Is repod's YAML workflow similar to Terraform?

  It is similar in the narrow sense that YAML can describe desired access outcomes, and repod can preview and apply controlled changes. It is not Terraform: repod does not use Terraform state, providers, or a full GitHub-org-as-code lifecycle.

  Repod's YAML workflow is an operational control layer for team-repo permissions, team settings and hierarchy, team memberships, and direct-collaborator exceptions. The difference is that repod wraps those changes in review, risk warnings, RBAC, audit evidence, and compliance context.

• How does repod compare with gh-iga, github-org-manager, and safe-settings?

  Use gh-iga when you want a local scanner, github-org-manager when your org is ready for YAML-based org management, and safe-settings when continuous repository settings enforcement is the main job. repod fits when GitHub access policy needs a reviewable workflow: direct grants, private repo coverage, team ownership, delegated review, controlled cleanup, and audit evidence.

  Read the detailed comparisons: repod vs gh-iga, repod vs github-org-manager, and repod vs safe-settings.

• How does repod access GitHub?

  repod supports fine-grained GitHub PAT auth and GitHub App beta. Audit/read mode uses read-oriented access to org settings, repository metadata, members, teams, and repo-team permission state. Write mode is only needed when you ask repod to apply changes.

  repod operates on GitHub organization metadata and access-control state. It does not clone repositories or process source code contents in normal operation. For setup details, read the GitHub fine-grained PAT scopes for repod.

• How do we review changes before they land?

  repod is built around previewing repo-team changes before apply so you can inspect removals, new team mappings, and the exact changes that will be pushed back to GitHub.

  For the detailed workflow, read how to export, review, and apply GitHub repo-team access changes.

• Where can buyers review security information?

  Start with the Security, Subprocessors, DPA, Vulnerability Disclosure, Privacy, Terms, and Trust Pack pages.

  repod does not currently hold SOC 2, ISO 27001, or Cyber Essentials accreditation. The trust pages document the current controls without claiming external certification.