End-to-End GitHub Security Hardening Guide for Organizations

DEV Community

- Check IdP logs for suspicious login or impossible travel - Confirm whether new owner changed settings, tokens, apps, runners, or rulesets response: - Escalate to Incident Commander if unauthorized - Remove unauthorized owner - Revoke sessions and tokens for involved identities - Review organization settings and audit log for follow-on activity owner: SOC / Security Engineering review_cadence: Quarterly

Recommended detection catalog:

Detection ID	Detection	Severity	Primary Risk
GH-DET-001	Organization owner added or restored	Critical	Privilege escalation
GH-DET-002	SAML SSO, MFA, or enterprise identity setting weakened	Critical	Identity control bypass
GH-DET-003	Repository changed from private/internal to public	Critical	Source/data exposure
GH-DET-004	Ruleset or branch protection disabled, deleted, or bypass actor added	High/Critical	Source integrity compromise
GH-DET-005	Workflow file changed in critical repository	High	CI/CD compromise
GH-DET-006	New self-hosted runner or runner group policy changed	High	Runner compromise path
GH-DET-007	OAuth App or GitHub App approved with broad private repo access	High	Third-party data access
GH-DET-008	Classic PAT or broad fine-grained PAT approved	High	Token-based bypass
GH-DET-009	Secret scanning alert or push protection bypass	High	Credential exposure
GH-DET-010	Release, tag, package, or artifact modified unexpectedly	High	Supply-chain compromise
GH-DET-011	Large clone, unusual archive download, or mass repository access	Medium/High	Source-code exfiltration
GH-DET-012	GitHub Actions job uses unexpected privileged runner label	High	Runner trust-zone violation

Detection quality metrics:

Alert volume
True-positive rate
False-positive rate
Mean time to triage
Mean time to contain
Percentage of alerts with complete required fields
Percentage of critical repositories covered
Detection drift or broken parser count

20.3 Example SIEM Detection Logic

Pseudo-logic:

IF github.event IN (
 "org.update_member",
 "org.add_member",
 "org.add_owner",
 "repo.visibility_change",
 "repo.transfer",
 "protected_branch.destroy",
 "ruleset.destroy",
 "oauth_application.create",
 "self_hosted_runner.create"
)
AND actor NOT IN approved_admins
THEN alert severity = high

For source exfiltration:

IF actor clones OR downloads many private repositories
AND actor is unusual for that repository set
AND activity occurs outside normal geography or working pattern
THEN alert severity = high

For workflow tampering:

IF file_path MATCHES ".github/workflows/**"
AND actor NOT IN platform_security_or_devsecops
THEN alert severity = high

20.4 Triage Steps

For high-risk GitHub alerts:

Identify actor, account type, team, and employment status.
Confirm whether change was approved.
Review affected repositories.
Review related workflow runs.
Check token, OAuth, and app activity.
Check recent authentication and SSO events.
Check whether secrets or releases were accessed.
Contain if unauthorized.
Preserve audit logs and timeline.
Open incident record if malicious or unexplained.

21. Incident Response Playbooks for GitHub

21.1 Compromised User Account

Immediate actions:

Suspend or remove user from organization.
Revoke active sessions where available.
Revoke PATs and SSH keys.
Revoke OAuth authorizations.
Review recent repository access.
Review pushes, PRs, workflow runs, releases, and package activity.
Rotate secrets accessible to the user.
Revert unauthorized code changes.
Rebuild artifacts if integrity is uncertain.
Complete root cause and detection improvement.

21.2 Leaked Secret

Immediate actions:

Revoke the secret at the source system.
Rotate replacement credential.
Identify repositories and branches containing the secret.
Review whether secret was accessed or used.
Remove secret from active code.
Clean history only when required and operationally safe.
Notify affected owners.
Add custom pattern if the secret type was not detected.
Review why push protection did not block it.

21.3 Malicious Workflow Execution

Immediate actions:

