Topic 65

Repository and Org Administration

Security

Access control on GitHub scales through teams and roles, not through per-user grants. You assign repositories to a team, give the team a role, and then manage people by changing team membership — so onboarding and offboarding happen in one place instead of repo by repo. Per-user grants feel simpler at three people and become unmanageable at thirty.

Around that sit org-level policies that set the guardrails — who can create repositories, which actions are allowed to run, whether 2FA is mandatory — and the audit log, which is the record of who did what. Administration is mostly the discipline of setting these defaults tightly and then watching the log.

Repository Roles

GitHub offers five repository roles in increasing power: Read, Triage, Write, Maintain, and Admin. The operating principle is least privilege — grant the lowest role that lets someone do their job. Most contributors need Write; reserve Maintain for those who manage settings short of destructive ones, and Admin for the few who genuinely administer the repo.

Teams

Teams are nested groups that mirror your org structure, and they are the unit access should attach to. Give a team a role on a repository and membership controls who has that access, so a single membership change grants or revokes correctly everywhere the team is used. Nesting lets a parent team's access flow to child teams without re-granting.

Org Policies

Org-level settings are the guardrails that individual repos inherit: member privileges, default repository visibility, required two-factor authentication, and the allowed-Actions and runner policies. These are where you prevent whole classes of mistakes at once — for example, defaulting new repos to private so no one accidentally publishes source, or requiring 2FA so a phished password is not enough to take over an account.

Branch and Tag Protection / Rulesets

Protections like required reviews, required status checks, signed commits, and linear history can be enforced as rulesets at the org level rather than configured per repository. Org rulesets stop the drift where one repo quietly lacks the review requirement everyone assumes is universal — the rule is defined once and applies across the matching repositories.

Audit Log

The audit log is a searchable record of administrative and security events: permission changes, token creation, policy edits, repository visibility changes. It is exportable for compliance and is the first place you look during an incident to reconstruct who changed what and when. A guardrail you never review is a guardrail you cannot trust.

Common Mistakes

Granting individuals Admin on repos instead of using teams with scoped roles — access sprawls and offboarding misses people.
Defaulting new repositories to internal or public visibility org-wide when they should be private, risking accidental source disclosure.
Not requiring 2FA at the org level, leaving a phished or reused password as a direct path to account takeover.
Leaving the Actions policy at "allow all actions," so any marketplace action can run with your tokens and secrets.
Never reviewing the audit log, so a malicious permission change or token creation goes unnoticed until it causes an incident.

Best Practices

Manage access through teams with the lowest sufficient repository role, not per-user grants.
Require 2FA org-wide and restrict who can create public or internal repositories.
Restrict the Actions policy to GitHub-authored actions plus an explicit allowlist of verified ones.
Enforce branch protection through org rulesets — required reviews, status checks, signed commits — rather than per-repo configuration that drifts.
Export and monitor the audit log for credential creation, permission changes, and policy edits.

Comparable toolsGitLab groups and subgroups, member roles, group settings, and audit eventsBitbucket workspaces, groups, and permission schemesAzure DevOps organizations, security groups, policies, and audit logs

Knowledge Check

Why do teams and roles scale better than per-user grants?

Access attaches to a team, so onboarding and offboarding happen by changing one membership instead of editing every repository
Teams can grant a higher level of permission than any individual user is ever allowed to hold on a repository
Per-user collaborator grants are not supported on GitHub, so a team is the only way to share a repository
Putting access on a team lets every member of that team bypass the branch protection rules configured on the target repository

What does restricting the org Actions policy to an allowlist defend against?

An arbitrary marketplace action running with your workflow's tokens and secrets
Developers pushing changes directly to the main branch without an approving pull-request review first
Declared dependencies that carry known published vulnerabilities with assigned CVE identifiers in the manifest
Commits authored under a spoofed contributor email address that impersonates a trusted maintainer on the team

What is the security value of requiring 2FA org-wide?

A phished or reused password alone is no longer enough to take over a member's account
It encrypts every repository's contents at rest using each member's second factor
It signs every commit automatically once the second factor is enrolled
It prevents members from creating any personal access tokens for Git operations over HTTPS

What is the audit log primarily for during an incident?

Reconstructing who made which administrative or security change and when — permission edits, token creation, policy changes
Automatically rolling back and reverting all of the malicious commits an attacker pushed to the branch during the incident window
Blocking any push that contains a credential before it can reach the remote during the incident
Generating signed build provenance attestations for the releases shipped that day

You got correct