Guideline of best practices to follow to configure Github Enterprise Cloud in a secure way.

Report an issue

⚠️ This document is subject to change as the GitHub platform grows with time.

• About the project
• Enterprise account section
  • Managing the subscription
  • Roles for an enterprise account
  • Manage user SAML access to enterprise account
  • Adding organizations to the enterprise account
  • Enforcing repository management policy
  • Enforcing security settings in your enterprise account
• Organization section
  • Profile settings
  • Member privileges
  • Billing manager
  • Organization security
  • Verify domain
  • Audit log
  • Organization webhooks
  • Organization third party access
  • Organization OAuth apps
  • Organization GitHub apps
  • Organization owner
  • Blocked users
  • Terms of service
• User section
  • User creation
  • User security
• Repository section
  • Repository creation
  • Naming convention
  • Tagging convention
  • Repository template
  • Manage access
  • Branch protection
  • Repository webhook
  • Repository notification
  • Repository integration and services
  • Repository deploy key
  • Repository autolink references
  • Repository secrets
  • Security policy and advisories
  • Security alerts
  • Contributing file
  • README file
  • CODEOWNER file
  • GITIGNORE file
  • LICENSE file
  • GitHub Actions
  • GitHub Packages
  • Repository-forking
  • Repository duplicating
  • Open sourcing
  • Agility
• GitHub API section
  • GitHub Rest API
  • GitHub GraphQL API
• Compliancy section
• Support section
• Contributing
• License
• Contact

Looking for a guideline to configure your GitHub Enterprise Cloud in a secure way?

Here is a 🔥 list of things to do!

View the current subscription, license usage, invoices, payment history, and other billing information for your enterprise account.

Enterprise accounts come with a set of administrator roles that you can assign to users of your enterprise. Each administrator role maps to business functions and provides permissions to do specific tasks within the enterprise account.

When you enable SAML single sign-on for your enterprise account, each enterprise member can link their external identity on your identity provider (IdP) to their existing GitHub account. To access each organization's resources on GitHub, the member must have an active SAML session in their browser. To access each organization's protected resources using the API and Git, the member must use a personal access token or SSH key that the member has authorized for use with the organization. Enterprise owners can view and revoke a member's linked identity, active sessions, or authorized credentials at any time.

Enterprise owners can create new organizations within an enterprise account's settings.

To add an organization to your enterprise account, you must create the organization from within the enterprise account settings. You cannot transfer existing organizations into an enterprise account.

Enterprise owners can enforce certain repository management policies for all organizations owned by an enterprise account, or allow policies to be set in each organization. The policies should respect the repository rules in the repository section bellow.

Enforce every enterprise account security recommendations listed here.

This covers many sections such as

1. Requiring two-factor authentication for organizations in your enterprise account
2. Managing allowed IP addresses for organizations in your enterprise account
3. Enabling SAML single sign-on for organizations in your enterprise account
4. Managing team synchronization for organizations in your enterprise account
5. Managing your enterprise account's SSH certificate authorities

More details can be viewed the organization security section

Provide only necessary profile information

Organization display name
Description
URL
Location
Picture

A billing manager for the organization must be defined.

The organization administrator must add the TXT record to our DNS configuration in order to be a Verified Organization Domain in GitHub. This control will also restrict email notifications to an approved domain to prevent information leak

The SOC team must be able to use the GitHub audit log API to do further security analysis and investigation on events from the audit log.

Every webhooks that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Every third-party access that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Every GitHub Oauth apps that the GitHub organization owners wants to add must be reviewed and approved by the security team.

Every GitHub Apps that the GitHub organization owners wants to add must be reviewed and approved by the security team.

GitHub organization owners account can basically do everything, and this is the reason why we must limit to a max of 3-5 users.

This feature must be called from an API if the SOC team detects strange events going on from a users account. We can block a user from within your organization settings or from a specific comment made by the user.

The Standard Terms of Service is an agreement between GitHub and you as an individual. To enter into an agreement with GitHub on behalf of an entity, such as a company, non-profit, or group, organization owners can upgrade to the Corporate Terms of Service.

User creation must be done by using the corporate email.

As listed in this README file, follow all the GitHub Account security best practices.

The repository creation must be initiated from a pull request.

Once the PR is accepted, it will create a new repository respecting all the rules listed in this section.

Repositories must have an effective naming conventions to help scale the organization for long term.

Microservices

<method>-<project-name>-<communication>-service 
ex: get-authentication-rest-service
ex: post-authorization-grpc-service

Libraries

<project-name>-library
ex: validation-library
ex: error-library
ex: jwt-library

GitHub repositories must be tagged with the ApplicationID, Technology used and other usefull informations.

