GitHub Enterprise Cloud attack surface analysis

Pretty simple list that maps every potential abuse point or hardening opportunity in GitHub Enterprise Cloud, complete with direct links to GitHub’s documentation.

Account and profile management

• – Personal end-user accounts (which is associated with one or many email addresses, which can be verified and can be used in a password reset flow)
• Enterprise managed users
• Organization accounts
• Bot accounts (representing an app’s service account identity)

Enterprise management

• Manage policies that apply to one to many Organizations where you can uniformly restrict configurations.
• Policies can affect the enforcement of two-factor authentication, restrict access by IP addresses, set default base permissions for Repositories, harden aspects of the built-in CI system, enforce SSH certificate authorities, restrict access using ungoverned Personal Access Tokens, etc.

Organization management

• Organization management
• Membership management (to an Organization or to a Team)
• Members (normal users)
• Owners (administrators of the organization)
• GitHub App Managers
• Security Managers
• Outside collaborators (see repositories)
• Base permissions for any member of the organization
• Allow to create Public or Private repositories
• Allow fork private repositories
• Allow repository administrators to invite outside collaborators
• Allow to publish Public or Private sites (GitHub Pages)
• Allow outside collaborators to request integration access
• Allow repository administrators to make a private repo, public
• Allow repository administrators to delete or transfer the repo
• Allow members to create teams
• Allow members to publish packages to the repository registry
• Set SSH Certificate Authority
• Authorize and review GitHub App and OAuth Apps
• Review and revoke fined-grained Personal Access Tokens

Authentication

• Authentication (to Web frontend, to native app, using Git command line client)
• Using username and password (GitHub’s password policy is 8 characters — with one digit and one case change — or 15 characters long.)
• Two-factor authentication (2FA)
• TOTP
• Security Keys (WebAuthn / U2F)
• SMS
• Mobile app (GitHub Mobile)
• One-time recovery codes or fallback authentication number
• Using various kinds of tokens (Personal Access Token, OAuth Access Token, Server-to-Server Token for applications like a GitHub App, etc. - We can distinguish between those by looking at their prefix)
• SSH private key for authenticating Git operations (user defined, deploy keys - Can be RSA, ECDSA, or Ed25519)
• SAML or OpenID Connect based SSO support

Authorization

• OAuth App approvals
• OIDC IdP Conditional Access Policy to dynamically allow or deny interactions (including from GitHub App, through SSH, using PATs)

Repositories management

• Administrators can invite repo-level collaborators (which can be restricted at Enterprise level)
• Server-side pre-receive hooks for secret detection

Webhooks

• Webhooks
• Git commit Signature support
• Using GPG private key
• Using SSH private key (Signing key type)
• Using S/MIME with an X.509 key signed by a CA in Debian’s trust store
• Signature by bots (such as GitHub Apps)
• Can enforce vigilant mode (flagging all unsigned commits as unverified)

Branch Protection 

• Branch Protection (only listing aspects that have security implications)
• Require a pull request before merging
• Require a certain number of approvals
• Dismiss stale pull request approvals when new commits are pushed
• Require review from Code Owners
• Restrict who can dismiss pull request reviews
• Allow specified actors to bypass required pull requests
• Require approval of the most recent push
• Require status checks to pass before merging
• Require signed commits
• Require deployments to succeed before merging
• Lock branch (setting the branch read-only)
• Do not allow administrators to bypass branch protection
• Restrict who can push to matching branches
• Allow all users with push access to force push on the protected branch
• Allow all users with push access to delete to protected branch

Tag Protection

• Set rules to protected tags (only allowing repository administrators)

Code Owners (ex. ./github/CODEOWNERS, ./gitlab/CODEOWNERS, etc. )

• Adds extra layer of security to define who should review changes to files and directories in the repository. This can be enforced through Branch Protection.

Audit logging

• Review events on the organization
• Enable disclosure of IP addresses in audit logs