Disable workflow if still running or recurring.
Cancel active workflow runs.
Revoke exposed tokens.
Rotate secrets accessible to the workflow.
Review runner logs and system state.
Rebuild self-hosted runners.
Review artifacts and packages produced.
Check downstream deployment impact.
Restrict Actions policy until root cause is fixed.
Add workflow policy checks.

21.4 Suspected Source Code Exfiltration

Immediate actions:

Preserve audit logs.
Identify actor and repositories accessed.
Determine clone/download scope.
Disable compromised access.
Review tokens and apps used.
Engage Legal/Privacy if regulated or sensitive data may be involved.
Rotate embedded secrets if any.
Review public exposure risks.
Prepare executive summary.
Update access model and detection logic.

22. Backup, Recovery, and Business Continuity

GitHub availability and integrity matter.

Minimum controls:

Maintain repository backup strategy for critical repositories.
Export repository metadata where required.
Preserve release artifacts or rebuild provenance.
Back up critical GitHub configuration as code where possible.
Document recovery procedures for deleted repository, compromised branch, and lost admin access.
Test recovery at least annually.

Backup scope:

Git repositories
Protected branch / ruleset configuration
CODEOWNERS
Workflow files
Release metadata
Package metadata where feasible
Repository settings inventory
Team and access inventory
Security alert exports

23. Secure Configuration as Code

Do not manage GitHub security only through clicks.

Use Terraform, GitHub APIs, or approved automation for:

Repository creation
Team management
Repository access
Branch protection
Rulesets
Actions policy
Repository topics and metadata
Secret scanning enablement
Default settings
Webhooks

Benefits:

Reviewable changes
Audit trail
Drift detection
Repeatability
Faster onboarding
Easier rollback

Minimum standard:

GitHub administrative changes should go through pull request review where feasible.
Security-sensitive GitHub configuration changes require platform/security approval.
Drift reports should be reviewed monthly.

23.1 Automation and Drift Detection

Configuration as code should not only create secure settings. It should continuously detect drift.

Recommended automation model:

Layer	Automation
Inventory	Pull repository, team, owner, runner, app, token, ruleset, and security feature state through APIs
Classification	Require repository metadata for data classification, production impact, owner, and deployment authority
Policy evaluation	Compare current settings against control catalog and repository classification
Remediation	Auto-open tickets or pull requests for non-compliant settings
Enforcement	Apply organization rulesets, branch protections, Actions policies, and repository defaults through approved automation
Evidence	Store signed snapshots of policy state, exceptions, and remediation status
Alerting	Send critical drift to SIEM/SOC, not only to backlog tickets

Do not allow automation to silently make destructive changes unless the action is low-risk, reversible, and approved. For high-risk changes such as removing users, disabling deploy workflows, or revoking broad access, use a human approval gate.

Drift examples that should trigger action:

Critical repository without enforced ruleset
Secret scanning disabled
Push protection disabled
Actions policy changed to allow all public actions
Self-hosted runner added to broad repository group
Repository admin added directly instead of through team
Public visibility enabled
Required security status check removed
Bypass actor added to production branch ruleset
Repository missing owner or classification metadata

24. Repository Onboarding Checklist

Every new repository must complete this checklist before production use.

# GitHub Repository Security Onboarding Checklist
Repository:
Owner:
Business service:
Data classification:
Production impact: Yes / No
Internet-facing: Yes / No
## Access
- [ ] Repository owner assigned
- [ ] Team-based access configured
- [ ] No unnecessary direct user grants
- [ ] Admin access minimized
- [ ] Outside collaborators approved and expiry set
## Protection
- [ ] Organization ruleset applies
- [ ] Default branch protected
- [ ] Pull requests required
- [ ] CODEOWNERS configured
- [ ] Signed commits required
- [ ] Required status checks configured
- [ ] Force pushes blocked
- [ ] Branch deletion blocked
## Security scanning
- [ ] Secret scanning enabled
- [ ] Push protection enabled
- [ ] Code scanning enabled
- [ ] Dependency scanning enabled
- [ ] Dependency review enabled
- [ ] IaC scanning enabled if applicable
- [ ] Container scanning enabled if applicable
## Actions
- [ ] GitHub Actions required for this repository
- [ ] Workflow permissions explicitly set
- [ ] Third-party actions pinned to SHA
- [ ] OIDC used instead of cloud static keys
- [ ] Environments configured for deployment
- [ ] Workflow changes require CODEOWNER review
- [ ] Self-hosted runner use approved if applicable
## Release
- [ ] Release owners defined
- [ ] Tag protection configured where applicable
- [ ] Artifact signing/provenance configured where applicable
- [ ] Package publishing restricted
## Monitoring
- [ ] Repository included in audit monitoring
- [ ] Security alerts routed to owner
- [ ] Incident contact defined

