Study Guide

With personal accounts, each person creates and signs in to their own GitHub.com account and is invited into your organizations. You can add SAML SSO so they must also authenticate with your identity provider (IdP), and SCIM can provision their access to individual organizations, but the account itself stays theirs and they can still contribute anywhere on GitHub.com.

With Enterprise Managed Users (EMU), your IdP provisions the accounts through SCIM and controls usernames, profile names, email addresses, organization membership, and repository access. Users authenticate only through the IdP (SAML, or OIDC with Entra ID), and they have no password or 2FA stored on GitHub. Learn's comparison adds that enterprise owners can audit everything managed users do, that managed users can't change their own metadata, and that there are no public repositories.

Managed users are deliberately fenced in. They can view public content on GitHub.com but can't push, open issues or pull requests, comment, react, star, watch, or fork outside the enterprise; they can't create gists or public repositories, can't be invited to other enterprises, and are visible only to members of their own enterprise. They also can't sign up for Copilot Free or Pro: Copilot comes from the enterprise's Business or Enterprise subscription.

Choose EMU when you need the IdP to be the source of truth and want to prevent accidental leaks to the public; choose personal accounts when developers must contribute outside the enterprise or when IdP-driven onboarding would be too complex. GitHub Enterprise Cloud with data residency requires EMU, and switching an existing personal-account enterprise to EMU means migrating to a new enterprise account.

SAML single sign-on requires GitHub Enterprise Cloud. You can set it up for one organization (enable, test, then enforce) or for the enterprise. While SAML is enabled but not enforced, members are prompted to link an IdP identity but can still reach resources. Enforcing it on an organization removes members who haven't authenticated through the IdP; requiring it for the enterprise removes no one, and people must authenticate the next time they access enterprise resources. An enterprise SAML configuration overrides any organization-level SAML.

To configure enterprise SAML you enter the IdP's sign-on URL, an optional issuer, and the IdP's public certificate, choose the signature and digest methods, and must pass Test SAML configuration before saving. Save the single sign-on recovery codes so owners can still get in if the IdP is down. If you use personal accounts and want SCIM, configure SAML at the organization level, because SCIM for personal-account enterprises works per organization.

Requiring 2FA is an organization (or enterprise) security setting. Outside collaborators without 2FA, including bot accounts, are removed and lose access to the organization's repositories and their forks of private ones; members and billing managers keep their membership and keep consuming licenses but can't reach organization resources until they enable 2FA. You must have 2FA on your own account first, and you can reinstate removed collaborators within three months. Older Learn units say everyone without 2FA is removed; current docs say otherwise.

You can also require secure methods only. Passkeys, security keys, authenticator apps, and GitHub Mobile are secure; anyone relying on SMS is blocked until they switch. The enterprise-wide 2FA policy isn't available with Enterprise Managed Users, because managed accounts authenticate only through the IdP.

SCIM (System for Cross-domain Identity Management) lets the IdP add, update, and remove access automatically. For an enterprise with personal accounts it works per organization with SAML SSO: the IdP invites people to the organization and removes them when access is revoked. Supported IdPs for organization SCIM are Microsoft Entra ID, Okta, and OneLogin. It runs through an OAuth app authorized by an organization owner, so GitHub recommends a dedicated owner account for it, and the SAML NameID must match the SCIM userName for each user. Without SCIM, SAML SSO alone doesn't deprovision anyone.

Team synchronization maps a GitHub team to an IdP group so that group membership changes flow to the team. It isn't a provisioning service: a person is added to a team only if they're already an organization member. It works with Entra ID (commercial tenants) or Okta, needs SAML SSO and a linked SAML identity, and Okta additionally needs SAML and SCIM set up plus an SSWS token from a read-only admin service user. If SAML is configured at the enterprise, team sync is enabled for the whole enterprise, not per organization.

With Enterprise Managed Users you don't use team sync. The EMU SCIM integration provisions the accounts themselves and can link IdP groups to teams, managing organization membership as well as team membership. Team sync has its own limits (5,000 members per team, 10,000 per organization, 1,500 teams per organization) that don't apply to SCIM group linking. When you disable team sync, members it added stay on their teams with their access.

For an enterprise or organization with personal accounts, GitHub supports SAML SSO with any IdP that implements SAML 2.0, and officially supports and tests Microsoft AD FS, Microsoft Entra ID, Okta, OneLogin, PingOne, and Shibboleth. GitHub doesn't support SAML Single Logout: to end a session, users sign out at the IdP.

For Enterprise Managed Users, GitHub recommends a single partner IdP for both authentication and SCIM provisioning, the paved-path integration GitHub fully supports: Microsoft Entra ID (SAML or OIDC), Okta (SAML), or PingFederate (SAML). Any other system must follow GitHub's integration guidelines, authenticate with SAML 2.0, and provision with SCIM 2.0 through GitHub's REST API, and mixed or untested combinations get limited help from Support. The combination of Okta and Entra ID for SSO and SCIM isn't supported at all. Choosing OIDC with Entra ID lets GitHub check the IdP's Conditional Access Policy.

GitHub Enterprise Server offers built-in authentication (local accounts) or external authentication with CAS, LDAP, or SAML; you can use SAML or LDAP but not both. External authentication can allow built-in fallback for people who have no account in the provider, such as a contractor or a machine user. Accounts are created just in time when someone first signs in, or, with SAML, provisioned in advance through SCIM. Learn's units also mention LDAP directories such as Active Directory and OpenLDAP for GHES.

People authenticate in the browser with a username and password plus 2FA, a passkey, social login, or (for managed users) only the IdP. Git over HTTPS needs a personal access token, GitHub CLI, or a credential helper, since password authentication for Git has been removed; Git over SSH needs an SSH key. Deploy keys are SSH keys attached to a single repository, read-only unless you grant write access.

When an organization uses SAML SSO, two layers apply. In the browser, members need an active SAML session, which generally lasts 24 hours unless the IdP says otherwise. For Git and the API, they must authorize each personal access token or SSH key for use with that organization. Apps also need an active SSO session when a user authorizes them, and existing OAuth and GitHub App authorizations must be reauthorized after SSO is turned on. Outside collaborators don't need SSO.

