About this guide
As an organization owner, preventing exposure of private or sensitive data should be a top priority. Whether intentional or accidental, data leaks can cause substantial risk to the parties involved. While GitHub takes measures to help protect you against data leaks, you are also responsible for administering your organization to harden security.
There are several key components when it comes to defending against data leaks:
- Taking a proactive approach towards prevention
- Early detection of possible leaks
- Maintaining a mitigation plan when an incident occurs
The best approach will depend on the type of organization you're managing. For example, an organization that focuses on open source development might require looser controls than a fully commercial organization, to allow for external collaboration. This article provide high level guidance on the GitHub features and settings to consider, which you should implement according to your needs.
Secure accounts
Protect your organization's repositories and settings by implementing security best practices, including enabling 2FA and requiring it for all members, and establishing strong password guidelines.
- Enabling secure authentication processes by using SAML and SCIM integrations, as well as 2FA authentication whenever possible. For more information, see À propos de la gestion des identités et des accès avec l’authentification unique SAML, À propos de SCIM pour les organisations, and Sécurisation de votre compte avec l’authentification à 2 facteurs.
-
Requiring organization members, outside collaborators, and billing managers to enable 2FA for their personal accounts, making it harder for malicious actors to access an organization's repositories and settings. This is one step further from enabling secure authentication. For more information, see Exiger l’authentification à deux facteurs dans votre organisation.
-
Encouraging your users to create strong passwords and secure them appropriately, by following GitHub’s recommended password guidelines. For more information, see Création d’un mot de passe fort.
-
Encouraging your users to keep push protection for users enabled in their personal account settings, so that no matter which public repository they push to, they are protected. For more information, see Gestion de la protection push pour les utilisateurs.
-
Establishing an internal security policy in GitHub, so users know the appropriate steps to take and who to contact if an incident is suspected. For more information, see Adding a security policy to your repository.
For more detailed information about securing accounts, see Bonnes pratiques pour sécuriser les comptes.
Prevent data leaks
As an organization owner, you should limit and review access as appropriate for the type of your organization. Consider the following settings for tighter control:
| Recommendation | More information |
|---|---|
| Disable the ability to fork repositories. | Gestion de la stratégie de duplication pour votre référentiel |
| Disable changing repository visibility. | Restriction des changements de visibilité des dépôts dans votre organisation |
| Restrict repository creation to private or internal. | Restriction de création de dépôts dans votre organisation |
| Disable repository deletion and transfer. | Définition des autorisations pour la suppression ou le transfert de référentiels |
| Disable the ability to use deploy keys. | Restriction des clés de déploiement dans votre organisation |
| Scope personal access tokens to the minimum permissions necessary. | None |
| Secure your code by converting public repositories to private whenever appropriate. You can alert the repository owners of this change automatically using a GitHub App. | Prevent-Public-Repos in GitHub Marketplace |
| Confirm your organization’s identity by verifying your domain and restricting email notifications to only verified email domains. | Vérification ou approbation d’un domaine pour votre organisation and Limitation des notifications par e-mail de l’organisation |
| Ensure your organization has upgraded to the GitHub Customer Agreement instead of using the Standard Terms of Service. | Mise à niveau vers le contrat client GitHub |
| Prevent contributors from making accidental commits. | Suppression de données sensibles dans un dépôt |
Detect data leaks
No matter how well you tighten your organization to prevent data leaks, some may still occur, and you can respond by using secret scanning, the audit log, and branch protection rules.
Use secret scanning
Secret scanning helps secure code and keep secrets safe across organizations and repositories by scanning and detecting secrets that were accidentally committed over the full Git history of every branch in GitHub repositories. Any strings that match patterns provided by secret scanning partners, by other service providers, or defined by you or your organization, are reported as alerts in the Security and quality tab of repositories.
There are two forms of secret scanning available: Alertes de détection de secrets destinées aux partenaires and Alertes d’analyse de secrets pour les utilisateurs.
-
Alertes de détection de secrets destinées aux partenaires: These are enabled by default and automatically run on all public repositories and public npm packages.
-
Alertes d’analyse de secrets pour les utilisateurs: To get additional scanning capabilities for your organization, you need to enable Alertes d’analyse de secrets pour les utilisateurs.
When enabled, Alertes d’analyse de secrets pour les utilisateurs can be detected on the following types of repository:
- Public repositories owned by organizations that use GitHub Enterprise Cloud
- Private and internal repositories when you have a license for GitHub Code Security
Conseil
Regardless of the enablement status of secret scanning and push protection, organizations on GitHub Team and GitHub Enterprise can run a free report to scan the code in the organization for leaked secrets. See Secret security with GitHub.
For more information about secret scanning, see Secret scanning.
Vous pouvez également activer l’secret scanning en tant que protection des poussées (push) pour un dépôt ou une organisation. Quand vous activez cette fonctionnalité, l’secret scanning empêche les contributeurs de pousser du code comportant un secret détecté. For more information, see Push protection. Finally, you can also extend the detection to include custom secret string structures. For more information, see Defining custom patterns for secret scanning.
Review the audit log for your organization
You can also proactively secure IP and maintain compliance for your organization by leveraging your organization's audit log, along with the GraphQL Audit Log API. For more information, see Examen du journal d’audit de votre organisation and Administration d’entreprise.
Set up branch protection rules
To ensure that all code is properly reviewed prior to being merged into the default branch, you can enable branch protection. By setting branch protection rules, you can enforce certain workflows or requirements before a contributor can push changes. For more information, see À propos des branches protégées.
En guise d’alternative aux règles de protection de branche, vous pouvez créer des ensembles de règles. Les ensembles de règles présentent quelques avantages par rapport aux règles de protection des branches, telles que les états, et une meilleure détectabilité sans nécessiter d’accès administrateur. Vous pouvez également appliquer plusieurs ensembles de règles en même temps. Pour plus d’informations, consultez « À propos des ensembles de règles ».
Mitigate data leaks
If a user pushes sensitive data, ask them to remove it by using the git filter-repo tool. For more information, see Suppression de données sensibles dans un dépôt. Also, if the sensitive data has not been pushed yet, you can just undo those changes locally; for more information, see the GitHub Blog (but note that git revert is not a valid way to undo the addition of sensitive data as it leaves the original sensitive commit in Git history).
If you're unable to coordinate directly with the repository owner to remove data that you're confident you own, you can fill out a DMCA takedown notice form and tell GitHub Support. Make sure to include the problematic commit hashes. For more information, see DMCA takedown notice.
Remarque
If one of your repositories has been taken down due to a false claim, you should fill out a DMCA counter notice form and alert GitHub Support. For more information, see DMCA counter notice.
Revoke exposed tokens
If credentials have been exposed in a GitHub repository, GitHub secret scanning can be used to report and revoke the credentials. For more information, see Résoudre les alertes de l'analyse des secrets.
You can also revoke exposed credentials that you do not own and have been exposed outside of GitHub repositories. By doing this, you are contributing to the overall security of the GitHub community and can quickly limit the impact of these credentials. The API supports revoking:
- Personal access tokens (classic) with the
ghp_prefix - Fine-grained personal access tokens with the
github_pat_prefix - OAuth app tokens with the
gho_prefix - GitHub App user-to-server tokens with the
ghu_prefix - GitHub App refresh tokens with the
ghr_prefix
If you find any exposed tokens either on GitHub or elsewhere, you can submit a revocation request using the REST API. See Révocation for the complete and authoritative list of supported credential types.