Guideline of best practices to follow to configure Github Enterprise Cloud in a secure way.
Report an issue
- About the project
- Enterprise account section
- Organization section
- User section
- 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
- 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
| Status | Description | |
|---|---|---|
| Base permissions | None | Members will only be able to clone and pull public repositories. To give a member additional access, you’ll need to add them to teams or make them collaborators on individual repositories. |
| Repository creation | Internal | Members will be able to create private repositories, visible to organization members with permission. |
| Repository forking | Unchecked | Refer to the repository forking section. |
| Actions | Enable local Actions for this organization | This allows all repositories to execute any Action, whether the code for the Action exists within the same repository, same organization, or a repository owned by a third party. |
| Repository visibility changes | Unchecked | Only organization owners can change repository visibilities. Or, repository creation and settings must be done as code via a PR |
| Repository deletion and transfer | Unchecked | Only organization owners can delete or transfer repositories. Or, repository creation and settings must be done as code via a PR |
| Issue deletion | Unchecked | Only organization owners can delete issues. Or, repository creation and settings must be done as code via a PR |
| Repository comments | Unchecked | No real need to see comment author’s profile name in issues and pull requests for private repositories. |
| Tream creation | Unchecked | Only organization owners can create new teams. Or, repository creation and settings must be done as code via a PR. |
| Outsider collaborators | Disabled | No outsider collaborators should be able to collaborate in the organization. |
A billing manager for the organization must be defined.
| Status | Description | |
|---|---|---|
| Two factor authentication 🔒 | Enabled | Require two-factor authentication for everyone in the organization. |
| SAML single sign-on 🔒 | Enable | Enable SAML authentication for the organization through an identity provider like Azure AD. SSO authentication to GitHub must be from a known internal identity provider. |
| SSO on access tokens 🔒 | Enable | Enable SSO for the use of access tokens within the organization. |
| SSO on SSH keys 🔒 | Enable | Enable SSO for the use of SSH keys within the organization. |
| SCIM integration 🔒 | Enable | With SCIM, administrators can automate the exchange of user identity information between systems to add, manage and remove organization members. |
| SSH certificate authorities 🔒 | Enable | Manage the organization SSH CA to require the members to have SSH CA certificates to access organization resources. |
| Automated security update 🔒 | Enable (unchecked) | Automatic security checks for dependencies and trigger a pull request in the vulnerable repository with the automated security update feature. |
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.mdfiles templateSECURITY.mdfiles templateLICENSE.txtfiles templateCONTRIBUTING.mdfiles templateCODEOWNERfile templateGITIGNOREfile templateOPENAPIfile 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
| Status | Description | |
|---|---|---|
| With teams | ✔️ | Members are part of teams and every access to repositories must be given with teams. |
| With individual members | ❌ | Individual members must not be able to be added to repositories. They must be a part of a team. |
| With outside collaborators | 👨💻 | For open-source projects only, the community must agree the terms and conditions of the company. |
| Status | Description | |
|---|---|---|
| Branch name | master | The master branch must always be protected. |
| Require pull request before merging | ✔️ | A pull request must absolutely be made before merging to master. No direct push to master must be allowed. |
| Require 2 approving reviews | ✔️ | Minimum 2 approved reviews should be passed and for major changes with security modification, a security advisor must be assigned in the pull request. |
| Require review from Code Owner | ✔️ | When possible, the code owner must review the pull requests. |
| Require status check to pass before merging | ✔️ | The new feature branch must pass all the required checks in order to be merged to master. Otherwise the merge would be impossible in order to protect the master branch. |
| Require the branch to be up to date before merging | ✔️ | The branches must be up to date before merging to avoid git conflicts. |
| Required signed commits | ✔️ | Only Signed Commits must be allowed. Here is a How-to. |
| Include restrictions to administrators | ✔️ | Administrators must not be able to bypass the branch security settings; they need to do pull requests also. |
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.
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. 👍
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.
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. 👍
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.
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the MIT License. See LICENSE.txt for more information.