For automation, GitHub recommends a fine-grained personal access token for personal use, a GitHub App to act on behalf of an organization or other users (OAuth apps work but give less control), and the built-in GITHUB_TOKEN inside GitHub Actions, which reaches only the workflow's repository. Token prefixes identify the type: ghp_ (classic PAT), github_pat_ (fine-grained PAT), gho_ (OAuth), ghu_ and ghs_ (GitHub App user and installation tokens), ghr_ (GitHub App refresh token).

Authorization inside GitHub is role-based: enterprise roles, organization roles, team roles, and repository roles. When someone gets access from several sources, the highest grants apply and permissions add up.

The five predefined repository roles, from least to most access, are Read (view and discuss), Triage (manage issues, discussions, and pull requests without write access), Write (push), Maintain (manage the repository without sensitive or destructive actions), and Admin (everything, including security settings and deleting the repository). You can grant them to members, outside collaborators, and teams. Access is additive: someone with Read through a team and Write as a direct collaborator effectively has Write.

Organization roles include owners (full control; keep at least two), members (the default; by default they can create repositories and projects), moderators (block and unblock non-member contributors, set interaction limits, hide comments in public repositories), billing managers (billing only, no license used), security managers (manage security alerts and settings organization-wide, with read access to every repository), and GitHub App managers (manage the settings of app registrations the organization owns, but not install them). Outside collaborators get access to specific repositories without being members; with managed users they're called repository collaborators.

Custom repository roles start from an inherited role and add permissions such as deleting issues, managing webhooks or deploy keys, bypassing branch protections, or viewing and dismissing security alerts. A GitHub Enterprise Cloud organization can create up to 20, and anyone with admin access to a repository can assign them. Custom organization roles grant permissions across all current and future repositories and organization settings, for example letting a team view the audit log without owner rights.

Teams make this manageable: grant a team a repository role once instead of each person. Team maintainers can manage team membership, settings, and review assignment, and child teams inherit their parent team's access.

Organization teams live inside one organization. Enterprise teams are created by enterprise owners under the enterprise's People settings and can include organization members, unaffiliated users, and outside collaborators from across the enterprise. GitHub recommends enterprise teams for anything that applies to the enterprise or to several organizations, and organization teams when the need is scoped to one organization.

An enterprise team can receive Copilot Business licenses directly from the enterprise, be assigned predefined or custom enterprise roles, be added to organizations, receive bypass access on rulesets, and be mentioned or requested for review in issues and pull requests (its slug has an ent: prefix). When you give the team access to an organization, its members join directly, without an invitation, with the organization's base repository permissions; organization admins can add access but can't remove what the enterprise granted. Outside collaborators added to the team become enterprise members and consume a license.

You add members manually, through the REST API, or, with Enterprise Managed Users only, by syncing the team to an IdP group (the team must have no manually added members first). Enterprise teams don't yet support nested teams, team maintainers, secret teams, project boards, CODEOWNERS status, or team sync for personal-account enterprises. Limits: 2,500 teams per enterprise, 5,000 users per team, and 1,000 organizations per team.

At the repository level, the Collaborators and teams settings page lists every team and person with access and their role, lets you change or remove access, and flags "Mixed roles" when someone receives conflicting access from different sources. Remember that effective access is the highest role a user gets from direct grants, teams, and the organization's base permission.

At the enterprise level, the People pages show administrators, members (with an overview by role, license type, and deployment), outside collaborators and the repositories they can reach, pending invitations, suspended managed users, dormant users, members without a verified-domain email, and whether members have 2FA. The membership information report (a CSV from the People page) lists everyone associated with the enterprise, licensed or not, with their organizations, owner or member status, pending invitations, and 2FA status and strength.

To see how access changed over time, search the organization or enterprise audit log for membership, permission, and team events, and for large estates script the REST or GraphQL APIs to list collaborators, teams, and permissions continuously. Learn also recommends branch protection and required reviews so every change is accountable.

Enterprise policies control what organizations may do: base repository permission (none, read, write, or admin), who can create, delete, or transfer repositories and which visibilities they may use, forking of private and internal repositories, inviting outside collaborators, and security settings such as required 2FA. For each, the enterprise either enforces a value, which locks the organization setting, or lets organization owners decide. Internal repositories are the default for new repositories in an enterprise's organizations and stay readable to enterprise members even with a base permission of none.

Rulesets are named lists of rules for branches, tags, or pushes, available on GitHub Team and Enterprise plans, at the repository, organization, or enterprise level (up to 75 per repository plus 75 organization-wide). Several rulesets can target the same branch and combine with branch protection rules; when the same rule appears more than once, the most restrictive version applies. Each ruleset is Active, Evaluate (logs would-be violations on Rule Insights without blocking), or Disabled, so you can test before enforcing, and anyone with read access can view active rulesets. Push rulesets block pushes by file path, extension, path length, or size across the repository's whole fork network, and delegated bypass lets reviewers approve exceptions.

Bypass lists name the roles, teams, or GitHub Apps allowed to skip a ruleset, such as a release team or an automation app. Roles complete the picture: enterprise owners, billing managers, app managers, security managers (public preview), and custom enterprise roles (public preview) let you delegate enterprise settings without granting ownership. Organization owners can't edit roles or assignments defined at the enterprise level.

Learn's split is practical. Administrators manage repository access, remove sensitive data from commits, restore recently deleted branches, and own infrastructure configuration, CI/CD integrations, third-party authentication such as SAML, internal scripts, hardware, and immediate on-premises fixes. GitHub Support handles account recovery (for example lost 2FA credentials), billing and subscription issues, takedown requests such as DMCA notices, help after a compromised account, abuse investigations, restoring force-pushed commits in limited cases, and clearing cached views after a history rewrite.

Current docs move one item: organization owners can restore a deleted repository themselves within 90 days, unless it belonged to a fork network that isn't empty, in which case Support can help. Older training lists repository recovery as Support-only.

GitHub Docs lists what's out of scope: third-party integrations such as Jira, CI/CD tools such as Jenkins, Azure DevOps, writing scripts, configuring external authentication systems such as SAML IdPs, open-source projects, writing CodeQL queries, cloud network setup, container orchestration, preview features, Copilot suggestions, and explanations of Copilot or metered usage. Support doesn't help with discontinued GHES releases, and during a security incident it answers questions but doesn't investigate for you. For guided help beyond scope, GitHub points to Expert Services.