To have a complete repository standardisation, we must use the created GitHub Template Repository

With templates repositories, we can reuse organization based :

• README.md files template
• SECURITY.md files template
• LICENSE.txt files template
• CONTRIBUTING.md files template
• CODEOWNER file template
• GITIGNORE file template
• OPENAPI file template

Also, we can use this feature to create basic reusable codegen templates for :

• Organization base level GitHub Actions
  • Code quality (Codacy, SonarCloud, ...)
  • Dependency checks (Snyk, Dependabot, ...)
  • Secret scanning
  • Docker image security scaning
  • GitHub Package publishing (with versioning)
• Microservices
  • Code template with clean architecture respecting the SOLID principle and 12 Factor Application.
• Libraries

Every Webhooks that the GitHub repository owners wants to add must be reviewed and approved by the security team.

Every Notifications that the GitHub repository owners wants to add must be reviewed and approved by the security team.

⚠️ This section is deprecated, do not use it.

Every Deploy Keys that the GitHub repository owners wants to add must be reviewed and approved by the security team. Deploy keys must respect the least privilege principle to access a repository.

Every Autolink references that the GitHub repository owners wants to add must be reviewed and approved by the security team.

GitHub repositories must not have any clear text secrets in the code, the secrets must be in the GitHub Secrets.

We must call HashiCorp Vault to retrieve secrets. To do so, we must use the GitHub Auth Method. Since GitHub is synched to the companies Identity Provider, it can easily and securely become our source of access to HashiCorp Vault. We must therefore ensure that secure HashiCorp Vault Policies are bulletproof.

Repositories must have a GitHub Security Policy document SECURITY.md to give instructions on how to responsibly report a security vulnerability.

GitHub Security Advisories must be used to privately discuss, fix, and publish information about security vulnerabilities.

We must ensure that GitHub Automated Security Alerts is enabled to have less security issues in our code.

We must have a CONTRIBUTING.md file that describes the steps to follow and respect in order to contribute to a project.

Each repository must have a clear README.md file that describes the goal of the repository and helps developers to set up their working environment quickly.

Each repository must have a CODEOWNER file to request reviews to the code owner on pull request.

Each repository must have a GITIGNORE file to ignore sensible information or garbage data generated by IDEs.

Each repository must have a LICENSE.txt file that is approved by the legal team of the organization. We must have specific licensing rules in repositories (private, public, ...)

GitHub Actions must be reusable and bulletproof. Therefore, they should be reviewed by DevOps, CloudOps and SecOps teams.

Actions must ease automation tasks in testing, deployment, security, notification and many other fields.

The template repository must have the base level GitHub Actions set by the organization at each time.

We must use as much as possible the GitHub Packages as our code and docker image registry to have an all-in-one tool that requires no external connections to other tools such as Nexus or JFrog.

In order to always have deployed artefact and images that are regulary scanned, we must add restriction in Github Actions when pulling a version of Package that is old. Github Packages 📦 older then 3 months must not be consumed for security reasons.

To re-run the GitHub Actions in order to have a new Github Package version simply push a change in the README.md file that doesn’t affect the code and then the base level action will follow all the security checks.

Members will be able to fork public (open source) repositories. When a member decides to fork a repository, he/she must ensure that he/she will merge his/her changes to the open source project. No sensible information must be in the forked code since repositories that are forked are by default public in GitHub.

Members who would like to add sensible data on existing open source projects must duplicate the repository and make it private within the organization instead of forking it.

Yes! 😎

If the code doesn't leak sensible data and is reviewed by the security team, we strongly encourage you to make it open-source by including the licensing and going through the legal approbations of the organization.

We strongly encourage teams to use GitHub to work in an agile way. 👍

• Create Issues
• Create Project Boards
• Assign Reviewers
• Create Milestones
• and more.

GitHub Rest API helps to configure many things in GitHub such as inviting/removing members, creating repositories and more.

GitHub GraphQL API is also available and it offers the ability to define pricisely only the required data you want in a single call. It is also very usefull to audit GitHub logs.

⚠️ Keep note of the rate limiting in place when doing HTTP requests.

No more need to worry about server deployments, updates, availability, hardening or other because with the cloud-hosted GitHub Enterprise Cloud because they handle this part.

• Security trust, audit and compliancy
• Policies
• Incident response
• Security advisory
• Bug bounty program

Github Enterprise Support offers very usefull assistance on everything you search. 👍

• Documentations
• Request creation

Also, GitHub offers a Premium Support with a 24/7 hours of operation availability time.

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

Distributed under the MIT License. See LICENSE.txt for more information.

Deniz Onur Duzgun
Khalid Nazmus Sakib