Auditing GitHub: Eleven Control Domains for 2026

GitHub has quietly become one of the most security-capable platforms in the modern developer toolchain. Between enforced SSO, rulesets, push protection, secret and code scanning, OIDC for cloud access, and build attestations, almost everything you need to run a hardened software factory now ships in the box. For most teams the opportunity isn’t buying more tools. It’s switching on, scoping, and connecting the strong ones they already have.

Realizing that opportunity starts with seeing GitHub for what it has become. It isn’t just a code host. It’s a control plane. It sits next to your identity provider, holds a meaningful share of your secrets, runs privileged automation against your cloud accounts, and forms the top of your software supply chain. Used well, that concentration is a genuine strength: one place to enforce identity, protect code, and prove provenance across the whole organization. It also means GitHub earns the same care you’d give any critical system, because the reach that makes it powerful is exactly what makes it worth protecting.

A good assessment reflects that. It’s less a hunt for broken settings and more a structured confirmation that a strong set of controls is turned on, correctly scoped, and working together. This guide lays out eleven control domains for a repeatable GitHub security assessment, then covers what changed in 2026 and which domains I’d now add. Each domain answers three questions: why it matters, what to assess, and what a red flag looks like.

1. Identity & Authentication

Why it matters. Every other control assumes the account behind an action is who it claims to be. If identity is soft, nothing downstream holds.

What to assess.

SSO enforcement at the organization/enterprise level. Is it required, or merely available?
MFA strength: phishing-resistant factors (passkeys, WebAuthn) versus SMS/TOTP, and whether MFA is enforced org-wide.
Whether every human account is linked to the IdP rather than an unmanaged personal login with a side-door password.
The identity model itself: standard SSO, versus Enterprise Managed Users (EMU) where accounts exist only within the enterprise and can’t wander off to personal use.
Network restrictions: IP allow lists for the enterprise, and whether they’re enforced for API and Git traffic, not just the web UI.

Red flags. Personal accounts with repo access that predate SSO enforcement. MFA “encouraged” but not required. A handful of admins exempt from SSO “for automation.” IP allow lists that only cover the browser.

2. Access & Authorization

Why it matters. Least privilege is where most orgs quietly fail. Access accretes; it rarely gets pruned.

What to assess.

Organization base permissions, the default every member inherits. Read is defensible; Write across the org almost never is.
Role assignments against actual need: how many Owners exist, and could any of them be a standard member with a custom role instead?
Team-to-IdP-group mapping so membership is governed in one place, not clicked into GitHub by hand.
Outside-collaborator access to sensitive repositories: who they are, what they can reach, and when it was last reviewed.
Custom repository roles used to narrow permissions rather than defaulting to the built-in broad ones.

Red flags. More than a few Owners. Base permission above Read. Outside collaborators on repos containing production secrets or customer data. Teams managed manually and drifting from the IdP.

3. Lifecycle Provisioning

Why it matters. The gap between “left the company” and “lost GitHub access” is a real, exploitable window. It’s also the control auditors probe first.

What to assess.

Automated joiner/mover/leaver flows via SCIM, so access tracks employment and role changes without a ticket queue.
Whether IdP deprovisioning immediately revokes GitHub sessions and tokens, not just the ability to log in next time.
Handling of the residue: PATs, SSH keys, and app authorizations that can outlive an SSO session even after the account is disabled.

Red flags. Offboarding that disables SSO but leaves live PATs. Manual deprovisioning. No test that a deprovisioned user’s existing token actually stops working.

4. Developer Credential Hygiene

Why it matters. The 2025 and 2026 supply-chain incidents nearly all trace back to a credential that should not have existed, or should not have had that reach.

What to assess.

Personal access tokens: prefer fine-grained over classic, scoped and expiring rather than broad and eternal. At the org level, enforce fine-grained PAT approval policies and restrict PAT access to org resources, a governance lever distinct from what lives on the workstation.
SSH and deploy keys: inventory, ownership, and whether read-only deploy keys are used where write isn’t needed.
Commit signing: verified signatures enforced, so authorship can’t be trivially forged.
Local credential storage on developer machines: tokens in plaintext dotfiles, shell history, or committed .env files.