25. Quarterly GitHub Security Review

Run this every quarter.

Identity and Access

Review organization owners.
Review enterprise owners.
Review repository admins.
Review outside collaborators.
Review dormant users.
Review service accounts.
Review direct repository grants.
Confirm SSO and MFA enforcement.

Applications and Tokens

Review OAuth Apps.
Review GitHub Apps.
Review fine-grained PAT approvals.
Review classic PAT usage.
Revoke unused tokens.
Revoke unused integrations.

Repositories

Review public repositories.
Review archived repositories.
Review repositories without owners.
Review repositories without recent activity.
Review repositories missing rulesets.
Review repositories missing security scanning.
Review private forks.

CI/CD

Review workflows using privileged permissions.
Review workflows using pull_request_target.
Review workflows using unpinned actions.
Review workflows with write tokens.
Review OIDC trust policies.
Review deployment environment approvals.
Review runner groups and labels.

Alerts and Incidents

Review open secret scanning alerts.
Review open code scanning alerts.
Review Dependabot backlog.
Review bypass events.
Review security exceptions.
Review GitHub incidents and lessons learned.

26. Metrics for Leadership

Use metrics that show control coverage and risk reduction.

Metric	Target
MFA enforcement rate	100%
SSO enforcement coverage	100% for org access
Repositories with active owner	100%
Critical repos with rulesets	100%
Critical repos requiring signed commits	100%
Critical repos with CODEOWNERS	100%
Repositories with secret scanning	100% where supported
Repositories with push protection	100% where supported
Active critical/high code scanning findings past SLA	0
Active leaked secret alerts past SLA	0
Classic PAT usage	0 or formally excepted
Unapproved OAuth Apps	0
Self-hosted runners without owner	0
Production deployments using long-lived cloud keys	0 or exception-approved
GitHub audit logs forwarded to SIEM	100%

Report trends, not just point-in-time numbers.

27. Exception Handling

Some repositories will not meet the baseline immediately. That is normal. What matters is that exceptions are visible, risk-accepted, and temporary.

Exception request must include:

Control not met
Repository or organization scope
Business justification
Risk impact
Compensating controls
Owner
Expiry date
Remediation plan
Approval

Rules:

No permanent exceptions.
Critical repositories require CISO or delegated security approval.
Expired exceptions trigger escalation.
Exceptions are reviewed monthly.

28. 30 / 60 / 90 Day Hardening Plan

First 30 Days: Stop the Biggest Risks

Enforce MFA.
Enforce SSO or confirm identity integration roadmap.
Reduce organization owners.
Set base permissions to no permission or read.
Restrict repository creation and visibility changes.
Restrict outside collaborator invitations.
Enable OAuth App restrictions.
Restrict classic PATs.
Enable secret scanning and push protection.
Apply branch protection or rulesets to critical repositories.
Set Actions default token permissions to read-only.
Block unapproved Actions for critical repositories.
Inventory self-hosted runners.
Export audit logs to SIEM.

Days 31 to 60: Standardize Controls

Implement organization rulesets.
Require signed commits on protected branches.
Require CODEOWNERS for critical repositories.
Standardize reusable workflows.
Pin third-party Actions to SHAs.
Replace cloud secrets with OIDC for production deployments.
Segment self-hosted runner groups.
Enable code scanning and dependency review.
Build repository onboarding automation.
Build app and token inventory.
Create GitHub incident response playbooks.

Days 61 to 90: Mature and Automate

