End-to-End GitHub Security Hardening Guide for Organizations

GitHub is not just a source code platform anymore.

For most engineering organizations, GitHub is part identity system, part software supply chain, part CI/CD platform, part secret store, part deployment orchestrator, and part production change-control system.

That means we should secure GitHub like a production control plane.

This guide is written from the perspective of a CISO tightening GitHub across an organization. It is not a high-level best-practice list. It is a practical hardening baseline we can apply, audit, and improve over time.

The goal is simple:

Nobody should be able to compromise our source code, workflows, secrets, build systems, release process, or production environments because GitHub was loosely governed.

How to Use This Guide

Use it in three layers:

Control language in this guide should be interpreted as follows:

Every mandatory control should eventually map to:

Control ID → Requirement → Owner → Enforcement → Evidence → Monitoring → Exception path

Section 29 provides the operational enforcement map that tells administrators where to find each GitHub setting, what to configure, and what evidence to retain.

This prevents the standard from becoming a long checklist that nobody can prove or operate.

Assumptions

This guideline assumes:

• We use GitHub Organization or GitHub Enterprise Cloud.
• Repositories include production application code, infrastructure-as-code, automation, CI/CD workflows, and internal tooling.
• GitHub Actions is enabled or planned.
• Developers use pull requests for normal changes.
• Some repositories may connect to AWS, Azure, GCP, Kubernetes, package registries, or deployment tools.
• We want controls that are enforceable, auditable, and operationally realistic.

Where a feature depends on GitHub Enterprise, GitHub Advanced Security, GitHub Secret Protection, GitHub Code Security, or plan-specific capability, validate availability in your GitHub plan before rollout.

GitHub Capability and License Validation Matrix

Before enforcing this standard, validate which capabilities are available in your GitHub plan and enterprise configuration. GitHub feature availability changes over time, and some controls depend on GitHub Enterprise Cloud, GitHub Enterprise Server version, GitHub Secret Protection, GitHub Code Security, GitHub Advanced Security, or equivalent third-party tooling.

Rollout rule:

Do not weaken the security objective because a native feature is unavailable. Either enable the required GitHub capability, use an approved third-party control, or document a time-bound exception with compensating controls.

1. Governance Model: Treat GitHub as a Tier-0 Engineering Platform

The first mistake organizations make is treating GitHub as a developer tool owned only by engineering.

That is not enough.

GitHub should have a formal ownership model.

Security owns the control standard. Engineering owns implementation. Platform Engineering owns guardrails. Repo owners own compliance for their repositories.

That split matters. If ownership is unclear, GitHub security becomes a set of settings nobody fully controls.

2. Baseline Security Policy

Before we touch settings, we need a written baseline. This becomes the standard we enforce through organization settings, rulesets, CI/CD controls, and audit reviews.

Minimum GitHub Security Baseline

All organization-owned GitHub repositories must meet the following baseline:

1. All users authenticate using corporate identity controls.
2. MFA is mandatory for all users.
3. Organization access is granted through groups and teams, not ad hoc direct grants.
4. Base organization permissions are set to the lowest practical level.
5. Outside collaborators are restricted and reviewed.
6. Repository creation, deletion, transfer, and visibility changes are restricted.
7. Production branches require pull requests, approval, status checks, and signed commits.
8. Secrets scanning and push protection are enabled wherever available.
9. Code scanning and dependency scanning are enabled for active repositories.
10. GitHub Actions is restricted to approved sources and secure workflow patterns.
11. Self-hosted runners are isolated by trust level and workload sensitivity.
12. Long-lived cloud credentials in GitHub secrets are replaced with OIDC federation where supported.
13. Classic PAT usage is restricted. Fine-grained PATs require approval, expiry, and least privilege.
14. OAuth Apps and GitHub Apps require approval before accessing organization data.
15. Audit logs are reviewed and exported to the SIEM.
16. Repository administrators cannot bypass security controls without approved exception.
17. Break-glass access exists, is monitored, and is tested.
18. Exceptions are time-bound, risk-accepted, and reviewed.

This baseline is intentionally strict. The purpose is not to slow engineering down. The purpose is to prevent a compromised account, malicious workflow, leaked token, or careless repository setting from becoming a production incident.

Minimum Control Catalog Format

The baseline above should be converted into a control catalog before enterprise enforcement.

Use this format:

Starter controls:

3. Identity and Account Security

Identity is the first control plane. If an attacker gets a developer account with broad repository and workflow access, they may be able to steal source code, inject malicious code, exfiltrate secrets, or tamper with releases.

3.1 Enforce SSO

For enterprise environments, use SAML SSO or Enterprise Managed Users where appropriate.

Security requirement:

• Enforce SSO for all organization access.
• Use the corporate identity provider as the source of truth.
• Do not allow personal email accounts to become unmanaged production identities.
• Require reauthentication for sensitive operations where supported.
• Maintain emergency recovery codes and break-glass accounts under a documented procedure.

Recommended implementation:

• Use Enterprise Managed Users if the organization needs centralized lifecycle control over GitHub identities.
• Use SAML SSO with SCIM provisioning if using personal GitHub accounts but requiring centralized access governance.
• Map identity provider groups to GitHub teams.
• Remove users from GitHub through identity lifecycle automation, not manual cleanup only.

Operational rule:

If HR disables the user, GitHub access must be removed without waiting for a manual ticket.

3.2 Enforce MFA

MFA must be mandatory for:

• Organization members
• Enterprise owners
• Organization owners
• Billing managers
• Outside collaborators
• Service or automation accounts where supported

Preferred authenticators:

1. Passkeys / hardware security keys
2. TOTP authenticator apps
3. GitHub Mobile as an additional option

Avoid SMS where stronger methods are available.

Minimum policy:

• No user may retain access to organization repositories without MFA.
• Users who fail MFA enrollment by the deadline are removed or suspended.
• Break-glass accounts must use hardware-backed MFA and be stored in a controlled vault.

3.3 Reduce Organization Owners

Organization owner is a high-risk role.

Minimum standard:

• Keep organization owners to a very small group.
• Use named accounts only.
• Require MFA and SSO.
• Review owner membership monthly.
• Do not use owner access for routine repository administration.
• Use custom roles or delegated repository administration where practical.

Recommended target:

• 2 to 4 organization owners for small to mid-size organizations.
• Separate enterprise owners from day-to-day repository maintainers.
• Use break-glass owner access only for emergency recovery.

Owner account monitoring must include:

• New owner added
• Owner removed
• SSO enforcement changed
• MFA requirement changed
• Actions policy changed
• PAT policy changed
• OAuth policy changed
• Repository visibility changed
• Audit log export disabled
• Secret scanning disabled

3.4 Disable Dormant and Orphaned Access

Review at least monthly:

• Dormant users with no recent activity
• Users not mapped to an IdP group
• Former employees
• Contractors past end date
• Outside collaborators
• Users with direct repository access
• Users with admin or maintain role
• Service accounts

Action standard:

• Disable access immediately for terminated users.
• Remove stale users after 30 days of inactivity unless explicitly approved.
• Require business owner approval for contractor extensions.
• Record evidence of access review completion.

4. Teams and Access Model

A clean team model prevents access sprawl.

4.1 Use Teams as the Primary Access Mechanism

Avoid direct user-to-repository grants except for temporary exceptions.

Team design should follow this pattern:

org
├── platform-admins
├── platform-developers
├── security-admins
├── security-readonly
├── app-payments-admins
├── app-payments-maintainers
├── app-payments-developers
├── app-payments-readonly
├── data-platform-maintainers
├── data-platform-developers
├── data-platform-readonly
└── contractors-project-x-readonly

Team names should follow this pattern:

<domain-or-system>-<role>

Examples:

• app-payments-developers
• app-payments-maintainers
• app-payments-readonly

The repeated application or platform name is intentional. It separates access tiers for the same system so permissions can be granted through teams instead of direct user-to-repository grants.

Avoid using both admins and maintainers unless the distinction is defined. In GitHub, Maintain and Admin are different repository permission levels, so the team name should map cleanly to the intended GitHub role.

Each team should have:

• Clear business owner
• Clear technical owner
• Defined repository access
• Defined permission level
• IdP group mapping where possible
• Review frequency
• Expiry date for temporary teams

4.2 Use Least Privilege Repository Roles

Recommended role model:

Do not grant Admin because a user is senior. Grant it only when their operational role requires it.

4.3 Set Base Permissions to No Permission or Read

For production organizations, set organization base permission to:

No permission

Use Read only if the organization intentionally allows all members to read internal repositories.

Do not use broad Write base permissions.