Red flags. Classic PATs with repo + admin:org and no expiry. Deploy keys with write access “just in case.” Unsigned commits accepted on protected branches. Tokens pasted into CI variables that also land in logs.

5. Branch Protection & Rulesets

Why it matters. This is your integrity boundary for what actually reaches main and, critically, what gets tagged for release.

What to assess.

PR-only merges to protected branches, with no direct pushes, including from admins.
Required reviews (and whether “require review from code owners” is on for sensitive paths).
Required status checks that must pass before merge, wired to the checks that matter.
Signed-commit requirements on protected branches.
Ruleset coverage: rulesets applied consistently across default and release branches, including tag rules, not just main while release branches sit unguarded.

Red flags. Admins able to bypass protection. Protection on main but not on release/*. Status checks required but not actually blocking. Rulesets defined but scoped to zero repos.

6. Secrets Protection

Why it matters. A leaked credential is often the first domino. The goal is to stop the push, catch the leak, and prove the exposure was remediated, not merely rotated in theory.

What to assess.

Push protection enabled so secrets are blocked before they enter history, and how bypasses are tracked and justified.
Secret scanning coverage across all repos, including archived and internal ones.
Custom patterns for org-specific secret formats the default detectors won’t catch.
Historical exposure: scanning of existing history, not just new commits, and validity checks that tell you whether a found secret is still live.
Remediation discipline: leaked credentials revoked and rotated at the source, with the finding closed only after rotation, not resolved as “won’t fix.”

Red flags. Push protection off, or bypassable silently. Secret scanning enabled only on public repos. “Resolved” alerts where the underlying key was never rotated. No custom patterns despite proprietary token formats.

7. Code & Dependency Security

Why it matters. Where applicable, this is your ability to catch vulnerable code and vulnerable dependencies beforethey ship, and to make the fix the path of least resistance.

What to assess.

Code scanning (CodeQL or equivalent) enabled on the repos that warrant it, with results triaged rather than accumulating.
Dependabot alerts and automated update PRs. Alerts no one acts on are just noise.
Pull-request dependency review, so a risky new dependency is visible at review time.
Merge protection on high-severity findings, so a critical alert blocks the merge instead of being a suggestion.

Red flags. Code scanning on but no one owns triage. Thousands of open Dependabot alerts. Dependency review available but not required. High-severity findings that merge anyway.

8. CI/CD & GitHub Actions

Why it matters. Your pipeline is the most privileged code path in your stack. It authenticates to your cloud, handles your secrets, and publishes your artifacts, and until recently, security here depended entirely on each workflow author getting it right.

What to assess.

Workflow token permissions set to least privilege: permissions: read-all at the top, write granted only to the specific jobs that need it, and the org default set to read-only.
Action pinning to full commit SHAs rather than mutable tags or branches, the mutable-reference problem behind the largest recent supply-chain compromises.
An allowed-actions policy restricting which actions can run, ideally to verified creators plus an explicit allowlist.
OIDC for cloud authentication instead of long-lived cloud keys stored as secrets.
Self-hosted runner hardening: ephemeral runners, network isolation, no reuse across trust boundaries, and no self-hosted runners on public repos.
Deployment environments and protection rules: environment-scoped secrets, required reviewers for production deploys, wait timers, and deployment branch policies.
The dangerous-trigger audit: pull_request_target and similar triggers that run in the base-branch context with secret access while checking out fork code.

Red flags. permissions: write-all or the default token left broad. Actions pinned to @v4 or @main. Long-lived cloud keys in Actions secrets. Persistent self-hosted runners shared across teams. pull_request_target checking out and executing untrusted PR code.

9. Supply Chain Integrity

Why it matters. You are both a consumer and a producer in the supply chain. Assess both directions: what you pull in, and what you vouch for on the way out.

What to assess.

Build provenance and artifact attestations, so a published artifact can be traced to the workflow and commit that produced it.
Dependency pinning, of both third-party actions and package dependencies, to specific, verifiable versions.
Tag protection so release tags can’t be silently repointed to malicious code (the exact mechanism behind the tj-actions class of attack).
Governance of third-party OAuth apps and GitHub Apps: an inventory, an approval process, and periodic review of what scopes they hold and whether they’re still used.

Red flags. No attestations on published artifacts. Third-party OAuth apps with org-wide access that no one recognizes. Unprotected release tags. A “we’ll review integrations later” backlog that never clears.

10. Organization & Enterprise Policy

Why it matters. This is where secure-by-default is won or lost. Good defaults mean every new repo starts safe without anyone remembering to configure it.

What to assess.

Repository creation policy and default visibility. New repos should not default to public.
Forking policy for private and internal repositories.
Secure-by-default configurations pushed from the org/enterprise level rather than left to per-repo discretion.
Member privileges: who can create repos, invite outside collaborators, install apps, or change visibility.
Data residency (ghe.com regions where relevant) and notification restrictions to verified domains, a quiet but real data-egress control.

Red flags. New repos default to public. Any member can invite outside collaborators or install apps. Private repos forkable to personal accounts. Security features enabled repo-by-repo instead of enforced org-wide.

11. Logging, Monitoring & Audit

Why it matters. Everything above assumes you’d notice. Without telemetry and a routine, the controls are unverified assertions.

What to assess.

Audit-log streaming to the SIEM, including Git events (clone/push/fetch), not just management events, with retention that matches your investigation needs.
Security Overview usage as a single pane for enablement and findings across the org. (Note the 2026 rename: the top-level tab is now Security & quality, and repo “Vulnerability alerts” is now Findings.)
Alert routing so secret-scanning, Dependabot, and code-scanning findings reach an owner, not an unread inbox.
A recurring credential-and-access review on a defined cadence, the human control that catches the drift automation misses.
Incident-response readiness: token-revocation runbooks, familiarity with the credential revocation API, and (optionally) honeytokens to catch misuse early.

Red flags. Audit logs never leave GitHub. Security Overview no one opens. Alerts with no defined owner. Access reviewed only when an auditor asks. No plan for what to do in the first hour after a token compromise.

The 2026 shift: secure-by-default CI/CD

If you assessed GitHub before 2026, revisit Domains 8 and 9. In March 2026 GitHub published an Actions security roadmap that reframes CI/CD security from opt-in hardening to platform-level defaults, in direct response to attacks aimed at the automation itself rather than the software it builds. The primitives worth knowing:

Workflow dependency locking: deterministic dependency resolution via lock files, so a workflow can’t silently pull a changed action behind a mutable tag. This is the structural fix for the mutable-reference problem.
Scoped secrets: secrets bound to a specific execution context (branch, environment, workflow identity, or path), with reusable workflows no longer inheriting secrets from their callers by default. Notably, repository writeaccess no longer confers secret-management rights; that moves to a dedicated custom role, least privilege by default.
Workflow execution policies: built on the rulesets framework, centralizing control over who and what can trigger workflows.
Native egress firewall: a Layer 7 firewall for hosted runners that sits outside the runner VM, so it holds even against an attacker with root inside the runner. Roll out in Monitor mode to learn traffic patterns, then switch to Enforce. Until it’s broadly available, harden-runner provides in-VM egress visibility today.
Actions Data Stream: real-time CI/CD execution telemetry to external sinks, making the pipeline observable like any other production system.

Treat these as forward-looking assessment criteria: even where a capability is still in preview, whether the team has a migration plan is itself a finding.

Domains worth adding

The eleven above are a solid backbone. Based on how GitHub has evolved, I’d extend the assessment with these:

AI / Copilot & coding-agent governance. The most conspicuous gap in most current frameworks. Assess Copilot Business/Enterprise settings, content exclusions, IP indemnity posture, whether prompts and code are used for training, Copilot audit events, and Autofix coverage. Then assess autonomous agents: as of mid-2026, code generated by GitHub’s Copilot cloud agent and third-party coding agents receives automatic security validation (CodeQL, Advisory-Database dependency checks, and secret scanning) before the PR is finalized. Confirm it’s on, and govern which agents can open PRs against which repos.
Codespaces security (if used): secret exposure inside dev containers, prebuild trust, default machine permissions, and lifecycle.
Webhook & integration security: webhook secret validation, SSRF exposure from webhook endpoints, and payload handling.
Private vulnerability reporting: for public-facing repos, a configured coordinated-disclosure path (SECURITY.md, private reporting enabled) so external researchers have somewhere to go.
Backup & resilience: repository and metadata backup and a tested restore path. Not strictly a security control, but a business-continuity gap assessments increasingly flag.