Manage GitHub configuration as code.
Implement drift detection.
Add SIEM detections for high-risk GitHub events.
Implement artifact attestations for critical builds.
Enforce provenance in deployment where feasible.
Run a GitHub compromise tabletop.
Run a supply chain attack simulation.
Review metrics with leadership.
Close or formally accept remaining exceptions.

29. GitHub Enforcement Location Map

This section tells administrators where each recommended control is enforced in GitHub, what setting to change, and what evidence to capture. GitHub changes product navigation over time, so treat these paths as operational guidance and verify them in your GitHub Enterprise or organization UI before rollout.

Use this section with the control catalog in the appendix:

Control ID → GitHub location → Setting to configure → Evidence to capture

29.1 Enforcement Scope Reference

Scope	Typical GitHub Location	Used For
Enterprise	Enterprise account → Settings	Enterprise identity, Actions policy, audit log streaming, enterprise-wide security and policy controls
Organization	Organization → Settings	SSO, MFA, base permissions, repository governance, Actions policy, OAuth/PAT policy, security defaults
Repository	Repository → Settings	Branch protection, rulesets, Actions, environments, secrets, code security, Pages, webhooks
Security Overview / Security Configurations	Organization or enterprise security views	Security feature coverage, secret scanning, code scanning, Dependabot, vulnerability management
API / Terraform / GitHub CLI	GitHub REST/GraphQL API, Terraform provider, `gh` CLI	Evidence export, drift detection, policy-as-code, bulk remediation

Operational rule:

Every control must identify whether enforcement is performed at the enterprise, organization, repository, workflow, cloud, or process layer. If GitHub has no native setting for the control, document the compensating automation, required evidence, and manual review owner.

29.2 Control-by-Control Enforcement Instructions