To open tickets for the enterprise account you need a support entitlement: enterprise owners and billing managers have one, and owners can grant it to members (any organization member can open a ticket for their own organization). Tickets get a priority of Low, Normal, High, or Urgent; Urgent is only for Premium Support customers. Include URLs, exact error messages, reproduction steps, and logs, and use English (or Japanese where your plan allows).

A support bundle is a gzip-compressed archive with a diagnostics file plus sanitized logs: authentication logs (useful for LDAP, CAS, or SAML problems), the Management Console log, exceptions, audit, Git proxy, and HAProxy logs, configuration logs, and service status. Tokens, keys, and secrets are removed, and bundles contain no repository content. GitHub Support uses them to investigate performance problems, outages, authentication failures, and upgrades, and you can also use a bundle to generate a Health Check report.

A standard bundle holds about two days of logs; an extended bundle holds about eight days and includes rotated logs, core dumps, and a disk usage report. You can create a standard bundle from the Management Console (Support, then Download support bundle) or over SSH with ghe-support-bundle -o. Extended bundles need the command line (ghe-support-bundle -x), and -p sets a custom period. Clusters and geo-replication configurations use ghe-cluster-support-bundle instead.

To share a bundle, use the upload link in the ticket confirmation email or a support engineer's link, upload it at support.github.com/uploads, upload it from your GitHub Enterprise Cloud enterprise's License settings, or send it straight from the appliance with ghe-support-bundle -u (add -t TICKET_ID to attach it to a ticket). Direct upload needs outbound HTTPS to GitHub's bundle servers. The separate diagnostics file, a plain-text overview of the instance, is covered under monitoring.

