Security check

GitHub repo permissions: know exactly who can push to your code

Over time, admin and write access accumulates on the wrong people, former employees and outside collaborators. We map permissions per repo and show where least privilege breaks down.

Run a free domain scan All checks →
Relates to: ISO 27001 · A.5.15 / A.5.18 access control SOC 2 · CC6.1–CC6.3 logical access NIS2 · art. 21 — access control CIS · Controls v8 — 6

What we check

We read your GitHub org's access model: which teams and people hold admin, maintain, write, triage or read per repo, which outside collaborators are invited, and whether permissions are set directly on users instead of via teams.

Why it matters

Excessive access is the silent risk: one compromised key with admin on the wrong repo is enough to plant backdoors or exfiltrate code. Least privilege is a core control in ISO 27001, SOC 2 and NIS2 — and the most commonly missed in practice.

How Security Guru tests it

Common mistakes

  • Permissions set directly on users instead of via teams — impossible to oversee
  • Outside collaborators left long after the engagement ended
  • Every developer has admin 'for convenience'
  • No periodic access review of who has what

What you get in the report

  • Permission map per repo — who has admin/write, green/red
  • Outside collaborators and excessive admin rights
  • Recommended team-based baseline and a cleanup list
  • Mapping to SOC 2 CC6 / ISO A.5.15 / NIS2

FAQ

Do you change anything in our org?

No — we only read permissions via the GitHub API. You do the cleanup from our prioritised list.

What token is needed?

A read token with org and repo administration read. We never write.

Do you cover team hierarchies?

Yes — we compute the effective permission even when inherited via nested teams.

Want to know your status?

Run a free scan or order a full Security Assessment — prioritised, not noise.

Run a free domain scan