Control ID	Where to Enforce in GitHub	What to Configure	Evidence to Capture
GH-GOV-01	No single GitHub toggle. Maintain in security governance documentation and mirror ownership through organization teams and repository metadata.	Define accountable owners for enterprise/org settings, repositories, Actions, secrets, apps, runners, security alerts, and audit logs. Create GitHub teams such as `platform-admins`, `security-admins`, and service owner teams.	RACI, owner register, GitHub team list, repository owner metadata, quarterly review ticket.
GH-ID-01	Enterprise or Organization → Settings → Authentication security / SAML single sign-on. For Enterprise Managed Users, use Enterprise → Settings → Authentication and provisioning.	Enforce SAML SSO or Enterprise Managed Users. Configure SCIM where available. Map IdP groups to GitHub teams. Require SSO authorization for organization access.	SSO enforcement screenshot/export, IdP group mapping, SCIM configuration, sample deprovisioning evidence.
GH-ID-02	Organization → Settings → Authentication security. Enterprise policies may also enforce user security controls.	Require two-factor authentication for all organization members. Verify outside collaborators and privileged users meet the same requirement where supported.	MFA requirement screenshot/export, list of non-compliant users, removal/suspension evidence.
GH-ID-03	Organization → People → Owners. Enterprise → People / Administrators where applicable.	Minimize organization owners. Remove unnecessary owner access. Use named accounts only. Move routine administration to delegated teams or custom roles where available.	Owner list export, monthly review record, removal tickets, break-glass account record.
GH-ACCESS-01	Organization → Teams; Organization → People; Repository → Settings → Collaborators and teams.	Grant repository access through teams. Remove direct user grants unless exception-approved. Map IdP groups to GitHub teams where available.	Team-to-repository access export, direct access report, exception register.
GH-ORG-01	Organization → Settings → Member privileges → Base permissions.	Set base permission to `No permission`. Use `Read` only when explicitly approved. Do not use broad `Write`.	Organization settings screenshot/API export, exception approval if base permission is not `No permission`.
GH-ORG-02	Organization → Settings → Member privileges and Repository defaults.	Restrict repository creation, deletion, transfer, visibility changes, and outside collaborator invitations. Limit repository creation to approved teams. Require approval for public repositories.	Organization privilege settings export, repository creation permission list, visibility/deletion/transfer audit events.
GH-REPO-01	Repository → About/sidebar metadata, repository topics, custom inventory, or policy-as-code inventory.	Require business owner, technical owner, classification, production-impact flag, deployment authority flag, OIDC/cloud access flag, and last review date. GitHub does not natively enforce all metadata fields, so enforce through repository onboarding automation and inventory checks.	Repository inventory export, onboarding checklist, metadata validation report, missing-owner report.
GH-REPO-02	Repository root → `CODEOWNERS`; Repository → Settings → Rules → Rulesets or Branches → Branch protection.	Add CODEOWNERS entries for global ownership and sensitive paths such as `.github/workflows/`, `terraform/`, `k8s/`, `auth/`, and release/package files. Require CODEOWNERS review through rulesets or branch protection.	CODEOWNERS file, ruleset requiring code owner review, sample blocked/approved PR evidence.
GH-RULE-01	Organization → Settings → Rules → Rulesets, or Repository → Settings → Rules → Rulesets / Branches → Branch protection rules.	Create enforced rulesets for `main`, `master`, `release/`, `hotfix/`, and `production`. Require pull requests, approval count, CODEOWNERS review, required status checks, signed commits, conversation resolution, block force pushes, block deletions, and restrict bypass.	Ruleset export/API snapshot, enforcement mode, protected branch patterns, required checks list, bypass actor list.
GH-RULE-02	Organization or Repository → Settings → Rules → Rulesets → Bypass list. Branch protection bypass controls where branch protection is used.	Keep bypass actors empty by default or limited to a break-glass team. Require approval, reason code, ticket reference, and SOC alerting for bypass use.	Bypass actor export, break-glass approval record, SIEM alert for bypass event, post-event review ticket.
GH-ACT-01	Enterprise or Organization → Settings → Actions → General. Repository override: Repository → Settings → Actions → General.	Disable Actions where not needed. Restrict allowed Actions and reusable workflows. Allow GitHub-authored Actions and approved third-party Actions only. Require third-party Actions to be pinned to full-length commit SHA through workflow linting or policy-as-code.	Actions policy export, allowed Actions list, workflow scan showing SHA pinning, exception list.
GH-ACT-02	Organization → Settings → Actions → General → Workflow permissions. Repository → Settings → Actions → General for repository override. Workflow files under `.github/workflows/*.yml`.	Set default `GITHUB_TOKEN` permissions to read-only. Disable or tightly control "Allow GitHub Actions to create and approve pull requests." Require every workflow to declare explicit `permissions:`.	Organization/repository Actions settings, workflow lint results, sample workflow with explicit permissions.
GH-ACT-03	GitHub side: Repository → Settings → Environments and workflow `permissions: id-token: write`. Cloud side: AWS IAM / Azure Federated Credentials / GCP Workload Identity Federation / Vault trust configuration.	Replace static cloud keys with OIDC or approved short-lived credentials. Restrict trust by organization, repository, branch/tag/environment, and workflow where possible. Use separate roles per environment.	Workflow file, GitHub environment configuration, cloud trust policy, role permissions, deployment logs showing federated identity.
GH-RUN-01	Enterprise or Organization → Settings → Actions → Runners / Runner groups. Repository → Settings → Actions → Runners for repo-scoped runners.	Create runner groups by trust zone. Restrict which repositories can use each runner group. Do not allow untrusted fork PRs on privileged self-hosted runners. Prefer ephemeral runners for sensitive workloads.	Runner group policy export, repository allowlist, runner labels, network segmentation evidence, runner lifecycle logs.
GH-SEC-01	Organization security settings / Security configurations, or Repository → Settings → Code security and analysis / Security and analysis.	Enable secret scanning, push protection, validity checks where available, and custom patterns for internal tokens. Apply security configurations to repositories where supported.	Security configuration export, secret scanning status, push protection status, custom pattern list, alert routing evidence.
GH-PAT-01	Organization → Settings → Personal access tokens → Settings. Enterprise policies may also apply.	Restrict or block classic PAT access. Require approval for fine-grained PATs where supported. Enforce maximum lifetime and least privilege. Review active tokens regularly.	PAT policy screenshot/export, approved token list, denied/non-compliant token events, exception register.
GH-APP-01	Organization → Settings → Third-party Access / OAuth application policy; Organization → Settings → GitHub Apps / Installed GitHub Apps; Enterprise → Policies where applicable.	Enable OAuth App access restrictions. Require approval before apps access organization resources. Prefer GitHub Apps installed only on selected repositories with least permissions. Review broad app scopes quarterly.	OAuth restriction setting, pending/approved app list, GitHub App installation permissions, vendor/security approval record.
GH-SCA-01	Repository → Security / Security and quality; Repository → Settings → Code security and analysis. Organization security configurations where available. Workflow required checks under Rulesets/Branch protection.	Enable CodeQL/code scanning or approved SAST. Enable Dependabot alerts, dependency graph, Dependabot security updates, and dependency review. Require security checks before merge for Critical and High repositories.	Code scanning configuration, Dependabot settings, PR required checks, vulnerability SLA report, false-positive/suppression record.
GH-SUPPLY-01	Repository → Settings → Actions, Environments, Packages, Releases, Tags, and workflow files. Rulesets for tag/release branch protection where available.	Require protected release branches/tags, restricted release publishers, signed tags where supported by process, artifact attestations/provenance, and package publishing controls. Verify provenance before deployment for critical artifacts.	Release/tag protection evidence, workflow attestation output, package publisher list, deployment verification logs.
GH-MON-01	Enterprise → Settings → Audit log / Audit log streaming. Organization → Audit log for org-level review. SIEM/log lake configuration outside GitHub.	Stream or export GitHub audit logs to SIEM/log lake. Include enterprise audit log, organization audit log, Git events where available, Actions, security alerts, app/token events, runner events, and ruleset changes.	Audit log streaming configuration, SIEM ingestion dashboard, parser health, sample event, retention configuration.
GH-IR-01	GitHub Security, Audit log, Actions run logs, repository activity, Releases, Packages, Branches/Rulesets, and IdP logs. Incident case system outside GitHub.	During GitHub incidents, preserve raw audit logs, workflow logs, runner logs, release metadata, package metadata, commit/PR history, token/app activity, and identity evidence before remediation destroys context.	Incident evidence package, immutable log export, chain-of-custody record, timeline, containment approvals, post-incident review.
GH-EXC-01	No single native GitHub toggle. Maintain an exception register and reflect approved exceptions in ruleset bypass lists, Actions allowlists, app approvals, token approvals, or repository metadata.	Require risk rating, business justification, compensating controls, owner, expiry date, and remediation plan. Alert on expired exceptions.	Exception register, approval record, expiry tracking, compensating control evidence, monthly review.