Learn recommends choosing the collaboration model by audience: branching inside shared repositories for internal teams, and fork-and-pull for open-source or cross-organization work. Pair it with consistent branch naming (for example feature/* and bugfix/*) and a stable integration branch such as main or develop for CI/CD. Rulesets are GitHub's recommended way to enforce those standards across repositories.

Document standards where everyone sees them. For automation, Learn suggests recording storage repositories, naming conventions, the location of shared components, maintenance plans, and contribution guidelines in a wiki or a Markdown file available to the whole organization. For contributor guidance, put default community health files (CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, SUPPORT, issue and pull request templates) in the organization's .github repository; GitHub shows them for any repository without its own file. That repository must be public, or internal in an enterprise with managed users, and you can't set a default LICENSE.

Learn also frames the administrator's toolkit in two groups: upkeep features that keep access secure and supported (SAML and SCIM, GitHub Connect, Pages access control, Enterprise Support) and automation features that reduce manual work (GitHub Advanced Security, GitHub Actions, automatic security updates). Prefer marketplace tools from verified creators when standardizing on integrations.

GitHub flow is the lightweight default: create a descriptively named branch, commit isolated changes, open a pull request (a draft if you want early feedback), address review comments, merge, and delete the branch. Linking the pull request to an issue with a keyword closes the issue on merge.

Review standards live in branch protection rules or rulesets. Require pull request reviews with a minimum number of approvals, optionally require review from code owners (people or teams listed in a CODEOWNERS file in the .github, root, or docs folder of the base branch, who must have write access), dismiss stale approvals when new commits change the diff, or require approval of the most recent push by someone other than its author. Add required status checks, conversation resolution, signed commits, linear history, or a merge queue as needed. By default, admins can bypass these rules unless you include them.

Merge standards decide history shape: a merge commit (the default), squash and merge (one commit per pull request, losing individual commit detail), or rebase and merge (commits added individually without a merge commit). Repository settings or a ruleset can restrict which methods are allowed; requiring linear history blocks merge commits.

Releases package a tag with release notes, which you can generate automatically, and binary assets (up to 1,000 per release, each under 2 GiB), plus automatic source archives. Anyone with read access can view releases; managing them needs write access. Publish a security advisory alongside a release that fixes a vulnerability.

GitHub Enterprise Cloud (GHEC) with personal accounts: GitHub hosts everything on GitHub.com, and people use their own accounts, optionally with SAML SSO so they must also sign in to your IdP. User accounts aren't provisioned; SCIM can only provision access to individual organizations. Choose it when developers need to work outside the enterprise or when IdP-driven onboarding would be too complex.

GHEC with Enterprise Managed Users (EMU): still on GitHub.com, but your IdP provisions and controls the accounts, and users authenticate only through it (SAML, or OIDC with Entra ID). Managed users can't create public content or collaborate outside the enterprise. Choose it for strong central control and to prevent leaks; moving an existing enterprise to EMU means migrating to a new enterprise account.

GHEC with data residency + EMU: the enterprise runs on a dedicated subdomain of GHE.com with its code and data stored in a chosen region (currently EU, Australia, US, or Japan) and must use EMU. Network details such as IP ranges differ from GitHub.com, and some features may not be available yet. It suits regional compliance without self-hosting: GitHub handles maintenance and upgrades and new features arrive as on GitHub.com.

GitHub Enterprise Server (GHES): a self-hosted virtual appliance on Hyper-V, OpenStack KVM, or VMware ESXi on-premises, or on AWS, Azure, or Google Cloud. You control the network, IAM, and monitoring, and you apply upgrade packages and hotpatches. Users sign in with built-in authentication, CAS, LDAP, or SAML. GitHub Connect can link GHES to your GHEC enterprise for license sync, Dependabot alerts, GitHub.com actions, and unified search and contributions, without exposing private data or opening the instance to the internet.

Each month an enterprise is billed for the GitHub Enterprise licenses it uses, any usage of metered products such as GitHub Actions or Codespaces beyond the plan's included allowance, and extra products such as GitHub Copilot or GitHub Advanced Security products. Learn's billing unit frames it as subscription and license charges (for example Copilot seats) plus usage-based charges.

Licensing is per unique user. The GitHub Enterprise plan entitles you to GitHub Enterprise Cloud (one deployment, on GitHub.com or GHE.com) and GitHub Enterprise Server, and a person consumes one license no matter how many GHES instances or GHEC organizations they use, as long as license usage is synced so GitHub can deduplicate users by email address.

There are two license billing models. Usage-based (metered) billing charges each month for licenses actually consumed, prorates users who start mid-cycle, and is cloud-first: users must be added on GHEC, and GHES license files are generated for the consumed count and expire after 12 months. Volume (subscription) licensing is a fixed number of licenses bought through GitHub Sales that covers both GHEC and GHES. Enterprises created from a trial since August 1, 2024 are already usage-based; volume customers can switch at renewal.

Metered billing distinguishes consumed licenses (in use right now) from billable licenses (distinct users who held a license at any point in the cycle). Payment can be a credit card, PayPal, an Azure subscription, prepaid credits for invoiced volume customers, or purchase orders through Sales.

On GitHub Enterprise Cloud, a license is consumed by organization members and owners, enterprise owners who belong to at least one organization, outside collaborators on private or internal repositories (counted once each), and dormant users who belong to an organization. Billing managers, suspended managed users, enterprise owners in no organization, guest collaborators who aren't members or repository collaborators, unaffiliated users, and outside collaborators on public repositories don't. Pending invitations consume a license only without usage-based billing or EMU. On GHES, every user who has authenticated, including dormant users, consumes one; suspending dormant users frees licenses.

The enterprise's Licensing page shows consumed Enterprise Cloud licenses and, depending on the model, the estimated monthly payment (usage-based) or total licenses and expiration date (volume). More details breaks usage down, and Download CSV report exports it. License history, in public preview for usage-based enterprises without Visual Studio bundles, records daily license additions and removals, who made them, and when they affect the bill.

For combined use, sync GHES license usage to GHEC weekly through GitHub Connect, trigger a sync from the GHES Licensing settings, or export a license usage file from GHES and upload it to GHEC. Only user IDs and email addresses are transmitted. The Licensing page shows when the last sync happened. Learn's license units add practices such as reclaiming unused seats, auditing monthly or quarterly, and reviewing machine accounts, which consume a license like any user.

Learn frames policy as a trade-off between trust and control. Low control relies on guidance and best practices (security advisories, code scanning, Dependabot alerts, optional reviews) and suits teams that need flexibility. Moderate control enforces rules such as required branch protection, commit signing, organization-wide security policies, and monitoring webhooks. High control, for strict compliance such as SOC 2 or ISO 27001, enforces SAML SSO and 2FA, restricts visibility and forking, requires pull request approvals, blocks force pushes, and runs CI/CD security checks.

Organization owners set policies in organization settings (such as Member privileges); enterprise owners set them under the enterprise's Policies, where each policy is either enforced for all organizations or left to organization owners. An enforced enterprise policy overrides and locks the organization setting. Repository management policies cover base permissions, repository creation and visibility, forking of private and internal repositories, inviting outside collaborators (members, organization owners, or only enterprise owners), the default branch name, deploy keys, visibility changes, deletion and transfer, deleting issues, and renaming protected branches.

Other enterprise policy areas include security settings (required 2FA, SSH certificate authorities), personal access tokens, GitHub Actions, Codespaces, and code security and analysis, where enterprise owners decide whether repository admins can enable GitHub Secret Protection, GitHub Code Security, or GitHub Advanced Security features. Those products are billed per active committer, so that policy is also a cost control.

An enterprise IP allow list limits access to private resources to listed IP addresses or CIDR ranges. It applies to web sign-in and to non-interactive credentials: personal access tokens, OAuth app tokens, SSH keys including deploy keys, and GitHub App tokens including GITHUB_TOKEN. It applies to every role, owners included, but not to anonymous access to public resources. Add your own IP first; organizations inherit the enterprise's entries and can add their own, and you can automatically allow the IP addresses configured by installed GitHub Apps. Enterprises using EMU with Entra ID and OIDC can instead use the IdP's allow list.

Security configurations are collections of enablement settings for security features that you apply to repositories across an organization or enterprise; global settings set organization-level behavior inherited by all repositories. Some features are in every plan (dependency graph, Dependabot alerts). Others need a GitHub Advanced Security product on private and internal repositories: GitHub Secret Protection (secret scanning, push protection, custom patterns, AI-detected secrets) and GitHub Code Security (code scanning, Copilot Autofix, dependency review, security campaigns, security overview). Learn also notes the compliance reports GitHub provides for audits, such as SOC 1 Type 2, SOC 2 Type 2, and ISO/IEC 27001.

Data protection includes preventing and cleaning leaks. Use .gitignore and secret stores to keep secrets out, and push protection to block them. If a secret does land, revoke or rotate it first, because anything pushed should be treated as compromised. To purge it from history, current GitHub Docs use git-filter-repo with --sensitive-data-removal (version 2.47 or later) rather than the filter-branch and BFG commands in older training. Rewriting changes commit hashes, invalidates signatures, and can't clean other people's clones; GitHub Support removes cached views only when rotating credentials can't mitigate the risk.

Each audit log entry is named category.operation (for example repo.create) and records the organization or enterprise, the actor and affected user, the repository, the action, the country, the time, the actor's SAML and SCIM identity, how they authenticated outside the web UI, and optionally the source IP address. Enterprise owners can search it in the web UI, filter by qualifiers such as action, actor, repo, and created, export it, and identify every event performed by a specific access token.

Retention on GitHub Enterprise Cloud is 180 days for audit events and seven days for Git events, and the web view shows three months unless you add a created date range. Older Learn units say 90 days (120 on GHES) and describe a log-retention setting; current docs have neither, so long-term retention means streaming. The REST audit log API needs the read:audit_log scope and allows 1,750 queries per hour per user and IP address. Webhooks can be more efficient than polling when you only need to react to an event.

Audit log streaming sends audit and Git events for the whole enterprise, as compressed JSON, to Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage, or Splunk, from the time it's enabled. A paused stream buffers seven days; a health check runs every 24 hours and emails owners about misconfiguration. API request events and source IP display are off by default and should be enabled before you need them.

The dependency graph parses manifests such as package.json and requirements.txt. Dependabot alerts watch it and cross-reference dependency versions with GitHub Security Advisories, alerting when a dependency is vulnerable or malicious. Both are in every plan, and you can enable alerts for a repository, organization, enterprise, or personal account.

Secret scanning detects supported secrets, custom patterns, and (optionally) generic and AI-detected secrets already committed, and raises alerts on the repository's security tab; partner alerts go directly to the issuing provider. Push protection blocks secrets before they land, on command-line pushes, web commits, file uploads, and API requests; a contributor who bypasses it creates an alert, and delegated bypass can require reviewers' approval. Push protection for users is on by default for public repositories; push protection for repositories requires GitHub Secret Protection and is enabled by repository admins, organization owners, security managers, or enterprise owners.

Code scanning analyzes code for vulnerabilities and errors using CodeQL or third-party tools that upload SARIF results, and Copilot Autofix suggests fixes. Start with default setup: in the repository's Advanced Security settings choose CodeQL analysis, then Default. The repository needs GitHub Actions enabled and, if private, GitHub Code Security, and scans consume Actions minutes. Advanced setup (a workflow file) gives more control.

Dependabot security updates open pull requests that raise a vulnerable dependency to the minimum version with the fix, linked to the alert. When enabled, Dependabot tries to fix every open alert with a patch, and alerts close when the pull requests merge. Dependabot version updates, configured by committing a dependabot.yml file, open pull requests to keep dependencies on the latest versions even without vulnerabilities, including actions and reusable workflows referenced in workflow files. Version updates wait a default three-day cooldown after a release; security updates don't. Dependabot signs its own commits.

Repository security advisories let maintainers of public repositories create a draft advisory, discuss the impact privately, fix the vulnerability in a temporary private fork, and publish when the patch is ready. GitHub is a CVE Numbering Authority and can assign a CVE. Published advisories for ecosystems the dependency graph supports go to the GitHub Advisory Database, and GitHub may send Dependabot alerts to affected repositories.

Private vulnerability reporting, enabled by owners and admins of a public repository, lets anyone report a vulnerability privately through an advisory form. It's separate from SECURITY.md, which tells people how to report and which versions are supported.

Before an incident, enable the investigative tooling that's off by default: stream the enterprise audit log (including API request events) to a SIEM, display source IP addresses in the audit log, and retain identity provider logs. Streaming captures activity only from when it's enabled, so it can't be switched on mid-incident to recover history. Learn which tools exist and their limits, and practise containment actions such as revoking credentials, enabling an IP allow list, and suspending users; enterprise owners also have bulk actions such as locking down SSO and deleting all user tokens and keys.

Write a Security Incident Response Plan (SIRP) that defines roles and responsibilities, escalation paths, communication protocols, severity classification, and step-by-step procedures for common threats. GitHub's response guide follows six steps: assess and validate the signal, contain the threat, investigate fully, remediate (rotate tokens and secrets, look for persistence, audit dependencies), document, then reflect and harden. Repository basics such as SECURITY.md, security advisories, and private vulnerability reporting complete the plan for externally reported issues.

GitHub Support handles security matters in writing and can explain features and the data available to you, but it doesn't investigate, join or lead your response, revert changes, restore data, or preserve or extend logs. Learn's support unit says Support can help roll back repository changes; current docs say it can't, so plan to recover from your own backups and logs.

Personal access tokens replace passwords for the API and Git over HTTPS and act with their owner's access, limited by the token's scopes or permissions. For organizations or long-lived integrations, use a GitHub App instead. Fine-grained tokens (prefix github_pat_) are scoped to one user or organization, optionally to specific repositories, with specific permissions, and can require organization approval. Classic tokens (ghp_) use broad scopes and are still needed for some tasks: contributing to public repositories you don't belong to or where you're an outside collaborator, reaching several organizations at once, enterprise account APIs, and Packages.

Organization owners can restrict or allow access by classic and fine-grained tokens and set a maximum lifetime. Enterprise owners set the same policies separately for each token type: allow organizations to decide (the default), restrict, or allow; restrict and allow can't be overridden by organizations. Tokens always keep access to public resources, and SSH keys created with a restricted token keep working. Fine-grained tokens default to a 366-day maximum lifetime; classic tokens have no expiration requirement. Non-compliant tokens are blocked, not revoked.

Only fine-grained tokens can be subject to approval; by default organizations require it, and the enterprise can require or disable approval for all organizations. GitHub removes tokens unused for a year. Under SAML SSO, a token must also be authorized for the organization.

Unauthenticated requests get 60 per hour, counted by IP address. An authenticated user gets 5,000 per hour, shared by their personal access tokens and any GitHub App or OAuth app acting on their behalf; requests made for the user by a GitHub App owned by a GitHub Enterprise Cloud organization get 15,000. Learn's logging unit gives the same 60 and 5,000 figures.

A GitHub App installation token gets at least 5,000 requests per hour; on a GHEC organization or enterprise it gets 15,000. Elsewhere, installations gain 50 requests per hour for each repository or user beyond 20, up to 12,500, so App limits scale while OAuth apps (which use the user's limit) don't. GITHUB_TOKEN in Actions gets 1,000 per hour per repository, or 15,000 for GHEC resources. The enterprise audit log API has its own 1,750 queries per hour.

Track usage with the x-ratelimit-limit, -remaining, -used, -reset, and -resource response headers, or GET /rate_limit, which doesn't count against the primary limit. Secondary limits guard against bursts: no more than 100 concurrent requests, per-minute point limits (most REST reads 1 point, writes 5), CPU-time limits, and content creation of about 80 requests per minute and 500 per hour. Handle 403 and 429 responses by waiting rather than retrying immediately.

GitHub prefers GitHub Apps: they use fine-grained permissions, let the installer choose repositories, use short-lived tokens, can act independently of a user (or for a user with a user access token), receive centralized webhooks for everything they can access, and get rate limits that scale. OAuth apps act only as the authorizing user, need webhooks configured per repository or organization, and have lower limits. GitHub Docs notes one case for OAuth apps: accessing enterprise-level resources such as the enterprise object itself.

Organization owners install GitHub Apps on the organization; repository admins can install one if it requests no organization permissions and only their repositories, and an app needing organization permissions requires owner approval. GitHub App managers can edit the settings of apps the organization owns but can't install them. OAuth apps are authorized by individual users; revoking an OAuth app deletes SSH keys it created, including deploy keys. Enterprise-owned GitHub Apps can be installed only on the enterprise or its organizations.

Learn compares Marketplace integrations: GitHub Actions run per triggering event on GitHub-hosted or self-hosted runners with the temporary GITHUB_TOKEN and are billed by minutes; GitHub Apps run as services that receive webhooks and authenticate with a JWT and an installation token. Choose actions for event-driven automation and apps for persistent services with deeper API needs.

With OAuth app access restrictions on (the default for new organizations), members and outside collaborators can't let OAuth apps reach organization resources. They request approval and owners approve or deny. When restrictions are first set up, apps the organization owns keep access while other OAuth apps, and SSH keys they created, lose it. Without restrictions, any OAuth app a member authorizes can reach private organization resources.

For GitHub Apps, owners can restrict installation to organization owners, so repository admins must use the request flow. Owners can also stop members or outside collaborators from requesting unapproved apps (blocking member requests is in public preview), review installed apps, and change which repositories each can reach. Learn adds that admins should prefer tools with a verified creator badge and watch for permission changes.

SAML SSO adds another check: users need an active SSO session to authorize an app for the organization, and apps authorized before SSO must be reauthorized. The enterprise IP allow list can automatically include the IP addresses that installed GitHub Apps declare, so legitimate app traffic isn't refused.

Learn recommends central repositories for reusable components, for example one for custom actions, one for reusable workflows, and one for shared scripts, with clear naming, semantic versioning, README and CHANGELOG files, restricted write access with code-owner reviews, and a deprecation plan. Pin consumers to a version tag or commit rather than a moving reference, and document corporate standards (storage repositories, naming, shared component locations, maintenance, contribution guidelines) where everyone can read them.

To share without publishing, store the action or reusable workflow in an internal or private repository and, in that repository's Actions settings, allow access from workflows in other repositories in the organization or enterprise. Workflows in internal and private repositories across the enterprise can then use it; public repositories can't use actions from internal repositories. Runners download the action with a scoped, read-only installation token that expires after an hour.

A reusable workflow is triggered with workflow_call and called with a single uses line at the job level. It shares whole jobs, each choosing its own runner and logged separately, can nest up to ten levels deep, and one file can call at most 50 unique reusable workflows. GITHUB_TOKEN permissions can only stay the same or get more restrictive down the chain. A composite action bundles steps that run as one step inside the caller's job. Workflow templates live in the workflow-templates directory of the organization's .github repository as a .yml file plus a .properties.json metadata file; $default-branch is replaced with the repository's default branch.

Without enterprise policies, organization owners (and users with the "Manage organization Actions policies" permission) control Actions for their organizations. Enterprise owners can enable Actions for all, specific, or no organizations; disabling it also blocks code scanning and Code Quality analysis. The allowed-actions policy is one of: allow all actions and reusable workflows; allow enterprise actions only (which blocks even GitHub-authored actions such as actions/checkout); or allow enterprise plus selected non-enterprise actions, with options for actions created by GitHub, Marketplace actions from verified creators, and a list of specific actions or patterns (OWNER/REPOSITORY@TAG-OR-SHA, wildcards allowed). You can also require every action to be pinned to a full-length commit SHA.

Workflow permissions set the default GITHUB_TOKEN access: read-only (contents and packages) or read and write. Enterprises and organizations created on or after February 2, 2023 default to read-only; older ones default to read and write, which Learn's unit recommends tightening. Workflow authors can still adjust a workflow's permissions key. Fork pull request settings decide which outside contributions need approval before workflows run (first-time contributors new to GitHub, first-time contributors, or all outside collaborators) and, for private repositories, whether fork workflows run at all and whether they get write tokens or secrets.

Other enterprise Actions policies cover repository-level self-hosted runners, disabling standard GitHub-hosted runners, custom images, and retention for artifacts and logs (90 days by default, configurable up to 90 days for public and 400 days for private and internal repositories). Learn's unit describes options such as "Allow only actions created by GitHub" and a 30-day audit log retention setting that current docs don't have; the cards use the current policy names.

GitHub-hosted runners are maintained by GitHub, update automatically, give a clean instance for every job, and consume plan minutes. Self-hosted runners run on machines you provide (cloud or on-premises), update only the runner application automatically, and leave the OS and tools to you; they don't give each job a clean machine, cost nothing in Actions minutes, and can reach internal networks and special hardware. Learn's units (from 2024) say GitHub-hosted runners aren't available to GitHub Enterprise Server.

Larger runners are GitHub-hosted machines with more CPU, RAM, and disk, plus options such as static IP addresses, Azure private networking, custom images (Linux and Windows), GPUs, autoscaling, and concurrency limits. Runner groups collect larger and self-hosted runners into a security boundary: owners choose which organizations, repositories, and workflows can use each group, and jobs can target a group. A runner belongs to one group at a time and starts in the default group. Enterprises can disable standard GitHub-hosted runners so jobs must go through groups.

Self-hosted runners on public repositories are dangerous: anyone who can fork and open a pull request may run code on the machine and reach secrets or a write-capable GITHUB_TOKEN. Enterprise owners can stop repository admins adding repository-level runners (for all organizations or for EMU repositories). Prefer ephemeral runners, registered with config.sh --ephemeral, which take a single job each; GitHub recommends them for autoscaling, with Actions Runner Controller as the reference Kubernetes autoscaler.

An organization or enterprise IP allow list also applies to runners, because their tokens are non-interactive credentials. Standard GitHub-hosted runners use dynamic addresses from GitHub's published ranges (listed by the meta API at api.github.com/meta), which change and are hard to allow-list. Learn suggests self-hosted runners when you need an IP allow list; add each self-hosted runner's address to the list. Larger runners on Linux and Windows can instead get static IP addresses from a range assigned to you.

Azure private networking places a GitHub-hosted larger runner's network interface into your Azure virtual network subnet, in the same region. The runner can reach private and on-premises resources without opening internet ports, your network security rules and outbound policies apply, and you can monitor its traffic. It's available only for larger runners (2–64 vCPU Ubuntu and Windows), uses dynamic IPs, needs a supported Azure region, and is assigned to repositories through runner groups.

A self-hosted runner needs the runner application running, outbound HTTPS over port 443 to the GitHub domains its workflows use, and at least 70 kilobits per second of bandwidth. Learn's configuration unit shows proxy settings (http_proxy, https_proxy, no_proxy) and VPN access for private systems. With GitHub Enterprise Cloud data residency, runners need extra GHE.com hostnames.

The Runners page in repository, organization, or enterprise settings shows each runner's name, labels, and status: Idle (connected and ready), Active (running a job), or Offline (machine down, application stopped, or no connection to GitHub). A job stays queued until an online, idle runner matches its labels and group, so a stuck queue often means missing labels or offline runners. Learn also suggests checking runners through the REST API and monitoring CPU and memory, for example with Prometheus and Grafana.

To troubleshoot, run the runner's config script with --check, which tests each required GitHub service and writes details to the _diag directory. The same directory holds Runner_ logs for the application (a new file at each start) and Worker_ logs for each job. Check the service with journalctl or svc.sh status on Linux, launchd on macOS, or Get-Service on Windows. Runners update their own software by default (register with --disableupdate to manage updates yourself), and ephemeral runners' logs should be forwarded to external storage.

GitHub Actions metrics cover organizations and repositories. Usage metrics show minutes consumed by workflow, job, repository, runtime OS, and runner type, to spot costly workflows. Performance metrics show average run times, queue times, and failure rates by the same dimensions, to find bottlenecks and compare self-hosted with GitHub-hosted runners. Owners can let others see them with the "View organization Actions metrics" custom role permission.

GitHub Docs describes three levels for Actions secrets. Organization secrets can be shared with all, private, or selected repositories; repository secrets serve one repository; environment secrets serve only jobs that reference that environment and are read when such a job starts, so environment protection rules can gate them. Learn's 2024 unit also lists enterprise-level secrets for GitHub Enterprise Cloud; the current how-to pages don't describe them, so the cards don't rely on them.

When the same name exists at several levels, the lowest level wins: environment over repository over organization. Limits are 1,000 organization, 100 repository, and 100 environment secrets, each up to 48 KB; a workflow can use only the first 100 organization secrets (alphabetically) if more are assigned. Names may contain letters, digits, and underscores, can't start with GITHUB_ or a number, and are case-insensitive.

Some workflows never get secrets: those triggered from forks (only GITHUB_TOKEN is passed), those triggered by Dependabot events, and reusable workflows that weren't explicitly passed them. Secrets can't be used directly in if: conditions. Apply least privilege: scope organization secrets to the repositories that need them, put production credentials in environment secrets, and rotate regularly.

Repository secrets are created under the repository's Settings, Secrets and variables, Actions, by anyone with write access to an organization repository; environment secrets in an organization repository need admin access. Organization secrets are created in the organization's Secrets and variables settings by owners or users with the "Manage organization Actions secrets" permission, with repository access set to all repositories, private repositories, or selected repositories.

GitHub CLI manages all three: gh secret set SECRET_NAME for the current repository, --env ENV_NAME for an environment, and --org ORG_NAME for an organization (private repositories by default, --visibility all or --repos to change it); gh secret list and gh secret delete work the same way. Managing organization secrets needs the admin:org scope.

Workflows read secrets through the secrets context, for example ${{ secrets.API_KEY }}, passed to an action in with or to a script through env. GitHub redacts registered secrets and common token formats in logs, but Learn warns that redaction isn't a security boundary: a compromised runner can still exfiltrate secrets, so never print them and keep GITHUB_TOKEN permissions minimal. Avoid structured data such as JSON as a secret value so redaction works.

Learn shows workflows retrieving secrets from HashiCorp Vault (hashicorp/vault-action), AWS Secrets Manager, and Azure Key Vault. External vaults centralize secret management, automate rotation, add audit logs, and enforce least-privilege access, instead of copying the same credential into many repositories.

OpenID Connect removes the bootstrap secret. You configure the cloud provider or vault to trust GitHub's OIDC provider for specific workflows. Each job can request a signed JWT whose claims (such as sub, built from the repository and environment) identify the workflow, and exchange it for a short-lived access token valid only for that job. The job needs id-token: write in its permissions, which only allows requesting the token; when you set permissions, unlisted scopes become no access except metadata.

For HashiCorp Vault, enable the JWT auth method, configure GitHub's OIDC issuer, and create a role whose bound_claims define at least one condition, such as the repository. In the workflow, grant id-token: write and use hashicorp/vault-action to exchange the token and read the secret path. GitHub recommends environment protection rules when environments are part of the trust policy.

Each audit log entry records the repository, the actor, the action (category.operation, such as repo.create), the country or region, and the time, plus how the actor authenticated outside the web UI. Owners filter with qualifiers such as action, actor, user, org, repo, and created, and export results as CSV or JSON. The REST API (read:audit_log scope, 1,750 queries per hour per user and IP) supports the same searches, for example phrase=repository.deleted. Learn's logging unit lists use cases: tracing unauthorized access, proving compliance, troubleshooting CI/CD failures, and reviewing token and Git activity.

To investigate a credential, search for the events performed by a specific access token; token data appears for personal access tokens, OAuth tokens, GitHub App tokens, and (in public preview) SSH and deploy keys. Source IP addresses are hidden by default; enterprise owners can display them for new and existing events across the enterprise and its organizations, and are responsible for the legal obligations that come with them.

For API usage, organization owners on GitHub Enterprise Cloud have API insights: REST API activity for the organization and for each GitHub App and user, over preset or custom periods, appearing within about six hours. It covers only core REST endpoints on API hostnames, so it can show less than the x-ratelimit headers. Audit log streaming can include API request events for security-relevant endpoints once enabled, which helps detect exfiltration by compromised tokens or apps.

On GitHub Enterprise Server, administrators are responsible for the instance: keeping it upgraded, configuring authentication, networking, and integrations, and fixing on-premises issues. When they need help, GitHub Support can't see the environment, so it asks for data. A diagnostics file is a plain-text overview of the instance's settings and environment (license details, versions and SHAs, VM architecture, hostname, private mode and SSL settings, load and processes, network settings, authentication method, and repository and user counts), downloaded from the Management Console's Support page or produced with ghe-diagnostics. A support bundle adds sanitized logs from two days (or eight, extended).

A Health Check, in public preview for GHES, analyzes a support bundle and reports on general health (upgrade status, storage, license seat use), security (subdomain isolation, user authentication), and Git and API request patterns, such as the busiest repositories and most active API callers. You create the bundle, request the Health Check, and it appears in the Support portal after several hours to a day. Premium Plus customers can ask Support for a GitHub Enterprise Cloud Health Check.

Support's scope matters for monitoring too: it won't audit or explain Copilot consumption or interpret metered billing trends, and it won't investigate security incidents for you. Learn's split is that Support handles accounts, security recovery help, and abuse, while administrators own infrastructure, CI/CD integrations, third-party authentication, scripting, and hardware.

A user is dormant after 30 days without any of the listed activities in the enterprise, such as SAML SSO sign-in, creating repositories or pull requests, commenting on pull requests, labeling or assigning, publishing releases, pushing to a wiki or internal repository over HTTPS, starring, or joining an organization. Token, SSH key, or GitHub App access, Git operations on private repositories, and creating or commenting on issues don't count. Dormancy applies to members and outside collaborators, dormant users still consume licenses, and the enterprise can download a dormant users report.

For Copilot, keep billing and adoption separate. Billing views show assigned seats, license costs, and AI-credit consumption; the Copilot usage metrics dashboard (which needs the Copilot usage metrics policy, with data up to three days behind) shows adoption, feature, model, and language trends; the Copilot impact dashboard groups users into adoption cohorts over a rolling 28-day window, so a billed user can appear passive.

For security, security overview's Coverage view shows which repositories have adopted security features, Enablement shows how fast teams are adopting them, and every GitHub Enterprise organization can run a free secret risk assessment. For automation, Actions usage metrics show minutes by workflow, job, repository, OS, and runner type. Learn's features unit adds organization activity insights and dependency insights for spotting trends and risks.

Metered products include GitHub Actions minutes and storage, Codespaces, Packages, Git LFS, Copilot AI credits, and Advanced Security. Each plan includes some usage; beyond it you pay unless a budget stops usage. The enterprise Billing and licensing Overview page shows current metered usage (broken down by cost center), usage by product, and the top five organizations and repositories by usage, plus prepaid credits and discounts.

The Metered usage view lets you filter, group, and choose a time frame for all metered products; AI credits have a separate AI usage view where enterprise owners and billing managers can filter by user. Get usage report emails a download link that expires after 24 hours, and chart data can be downloaded directly. For Actions you can also see billable job minutes for a single workflow run. Enabling an Advanced Security product can take up to two hours to show in usage data.

Learn's metered usage unit explains how products are counted: Actions by minutes per repository and runner OS (public repositories free), Packages by storage and data transfer, GitHub Enterprise by users with access, and Advanced Security by unique active committers, meaning anyone who pushed to a repository with it enabled in the last 90 days, counted once. Prices and plan allowances change, so read them from the current pricing and included-usage pages rather than memorizing them.

Learn's license units recommend automating usage monitoring with the APIs, reclaiming seats from inactive users, auditing monthly or quarterly, and using SSO and SCIM so people who leave lose access (and stop consuming a license) automatically. Machine accounts consume a license like any user, so audit and restrict them, and find idle self-hosted runners that waste resources. For Copilot, review who needs a seat, since an assigned license is billed whether or not it's used.

Budgets track spending on metered products for the enterprise, organizations, cost centers, users, or repositories and email alerts at chosen percentages. For metered products such as Actions or Copilot AI credits, a budget can stop usage when reached; for license-based products such as Copilot, GitHub Team, or GitHub Enterprise it only alerts, except Advanced Security products, where a hard budget prevents enabling them on more repositories. Budgets aren't available for prepaid volume licenses. You can also opt in to alerts at 90% and 100% of included usage.

Cost centers attribute usage to business units for chargeback and forecasting and can carry their own budgets; enterprise owners and billing managers can create them for any resource, organization owners for their own organization's resources. Adding an enterprise team keeps cost-center membership in step with the team. For Actions, Learn suggests caching dependencies, triggering workflows only when needed, and using self-hosted runners for high volume; Actions usage metrics show which workflows consume the most minutes.

Not in the GH-100 skills measured, but taught in the official Part 2 module *Leverage GitHub Actions to publish to GitHub Packages*. GitHub Packages hosts software packages privately or publicly beside your source code, with registries for npm, RubyGems, Apache Maven, Gradle, Docker, and NuGet, and a Container registry optimized for Docker and OCI images. It works with standard package-manager clients, shows a package's README, versions, and download statistics on GitHub, and integrates with the APIs, webhooks, and GitHub Actions. Unlike a release (notes plus ZIP or tarball downloads tied to a tag), a package is published to a feed that package clients consume.

Permissions depend on the registry. Docker (docker.pkg.github.com), Maven, and Gradle packages are repository-scoped and inherit the repository's permissions and visibility; Maven and Gradle don't support internal visibility. The Container registry, npm, NuGet, and RubyGems support granular permissions: a package can be scoped to a user or organization and its access and visibility set separately from any linked repository. The 2024 Learn unit says all packages inherit repository permissions, which is no longer the whole story.

The Container registry stores images in an organization or personal account rather than a repository, at ghcr.io on GitHub.com (containers.SUBDOMAIN.ghe.com with data residency). An image can be linked to a repository and inherit its permissions or use granular ones, and public images can be pulled anonymously.

Learn's example publishes an npm package whenever a release is created: a build job installs dependencies and runs tests, then a publish job that needs the build job sets registry-url to https://npm.pkg.github.com/ and runs npm publish with NODE_AUTH_TOKEN set to the GITHUB_TOKEN. Container images are built, tagged as ghcr.io/OWNER/IMAGE_NAME, and pushed after logging in to ghcr.io.

In workflows, GITHUB_TOKEN publishes packages associated with the workflow's repository, and GitHub recommends it over personal access tokens for registries with granular permissions. To install a package from another private repository, either grant the workflow's repository read access to the package or use a personal access token (classic) with read:packages. Deleting or restoring packages with GITHUB_TOKEN through the REST API is in public preview.

Outside Actions, a package manager needs your username, a token, and the ecosystem's endpoint, for example https://npm.pkg.github.com or https://nuget.pkg.github.com/OWNER/index.json. GitHub Packages supports only personal access tokens (classic), with packages scopes. Manage packages through the REST and GraphQL APIs, react to new versions with webhooks, and prune old versions with the delete-package-versions action.