4.4 Control Outside Collaborators

Outside collaborators are one of the most common sources of access drift.

Minimum controls:

• Only organization owners or approved delegated admins may invite outside collaborators.
• Repository admins should not be allowed to invite outside collaborators without governance approval.
• Outside collaborators must use MFA.
• Access must be time-bound.
• Access must be tied to a sponsor.
• Access must be reviewed at least monthly.
• External access to sensitive repositories requires security approval.

Required evidence:

• Business justification
• Sponsor
• Repository list
• Permission level
• Expiry date
• Approval record
• Removal confirmation

5. Organization Settings Hardening

These settings reduce unsafe administrative behavior.

5.1 Repository Creation

Restrict who can create repositories.

Recommended policy:

• Only approved platform, engineering leadership, or delegated repository creator teams can create repositories.
• Default repository visibility should be private or internal.
• Public repositories require approval.
• Repository naming standards must be enforced.
• New repositories must be onboarded to security controls before production use.

New repository checklist:

• Owner assigned
• Data classification assigned
• Visibility approved
• Ruleset applied
• Code owners configured
• Security scanning enabled
• Dependabot configured
• Secrets scanning enabled
• Actions policy inherited
• Branch protection or ruleset active
• Repository archived if not used

5.2 Repository Visibility Changes

Restrict visibility changes.

Requirement:

• Developers and repository admins must not be able to change a private repository to public without approval.
• Public release of source code requires security, legal, and engineering approval.
• Sensitive repositories must be blocked from public visibility.

Monitor:

• Private to public changes
• Internal to public changes
• Repository transfer
• Repository deletion
• Repository archival
• Fork policy changes

5.3 Repository Deletion and Transfer

Restrict repository deletion and transfer to organization owners or a tightly controlled platform team.

Operational requirement:

• Repositories must not be deleted without backup/export and approval.
• Transfers outside the organization require security approval.
• Archived repositories must retain security-relevant history.

5.4 Default Repository Settings

Recommended defaults:

6. Repository Security Baseline

Every repository should be classified before controls are applied.

6.1 Repository Classification

Use a simple classification model:

6.1.1 Repository Classification Decision Criteria

Repository classification should be based on risk drivers, not only the application name or team size.

Use these criteria:

Decision rule:

If a repository can affect production, credentials, identity, cloud infrastructure, release artifacts, or customer data, do not classify it lower than High.

Required metadata for every repository:

Critical repositories require:

• No direct pushes to protected branches
• Signed commits
• Required pull request reviews
• Code owners
• Required status checks
• Required security scans
• Restricted administrators
• No unapproved Actions
• No public forks
• No unreviewed workflow changes
• Full audit logging and alerting

6.2 CODEOWNERS

Use CODEOWNERS for mandatory review ownership.

Example:

# Global owners
* @org/platform-maintainers

# Security-sensitive areas
/.github/workflows/ @org/devsecops @org/platform-security
/terraform/ @org/cloud-security @org/platform-engineering
/k8s/ @org/platform-engineering @org/cloud-security
/auth/ @org/security-engineering @org/app-auth-maintainers
/payment/ @org/payments-maintainers @org/appsec

Rules:

• CODEOWNERS must use teams, not only individuals.
• Security-sensitive directories must require security or platform review.
• Workflow changes must require DevSecOps or platform review.
• CODEOWNERS file changes must require approval from platform/security owners.

6.3 Repository Admin Reduction

Repository admin rights must be limited.

Minimum policy:

• Developers normally get Write.
• Maintainers get Maintain.
• Admin is reserved for repository owners and platform/security administrators.
• Admin access is reviewed monthly for critical repositories and quarterly for others.
• Direct user admin grants should be removed in favor of teams.

7. Branch Protection and Rulesets

GitHub rulesets should be the default way to enforce consistent policies across repositories and branches.

Use organization rulesets for broad enforcement. Use repository rulesets only where a specific repository needs stricter controls.

7.1 Required Rules for Default Branches

Apply to:

main
master
release/*
hotfix/*
production

Minimum required controls:

• Require pull request before merge
• Require at least 1 approving review for standard repositories
• Require at least 2 approving reviews for critical repositories
• Require review from CODEOWNERS
• Dismiss stale approvals when new commits are pushed
• Require conversation resolution before merge
• Require status checks to pass
• Require branch to be up to date before merge where practical
• Require signed commits
• Block force pushes
• Block branch deletion
• Restrict who can push
• Restrict who can bypass
• Require linear history where operationally suitable

7.2 Required Status Checks

Recommended required checks:

• Unit tests
• Build
• Linting
• SAST / CodeQL or equivalent
• SCA / dependency scan
• Secret scan check
• IaC scan for infrastructure repositories
• Container image scan where images are built
• License policy check where required
• Dependency review for pull requests
• Workflow policy check for .github/workflows/

Critical repositories should not allow merge if required security checks fail.

7.3 Signed Commits

Signed commits reduce the risk of impersonation and unauthorized commit injection.

Organization standard:

• Require signed commits on protected branches.
• Developers must configure Git commit signing using SSH signing, GPG, or S/MIME as supported by GitHub.
• Bot accounts must use verified signing keys.
• Unsigned commits are not accepted into protected branches.
• Exceptions require documented approval for legacy migration only.

Developer setup example using SSH signing:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Validation:

git log --show-signature -1

Operational note:

Required signed commits may break legacy automation if bots are not configured correctly. Fix the automation rather than weakening the branch rule.

7.4 Require Verified Commit Email

Where supported through rulesets and enterprise policy, require commit metadata to align with approved domains.

Recommended standard:

• Corporate work commits should use approved corporate email domains.
• Personal email addresses should not appear in production commit history unless approved.
• Prevent commits from unknown or disposable domains in sensitive repositories.

7.5 Block Dangerous File Paths

Use rulesets, code owners, and CI checks to protect sensitive paths:

.github/workflows/**
.github/actions/**
terraform/**
k8s/**
helm/**
Dockerfile
docker-compose.yml
scripts/deploy/**
Makefile
package.json
package-lock.json
pom.xml
build.gradle
requirements.txt
go.mod
Cargo.toml

Risk:

A pull request that modifies a workflow, package manifest, Terraform file, or deployment script can be a supply chain attack even if application code looks harmless.

7.6 Ruleset Evidence Requirements

Rulesets and branch protections should be auditable.

For each protected branch or ruleset, retain:

Ruleset drift should be detected automatically. Alert when:

• A ruleset is disabled or deleted.
• A required status check is removed.
• A bypass actor is added.
• A repository is removed from an organization ruleset.
• A protected branch pattern is weakened.
• A critical repository has no matching enforced ruleset.

8. Pull Request Security Workflow

A pull request is not just a collaboration feature. It is the security checkpoint before code enters the trusted branch.

8.1 Pull Request Requirements

All production-impacting repositories must require:

• Linked issue or change ticket
• Description of change
• Risk impact
• Testing evidence
• Rollback plan for production changes
• Security review for sensitive components
• Required status checks
• Code owner approval

Recommended pull request template:

## What changed?

## Why is this change needed?

## Security impact
- [ ] No security impact
- [ ] Auth / authorization changed
- [ ] Secrets / credentials changed
- [ ] Network exposure changed
- [ ] Data handling changed
- [ ] CI/CD workflow changed
- [ ] Infrastructure changed

## Testing performed

## Rollback plan

## Reviewer checklist
- [ ] Code owner reviewed
- [ ] Tests passed
- [ ] Security-sensitive paths reviewed
- [ ] No secrets introduced
- [ ] Dependencies reviewed

8.2 Merge Controls

Recommended merge policy:

Disable merge methods your organization does not use. This reduces confusion and inconsistent history.

8.3 Administrator Bypass

Do not allow administrators to bypass branch protection or rulesets by default.

If bypass is required:

• Limit bypass actors to a break-glass team.
• Require reason code.
• Alert SOC/SecOps.
• Create ticket automatically.
• Review bypass events within 24 hours.
• Document post-event justification.

9. GitHub Actions Security

GitHub Actions is powerful and dangerous. Treat it like production automation.

A malicious workflow can:

• Read repository contents
• Exfiltrate secrets
• Publish poisoned packages
• Modify releases
• Create cloud resources
• Deploy to production
• Abuse self-hosted runners
• Steal tokens from build environments

9.1 Enterprise and Organization Actions Policy

Recommended policy:

• Do not allow all public actions by default.
• Allow GitHub-authored actions.
• Allow verified creator actions only after review.
• Maintain an approved allowlist for third-party actions.
• Require full-length commit SHA pinning for third-party actions.
• Restrict reusable workflows to approved repositories.
• Disable Actions for repositories that do not need CI/CD.
• Require approval for workflows from forks.
• Set default GITHUB_TOKEN permissions to read-only.
• Require explicit permissions in each workflow.

9.1.1 GitHub Actions Threat Model and Abuse Cases

Actions controls should be tied to realistic abuse paths.

Minimum design principle:

Untrusted code may be built and tested, but it must not receive production secrets, privileged tokens, trusted runner access, or deployment authority.

9.2 Pin Actions to Commit SHA

Do not pin third-party actions only by mutable tags like:

uses: vendor/action@v1

Use full-length commit SHA:

uses: vendor/action@3df4b6a7d3d8e0e3b8d96f0c0f00000000000000

Operational rule:

• Tags can move.
• Branches can move.
• A full commit SHA is the safest reference.
• Review and update pinned SHAs through dependency management or scheduled review.

9.3 Set Workflow Permissions Explicitly

Do not rely on broad default token permissions.

Safe default:

permissions:
  contents: read

Only grant what the job needs.

Example for publishing a package:

permissions:
  contents: read
  packages: write
  id-token: write

Example for opening pull requests:

permissions:
  contents: write
  pull-requests: write

Security rule:

Every workflow must declare permissions: explicitly.

9.4 Use OIDC Instead of Long-Lived Cloud Secrets

Long-lived cloud keys stored as GitHub secrets are high risk.

Preferred pattern:

GitHub Actions → OIDC token → Cloud IAM federation → short-lived cloud credentials

Use OIDC for:

• AWS IAM roles
• Azure federated credentials
• GCP Workload Identity Federation
• Vault federation
• Cloud deployment systems that support OIDC

AWS trust condition example:

{
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/main"
  }
}

Minimum OIDC controls:

• Restrict by organization.
• Restrict by repository.
• Restrict by branch, tag, or environment.
• Restrict by workflow where supported.
• Use separate roles per environment.
• Do not allow a pull request workflow from an untrusted branch to assume production roles.

Cloud-specific implementation notes:

Required cloud-side evidence:

• Trust policy or federated credential configuration
• Mapped GitHub repository, branch, tag, environment, or workflow
• IAM role/service account permissions
• Session duration or token TTL
• Last successful deployment using federation
• Exception record for any remaining static cloud key

9.5 Protect Deployment Environments

Use GitHub Environments for deployment approval gates.

Production environment requirements:

• Required reviewers
• Wait timer where useful
• Branch restrictions
• Environment-specific secrets
• Deployment history review
• No direct deployment from feature branches
• OIDC trust restricted to the production environment

Example:

jobs:
  deploy:
    environment: production
    permissions:
      contents: read
      id-token: write

9.6 Control Workflow Triggers

Be careful with these triggers:

pull_request_target
workflow_run
repository_dispatch
schedule

High-risk pattern:

on: pull_request_target

Why it matters:

pull_request_target runs in the context of the base repository and can access secrets if misused. Never check out and execute untrusted pull request code under this trigger without strong isolation.

Safer approach:

• Use pull_request for untrusted code validation.
• Use pull_request_target only for metadata operations such as labeling.
• Do not run scripts from the pull request under privileged context.
• Never expose secrets to untrusted fork workflows.

9.7 Protect Workflow Files

Any change to .github/workflows/** must require approval from a trusted platform/security team.

Required CODEOWNERS:

.github/workflows/ @org/devsecops @org/platform-engineering
.github/actions/ @org/devsecops @org/platform-engineering

Required checks:

• Workflow linting
• OIDC policy validation
• Action pinning validation
• Permission minimization check
• Secret usage review

9.8 Reusable Workflows

Use reusable workflows for secure defaults.

Recommended pattern:

• Central security-approved CI workflow repository
• Application repositories call reusable workflows
• Deployment logic is standardized
• OIDC permissions are centrally reviewed
• Security scanning is consistent

Example:

jobs:
  secure-build:
    uses: org/platform-workflows/.github/workflows/secure-build.yml@<commit-sha>
    permissions:
      contents: read
      security-events: write

10. Self-Hosted Runner Security

Self-hosted runners are one of the highest-risk areas in GitHub.

A runner executes code. If the runner has network access to internal systems, cloud metadata, deployment credentials, or shared workspace data, a malicious workflow can become an internal compromise path.

10.1 Avoid Persistent Shared Runners for Untrusted Code

Minimum standard:

• Do not run public repository workflows on internal self-hosted runners.
• Do not run fork pull requests on privileged self-hosted runners.
• Do not share the same persistent runner across different trust zones.
• Do not place runners in flat internal networks.
• Do not give runners standing cloud credentials.
• Prefer ephemeral runners for sensitive workflows.

10.2 Runner Trust Zones

Use separate runner groups:

10.3 Runner Hardening

Required controls:

• Use ephemeral runners where possible.
• Rebuild runner after each job or job group.
• Run as non-root where possible.
• Disable unnecessary tools.
• Block outbound internet except required destinations where practical.
• Restrict access to cloud metadata endpoints.
• Do not store secrets on disk.
• Clear workspace after job completion.
• Forward OS, runner, and workflow logs to central logging.
• Patch runner images regularly.
• Use separate runner registration tokens per group.
• Rotate runner registration tokens.
• Monitor unexpected runner registration and removal.

10.4 Network Segmentation

Production deployment runners should have only the network access required for deployment.

Bad pattern:

runner → entire VPC / entire corporate network

Better pattern:

runner → deployment API / artifact registry / secret broker / Kubernetes API through controlled endpoint

10.5 Runner Detection Coverage

Monitor for:

• New self-hosted runner added
• Runner group policy changed
• Runner assigned to additional repositories
• Workflow using unexpected runner labels
• Job running on production runner from non-production branch
• Unusual outbound connections from runner
• Access to metadata IP
• Unexpected process execution
• Secret exfiltration patterns
• Large artifact uploads

11. Secrets Management

Secrets in GitHub require strict control because workflows can expose them if incorrectly designed.

11.1 Use the Right Secret Scope

Use the narrowest scope:

Do not store production secrets as broad organization secrets unless absolutely necessary.

11.2 Replace Static Secrets with Federation

Priority order:

1. OIDC federation
2. Secret broker such as Vault or cloud secret manager with short-lived credentials
3. Environment-scoped GitHub secrets
4. Repository-scoped GitHub secrets
5. Organization secrets restricted to selected repositories
6. Long-lived cloud keys only by exception

11.3 Enable Secret Scanning and Push Protection

Enable:

• Secret scanning
• Push protection
• Validity checks where supported
• Custom secret scanning patterns for internal token formats
• Alerts to security team and repository owners

Push protection is important because it blocks many secrets before they enter the repository.

11.4 Secret Rotation

Rotate secrets:

• Immediately after exposure
• When a user with access leaves
• When a repository is transferred
• When an integration is decommissioned
• On a defined schedule for high-risk secrets
• After suspicious workflow execution

Minimum evidence:

• Secret owner
• Purpose
• Scope
• Created date
• Last rotated date
• Repositories with access
• Rotation procedure
• Emergency revocation procedure

12. Personal Access Tokens

Personal access tokens are a common bypass around SSO, MFA, and least privilege if not governed.

12.1 Restrict Classic PATs

Policy:

• Restrict classic PAT access to organization resources.
• Block classic PATs where possible.
• Require approval for any exception.
• Prefer fine-grained PATs.
• Require expiration.
• Require least-privilege scopes.
• Review active tokens regularly.

Classic PATs are risky because they can be broad, long-lived, and hard to govern.

12.2 Fine-Grained PAT Standard

Fine-grained PATs must have:

• Specific repository access
• Required permissions only
• Expiration date
• Business justification
• Owner
• Approval
• Review date

Forbidden:

• No-expiry tokens
• Broad all-repository access
• Tokens owned by personal accounts for production automation
• Tokens used where GitHub Apps or OIDC can replace them

12.3 Service Accounts and Automation

Preferred automation order:

1. GitHub App with minimal permissions
2. OIDC federation
3. Fine-grained PAT with expiry
4. Classic PAT only by exception

Automation accounts must:

• Be named clearly
• Have an owner
• Use MFA where applicable
• Have documented purpose
• Have access reviewed
• Store credentials in approved secret manager
• Avoid human shared use

12.4 PAT Containment Procedure

If a PAT is leaked or suspected compromised:

1. Revoke the token immediately.
2. Identify token owner.
3. Identify scopes and repositories accessible by the token.
4. Review audit logs for token activity.
5. Check repository clone, push, release, workflow, package, and secret access events.
6. Rotate any downstream secrets the token could access.
7. Rebuild artifacts if release integrity is uncertain.
8. Create incident ticket.
9. Add detection or prevention rule to stop recurrence.
10. Complete post-incident review.

13. OAuth Apps and GitHub Apps

Third-party integrations are a major data access path.

13.1 Restrict OAuth App Access

Enable OAuth App access restrictions for the organization.

Policy:

• Users cannot authorize OAuth Apps to access organization resources without approval.
• OAuth App requests must be reviewed by Security or Platform Engineering.
• Approved apps must have a business owner.
• Approved apps must have documented scopes.
• Unused apps are removed.
• Apps with broad access are reviewed quarterly.

Review checklist:

• Who owns the app?
• What repositories can it access?
• What scopes does it request?
• Does it require write access?
• Does it access private repositories?
• Does it store repository data externally?
• Is the vendor approved?
• Does the vendor have SOC 2 / ISO 27001 or equivalent evidence?
• Is there a safer GitHub App alternative?

13.2 Prefer GitHub Apps Over OAuth Apps

GitHub Apps are usually easier to scope because access can be limited to selected repositories and specific permissions.

Policy:

• Prefer GitHub Apps over OAuth Apps for organization integrations.
• Install only on selected repositories unless enterprise-wide access is justified.
• Avoid broad write permissions.
• Review installations quarterly.
• Remove unused installations.

13.3 App Inventory

Maintain an app inventory:

14. Repository Content and Secret Exposure Controls

14.1 Prevent Sensitive Data in Repositories

Do not store:

• Production secrets
• Private keys
• Customer data
• Database exports
• Access tokens
• .env files with secrets
• Cloud credentials
• SSH private keys
• Unredacted logs
• Vulnerability scan exports with exploitable details unless access-controlled
• Incident data unless access-controlled

Use .gitignore, pre-commit hooks, push protection, and CI scanning together.

Example .gitignore baseline:

.env
.env.*
*.pem
*.key
*.p12
*.pfx
id_rsa
id_ed25519
secrets.*
credentials.*
*.kubeconfig

14.2 Pre-Commit Controls

Recommended developer-side controls:

pre-commit install

Recommended hooks:

• Secret scanning
• YAML validation
• JSON validation
• Terraform formatting
• Dependency lockfile check
• Large file check
• Private key detection

Developer controls are helpful, but they are not enough. Server-side push protection and CI scanning are still required.

15. Code Security and Dependency Security

15.1 Code Scanning

Enable code scanning for supported languages.

Minimum standard:

• CodeQL or approved SAST tool enabled for active repositories.
• Pull requests fail on critical findings for production code.
• Findings are assigned to repository owners.
• False positives are documented.
• Suppressions require justification.
• Security team tracks SLA compliance.

Severity SLA example:

15.2 Dependency Security

Enable:

• Dependabot alerts
• Dependabot security updates
• Dependency review on pull requests
• Lockfile maintenance
• License review where required

Dependency review should block pull requests that introduce:

• Known critical vulnerabilities
• Disallowed licenses
• Unmaintained critical packages
• Suspicious package source changes
• Dependency confusion risk

15.3 Package Registry Controls

For GitHub Packages or external registries:

• Require MFA for publishers.
• Use automation tokens with least privilege.
• Require provenance or signed artifacts where possible.
• Restrict who can publish packages.
• Monitor package deletion and version overwrite attempts.
• Use immutable versioning where available.
• Separate dev, staging, and production package namespaces.

16. Software Supply Chain Controls

16.1 Artifact Attestations

Use artifact attestations for critical builds.

Goal:

• Prove where the artifact came from.
• Prove which workflow built it.
• Prove which repository and commit produced it.
• Support downstream verification.

Use this for:

• Container images
• Release binaries
• Packages
• Deployment artifacts

Minimum policy:

• Critical production artifacts require provenance.
• Deployment systems should verify provenance before deployment.
• Kubernetes admission control should enforce provenance for critical workloads where feasible.

16.2 Signed Releases and Tags

Recommended controls:

• Protect release branches.
• Protect release tags.
• Require signed tags for production releases where supported by release process.
• Restrict who can create releases.
• Restrict who can upload release assets.
• Monitor release creation, deletion, and asset changes.

16.3 Secure Build Separation

Separate:

PR validation → build → test → security scan → release → deploy

Do not allow untrusted pull request code to access production secrets or deployment roles.

17. Forks, Public Repositories, and Open Source Exposure

17.1 Private Repository Forks

Private forks can copy sensitive code into places with weaker controls.

Policy:

• Disable private repository forking by default.
• Approve forks only when required.
• Review fork access.
• Delete stale forks.
• Do not allow production secrets in fork workflows.
• Restrict Actions execution from forks.

17.2 Public Repository Controls

Public repositories require stricter review because mistakes are immediately exposed.

Minimum controls:

• Security review before publication.
• Legal/IP review before publication.
• Secret scan full history before publication.
• Dependency and license review.
• CODEOWNERS enabled.
• Branch protection enabled.
• No internal-only documentation.
• No customer data, credentials, endpoints, private architecture details, or exploit details.

17.3 Open Source Contribution Safety

For public repositories:

• Treat pull requests from forks as untrusted.
• Do not expose secrets to forked PR workflows.
• Use pull_request for code execution.
• Avoid pull_request_target unless strictly limited.
• Require maintainer approval before running workflows from first-time contributors.

18. GitHub Pages, Wikis, Discussions, and Issues

These features can expose data even when source code is controlled.

Policy:

• Disable GitHub Pages unless needed.
• Restrict Pages source branches.
• Review custom domains and DNS ownership.
• Disable Wikis unless needed.
• Disable Discussions unless needed.
• Use issue templates with data-handling warnings.
• Do not allow secrets, customer data, incident details, or vulnerability details in issues.
• Use private vulnerability reporting or security advisories for vulnerability intake.

19. Copilot and AI Coding Controls

If GitHub Copilot or AI coding tools are enabled, govern them like development tooling with data exposure risk.

Minimum controls:

• Define approved use cases.
• Prohibit pasting secrets, customer data, private keys, or regulated data into prompts.
• Configure enterprise policy settings available in your plan.
• Require developers to review AI-generated code like human-written code.
• Require SAST/SCA scanning for AI-assisted code.
• Track insecure code patterns introduced through AI-assisted development.
• Ensure license and dependency risks are reviewed.

Operational rule:

AI-generated code does not bypass secure coding, review, testing, or security scanning.

20. Audit Logging and SOC Monitoring

GitHub logs must be monitored like cloud control-plane logs.

20.1 Export Audit Logs

Send GitHub audit logs to the SIEM or central log lake.

Required log sources:

• Enterprise audit log
• Organization audit log
• GitHub Actions workflow events
• Repository events
• Secret scanning alerts
• Code scanning alerts
• Dependabot alerts
• Authentication and SSO events
• OAuth and GitHub App events
• Runner events
• Branch/ruleset changes
• Repository visibility changes

20.2 High-Value Detection Use Cases

Monitor these events:

20.2.1 Production Detection Specification Template

Each high-value GitHub detection should be deployed as a managed detection, not just a checklist item.

Use this template:

rule_id: GH-DET-0001
name: Organization Owner Added
threat_scenario: Privilege escalation or persistence through GitHub organization ownership
data_sources:
  - GitHub organization audit log
  - Identity provider logs
  - Change management tickets
severity: Critical
confidence: High
logic: >
  Alert when an organization owner is added, restored, or when ownership is granted
  outside an approved change window or without a matching change ticket.
required_fields:
  - actor
  - target_user
  - organization
  - action
  - timestamp
  - source_ip
  - user_agent
  - SSO/IdP context
false_positives:
  - Approved emergency ownership recovery
  - Planned administrative change
triage:
  - Validate change ticket and approver
  - Verify actor identity and MFA/SSO status
  - Review actor's recent GitHub activity
  - 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 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:

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

21. Incident Response Playbooks for GitHub

21.1 Compromised User Account

Immediate actions:

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

21.2 Leaked Secret

Immediate actions:

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

21.3 Malicious Workflow Execution

Immediate actions:

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

21.4 Suspected Source Code Exfiltration

Immediate actions:

1. Preserve audit logs.
2. Identify actor and repositories accessed.
3. Determine clone/download scope.
4. Disable compromised access.
5. Review tokens and apps used.
6. Engage Legal/Privacy if regulated or sensitive data may be involved.
7. Rotate embedded secrets if any.
8. Review public exposure risks.
9. Prepare executive summary.
10. 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:

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.

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

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

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:

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.

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.