29.3 GitHub UI Enforcement Notes by Domain

Identity and access

Use GitHub for enforcement where possible, but treat the identity provider as the source of truth. SSO, SCIM, team synchronization, and Enterprise Managed Users should be managed from the enterprise or organization identity settings and the corporate IdP. GitHub teams should mirror approved IdP groups instead of becoming an unmanaged second identity system.

Implementation checklist:

Enforce SSO or Enterprise Managed Users.
Require MFA.
Map IdP groups to GitHub teams.
Review organization owners from the People/Owners view.
Remove direct repository grants from repository collaborator settings.
Export team and repository access through API or governance tooling.

Organization governance

Use organization settings for default guardrails. These are the controls that prevent unsafe behavior before a repository owner can create risk.

Implementation checklist:

Set base permissions to No permission.
Restrict repository creation.
Restrict repository deletion, transfer, and visibility changes where available.
Restrict outside collaborator invitations.
Require approval for public repositories.
Monitor audit events for any governance setting change.

Repository rules and change control

Use organization rulesets first, then repository rulesets or branch protection for special cases. Organization rulesets reduce drift and prevent each repository from inventing its own security model.

Implementation checklist:

Create rulesets for production branch patterns.
Require PRs, approvals, CODEOWNERS review, required checks, signed commits, and conversation resolution.
Block force pushes and branch deletion.
Minimize bypass actors.
Keep rulesets in enforced mode after testing.
Export ruleset configuration for audit.

GitHub Actions and CI/CD

Use enterprise or organization Actions policy for broad restrictions. Use repository Actions settings and workflow linting for repository-specific controls. Use cloud IAM for OIDC enforcement because GitHub issues the identity token, but the cloud provider decides what it can access.

Implementation checklist:

Restrict allowed Actions and reusable workflows.
Set default GITHUB_TOKEN to read-only.
Require explicit workflow permissions:.
Require SHA pinning for third-party Actions.
Protect .github/workflows/** with CODEOWNERS and rulesets.
Use GitHub Environments for production deployment approvals.
Use OIDC with cloud-side trust restrictions instead of static cloud keys.

Security scanning

Use organization security configurations where available to apply consistent scanning defaults. Use repository Code security settings for repository-specific enablement or verification.

Implementation checklist:

Enable secret scanning.
Enable push protection.
Enable custom secret patterns for internal credentials.
Enable CodeQL/code scanning or approved SAST.
Enable Dependabot alerts and security updates.
Require security checks through rulesets or branch protection for Critical and High repositories.
Route alerts to security and repository owners.

Apps, tokens, and integrations

Programmatic access should be centrally governed. OAuth Apps, GitHub Apps, fine-grained PATs, and classic PATs can all become bypass paths around normal review and SSO-driven access.

Implementation checklist:

Enable OAuth App access restrictions.
Review GitHub App installations and scopes.
Prefer GitHub Apps over OAuth Apps for automation.
Restrict or block classic PATs.
Require approval, expiry, and least privilege for fine-grained PATs.
Maintain an app and token inventory.
Alert on broad app approval or token policy weakening.

Runners

Runner isolation must be enforced in GitHub and in infrastructure. GitHub runner groups control repository eligibility, but network segmentation, ephemeral lifecycle, egress control, and host hardening must be enforced in the runner environment.

Implementation checklist:

Create runner groups by trust zone.
Restrict runner groups to approved repositories.
Use distinct labels that do not accidentally route jobs to privileged runners.
Use ephemeral runners for sensitive workflows.
Block privileged runners from untrusted fork PRs.
Forward runner OS, job, and network telemetry to central logging.

Audit logging and incident response

GitHub audit logging must be configured before an incident. The audit log UI alone is not sufficient for mature investigations because retention and query capability may be limited.

Implementation checklist:

Stream enterprise audit logs to SIEM where available.
Export organization audit logs where streaming is not available.
Enable source IP visibility where available.
Build detections for owner changes, SSO/MFA weakening, ruleset changes, runner changes, app approvals, token activity, workflow changes, and public exposure.
Preserve logs, workflow run data, runner evidence, release metadata, package metadata, and identity evidence during incidents.

29.4 When GitHub Has No Native Enforcement Setting

Some controls in this guide cannot be fully enforced by a GitHub UI setting. For those controls, use this fallback model:

Control Type	Enforcement Method
Ownership metadata	Repository onboarding workflow, required repository topics/properties, CMDB integration, or policy-as-code inventory
Repository classification	Intake questionnaire, repository inventory, security review, and automated policy evaluation
Workflow SHA pinning	CI workflow linter, pre-merge check, policy-as-code scanner, or required status check
Cloud OIDC scope	Cloud IAM trust policy, federated credential conditions, Vault role configuration
Artifact provenance verification	Deployment controller, Kubernetes admission policy, release pipeline gate, or package registry control
Exception governance	GRC register, ticketing workflow, exception dashboard, monthly review
Incident evidence package	Incident case management system, immutable storage, SIEM export, chain-of-custody process
Drift remediation	GitHub API/Terraform/GraphQL inventory compared against the control catalog

Minimum documentation for non-native controls:

Control ID:
Native GitHub setting available: Yes / No
Compensating enforcement:
Owner:
Evidence:
Review cadence:
Exception expiry:

This distinction is important. A control should not be marked "implemented" merely because it is written in this standard. It is implemented only when the enforcing setting, automation, or review process exists and produces evidence.

30. Enterprise Control Catalog Appendix

Use this appendix as the starting point for policy-as-code, audit evidence, and quarterly review.

Control ID	Domain	Requirement	Minimum Evidence	Review Cadence
GH-GOV-01	Governance	GitHub must have accountable owners for enterprise/org settings, repositories, Actions, secrets, apps, runners, alerts, and audit logs	RACI, owner list, operating model	Quarterly
GH-ID-01	Identity	SSO must be enforced for organization access	SSO setting, IdP mapping	Quarterly
GH-ID-02	Identity	MFA must be required for all members, owners, billing managers, outside collaborators, and automation accounts where supported	MFA compliance report	Monthly
GH-ID-03	Identity	Organization owners must be minimized and reviewed	Owner list, review ticket	Monthly
GH-ACCESS-01	Access	Repository access must be granted through teams, not direct grants, except approved exceptions	Team mapping, direct grant report	Quarterly
GH-ORG-01	Organization	Base permission must be `No permission` unless approved	Org settings export	Quarterly
GH-ORG-02	Organization	Repository creation, deletion, transfer, and visibility changes must be restricted	Org settings export	Quarterly
GH-REPO-01	Repository	Every repository must have owner, classification, and production-impact metadata	Repository inventory	Quarterly
GH-REPO-02	Repository	Critical and High repositories must use CODEOWNERS for sensitive paths	CODEOWNERS file and ruleset evidence	Quarterly
GH-RULE-01	Rulesets	Default, release, hotfix, and production branches must require PR review, status checks, CODEOWNERS review, and force-push protection	Ruleset/branch protection export	Quarterly
GH-RULE-02	Rulesets	Bypass actors must be minimized, approved, and monitored	Bypass actor list and SIEM alert	Monthly
GH-ACT-01	Actions	Third-party Actions must be approved and pinned to full-length commit SHA	Workflow scan results	Monthly
GH-ACT-02	Actions	`GITHUB_TOKEN` must default to read-only and workflows must declare explicit permissions	Org Actions setting and workflow lint	Monthly
GH-ACT-03	Actions	Production cloud access must use OIDC or approved short-lived credentials	Trust policy and workflow evidence	Quarterly
GH-RUN-01	Runners	Self-hosted runners must be segmented by trust zone and isolated from untrusted code	Runner group policy, network evidence	Monthly
GH-SEC-01	Secrets	Secret scanning and push protection must be enabled wherever available	Security settings export	Monthly
GH-PAT-01	Tokens	Classic PATs must be blocked or formally excepted	Token policy and exception records	Monthly
GH-APP-01	Apps	OAuth Apps and GitHub Apps must require approval and inventory tracking	App inventory and approvals	Quarterly
GH-SCA-01	Code security	Active production repositories must run SAST/SCA and required security checks	Scan configuration and PR checks	Quarterly
GH-SUPPLY-01	Supply chain	Critical artifacts must have provenance or signing where feasible	Attestation/signature evidence	Quarterly
GH-MON-01	Monitoring	GitHub audit logs must be exported to SIEM or reviewed through an approved process	SIEM ingestion, export job, parser health	Monthly
GH-IR-01	Incident response	GitHub incidents must preserve audit logs, workflow logs, release metadata, and identity evidence	Incident evidence package	Per incident
GH-EXC-01	Exceptions	Exceptions must be risk-rated, time-bound, approved, and reviewed	Exception register	Monthly

31. Final Thoughts

If we secure only user login and branch protection, we are not securing GitHub.

A strong GitHub security program covers identity, teams, repository governance, code review, signed commits, Actions, runners, secrets, tokens, OAuth apps, supply chain provenance, audit logging, incident response, and continuous review.

The most important design principle is this:

GitHub should not rely on developer discipline alone. Security-critical behavior must be enforced through platform guardrails.

Developers should still move fast, but within a system that prevents predictable mistakes and blocks high-impact abuse paths.