10 bonnes pratiques pour sécuriser GitHub

Dans notre univers numérique en constante évolution, dominé par le code, la protection de votre base de code est essentielle. GitHub est la plateforme de référence pour le partage de code et le contrôle de version au sein de la communauté des développeurs. Toutefois, malgré son adoption généralisée, GitHub n’échappe pas aux nombreux défis de sécurité auxquels les développeurs sont confrontés au quotidien. Des accès non autorisés aux risques de fuite de données sensibles, il est essentiel que les développeurs appliquent les bonnes pratiques de sécurité GitHub pour renforcer leur code et leurs processus de développement.

Dans cette fiche pratique, nous présentons dix bonnes pratiques pour renforcer la sécurité de votre compte GitHub. Téléchargez cette fiche synthétique et poursuivez votre lecture pour découvrir une explication détaillée de ces dix actions.

Activer et imposer l’authentification à deux facteurs sur GitHub

L’authentification à deux facteurs, souvent abrégée en 2FA, est un protocole de sécurité qui demande aux utilisateurs de fournir deux facteurs d’authentification différents pour vérifier leur identité. Il s’agit généralement d’une information que vous connaissez (comme un mot de passe) et d’un élément que vous possédez (comme un téléphone). Cette approche à plusieurs niveaux complique considérablement l’accès à vos données pour toute personne non autorisée : c’est un outil essentiel pour la sécurité des applications et du code.

GitHub regorge de propriété intellectuelle et de code sensible. En tant que développeurs et professionnels DevOps, nous devons accorder la plus grande importance à la sécurité de nos dépôts de code et à l’intégrité des projets open source auxquels nous contribuons. La 2FA ajoute une couche de sécurité supplémentaire et complique l’accès non autorisé pour les attaquants potentiels, même s’ils parviennent à obtenir votre mot de passe.

Pour activer la 2FA sur GitHub, suivez ces étapes simples :

1. Connectez-vous à votre compte GitHub.

2. Cliquez sur votre photo de profil en haut à droite, puis sur Settings.

3. Dans la barre latérale, cliquez sur Security.

4. Cliquez sur le bouton Enable two-factor authentication.

5. Choisissez si vous souhaitez utiliser une application d’authentification ou recevoir des SMS pour la 2FA, puis suivez les instructions de configuration.

6. Enfin, des codes de récupération vous seront fournis. Ils sont importants si vous perdez l’accès à votre méthode de 2FA : veillez donc à les conserver dans un endroit sûr.

Rendre obligatoire l’authentification à deux facteurs (2FA) pour les dépôts GitHub de votre organisation est une étape essentielle pour renforcer la sécurité. En imposant la 2FA, vous exigez de chaque membre de l’équipe qui accède au dépôt une vérification supplémentaire, comme un code temporaire généré par une application d’authentification ou reçu par SMS. Cette mesure de sécurité réduit considérablement le risque d’accès non autorisé, notamment en cas de compromission de mots de passe. L’obligation d’utiliser la 2FA protège votre base de code et témoigne de votre engagement proactif en faveur d’un environnement de développement sûr, conformément aux bonnes pratiques de contrôle d’accès.

Limiter l’accès aux dépôts

Dans le domaine de la sécurité des applications et du code, limiter l’accès à vos dépôts GitHub est essentiel. C’est un moyen efficace de gérer les personnes autorisées à consulter, modifier ou administrer votre code source. Cette pratique contribue à préserver l’intégrité du code et à le protéger des menaces potentielles. 

Le principe du moindre privilège (PoLP) est un concept de sécurité informatique selon lequel un utilisateur ne reçoit que le niveau d’accès minimum nécessaire pour accomplir ses tâches. Ce principe doit également s’appliquer à vos dépôts GitHub.

Appliquer le PoLP à vos dépôts contribue à limiter les risques liés aux situations suivantes :

• Exposition accidentelle de données sensibles : limiter les accès réduit le risque que des données sensibles soient accidentellement envoyées vers un dépôt, puisque moins de personnes disposent d’un accès en écriture.

• Attaques malveillantes : en limitant l’accès à votre base de code, vous réduisez le nombre de points d’entrée potentiels pour les attaquants.

• Modifications involontaires : moins de personnes disposant d’un accès en écriture ou d’administration signifie moins de risques de modifications accidentelles du code susceptibles de provoquer des bogues ou de faire échouer les builds.

GitHub propose plusieurs niveaux d’accès aux dépôts : Read, Triage, Write, Maintain et Admin. Chacun de ces niveaux offre des capacités différentes. Par exemple, une personne disposant des autorisations Read peut uniquement consulter et dupliquer le dépôt, tandis qu’une personne disposant des autorisations Admin peut gérer ses paramètres, ses équipes et ses intégrations.

N’oubliez pas d’accorder uniquement le niveau d’accès minimal nécessaire à chaque collaborateur pour remplir son rôle. Vous pourrez toujours l’augmenter par la suite si besoin.

Éviter de stocker des identifiants dans le code ou la configuration sur GitHub

Stocker des identifiants directement dans des dépôts GitHub présente un risque de sécurité important, car des informations sensibles peuvent être exposées à des personnes non autorisées. Pour réduire ce risque, les développeurs doivent recourir à des solutions sécurisées pour stocker ces informations, par exemple des variables d’environnement ou des fichiers de configuration situés en dehors du dépôt géré par le contrôle de version. En utilisant ces variables ou fichiers externes dans le code plutôt qu’en y intégrant les identifiants en dur, les développeurs séparent clairement les données sensibles de la base de code accessible au public et réduisent le risque d’exposition accidentelle.

Pendant le développement, Snyk Code peut vous aider à repérer les identifiants et secrets intégrés en dur dans le code. Le plugin IDE de Snyk Code est un excellent outil pour détecter les problèmes de sécurité potentiels avant la validation du code.

Par ailleurs, des outils spécialisés comme GitLeaks et Git-secrets sont essentiels pour renforcer la sécurité. GitLeaks analyse les dépôts à la recherche de secrets et de clés d’API, et vous alerte immédiatement lorsqu’il détecte des informations susceptibles de compromettre votre sécurité. L’intégration de GitLeaks aux pipelines CI/CD ou aux hooks de pré-commit permet de remédier rapidement aux problèmes. Git-secrets, un autre outil précieux, prévient l’ajout accidentel de secrets en analysant les commits, les branches et les fichiers indexés à la recherche de motifs prédéfinis de données sensibles. Configuré pour refuser les commits contenant ces motifs, Git-secrets constitue une défense robuste contre les fuites accidentelles et renforce la sécurité des dépôts Git et GitHub.

L’intégration de ces outils à votre processus de développement améliore la détection proactive et l’atténuation des risques de sécurité liés au stockage d’identifiants dans les dépôts Git et GitHub. Grâce à des analyses régulières et à des contrôles automatisés, les équipes peuvent réduire considérablement le risque d’exposition d’informations sensibles et mieux protéger leur base de code contre les menaces potentielles.

Si un secret est détecté, évaluez rapidement la situation et repérez les zones concernées dans le dépôt. Supprimez ou remplacez les identifiants compromis, renouvelez les clés ou mots de passe associés et informez les membres de l’équipe de l’incident. Vous pouvez également supprimer les données sensibles en réécrivant l’historique Git avec un outil comme BFG Repo-Cleaner, si leur invalidation ou leur remplacement ne suffit pas. Gardez à l’esprit que cet historique peut avoir été copié sur des machines locales ou dans des forks de votre dépôt.

Connecter vos dépôts à Snyk et rechercher les vulnérabilités

L’une des meilleures pratiques en matière de sécurité des applications et du code consiste à connecter vos dépôts GitHub à Snyk, un outil de référence pour la sécurité des développeurs. Cette intégration vous permet d’analyser automatiquement les vulnérabilités dans votre base de code, vos images de conteneurs, vos dépendances open source et vos configurations d’infrastructure as code.

Connecter votre dépôt GitHub à votre compte Snyk est très simple. Connectez-vous d’abord à votre compte Snyk et accédez à la page Integrations. Cliquez sur l’intégration GitHub, puis suivez les étapes pour autoriser Snyk à accéder à vos dépôts GitHub.

Dès l’installation, Snyk propose quatre types d’analyses pour vos dépôts GitHub :

1. Snyk Open Source : cette analyse recherche les vulnérabilités connues dans vos dépendances open source. C’est un outil essentiel pour la sécurité de l’open source, car il vous aide à détecter et à corriger les problèmes dans vos packages tiers. Snyk peut également vérifier les licences des dépendances utilisées afin de vous aider à prendre les bonnes décisions en matière de conformité des licences.

2. Snyk Code : cette analyse recherche les vulnérabilités de sécurité et les problèmes de qualité dans votre base de code. Elle contribue à la sécurité des applications en repérant les failles potentielles dans votre code. 

3. Snyk Container : cette analyse recherche les vulnérabilités dans vos images de conteneurs Docker. Elle est essentielle à la sécurité des conteneurs, car elle vous aide à vous assurer que vos images Docker peuvent être déployées en toute sécurité.

4. Snyk IaC : cette analyse examine vos configurations d’infrastructure as code. Elle assure une surveillance continue et une remédiation pour détecter et corriger les vulnérabilités des configurations d’infrastructure cloud, notamment Kubernetes, Terraform et CloudFormation. 

Analyser les pull requests entrantes

En plus de connecter vos dépôts GitHub à Snyk pour effectuer des analyses complètes des vulnérabilités, il est essentiel de tirer parti de la capacité de la plateforme à analyser en temps réel les nouvelles pull requests (PR). La fonctionnalité d’analyse des pull requests de Snyk vous permet de détecter et de corriger de manière proactive les vulnérabilités introduites pendant le développement. Lorsque les développeurs proposent des modifications dans leurs PR, Snyk analyse automatiquement la base de code modifiée, les dépendances open source et les images de conteneurs, et signale les vulnérabilités potentielles avant la fusion du code dans la branche par défaut.

Cette approche proactive permet aux équipes de développement de corriger les problèmes de sécurité dès les premières étapes du cycle de développement et réduit le risque d’introduire des vulnérabilités dans l’environnement de production.

En intégrant Snyk à votre workflow GitHub de manière transparente, vous renforcez la sécurité de votre base de code et favorisez une culture DevSecOps qui donne la priorité à la sécurité continue tout au long du processus de développement logiciel. Connecter vos dépôts à Snyk et activer l’analyse des pull requests ajoute une couche de protection supplémentaire et garantit que seul du code sécurisé est fusionné dans votre branche par défaut.

Ajouter un fichier SECURITY.md

En complément du fichier README.md indispensable, l’ajout d’un fichier SECURITY.md est une étape essentielle pour renforcer la posture de sécurité de votre projet. Ce fichier dédié centralise les informations de sécurité importantes, assure la transparence et fournit des directives claires aux contributeurs et aux parties prenantes.

Politique de divulgation

Définissez une procédure claire pour les personnes qui découvrent des problèmes de sécurité et désignez un point de contact, généralement une adresse e-mail commençant par « security@ ». Cette politique encourage la divulgation responsable et permet aux personnes externes de signaler les problèmes de sécurité de manière sûre, tout en favorisant une approche collaborative de la gestion des vulnérabilités.

Politique de mise à jour de sécurité

Précisez comment le projet prévoit de communiquer les informations sur les nouvelles vulnérabilités détectées. Indiquez les canaux par lesquels les utilisateurs recevront les notifications et les mesures qu’ils devront prendre pour corriger rapidement ces problèmes. Une politique de mise à jour bien définie permet aux utilisateurs de rester informés et de prendre les mesures nécessaires pour sécuriser leurs déploiements.

Configuration liée à la sécurité

Mettez en évidence les paramètres dont les utilisateurs devraient tenir compte pour renforcer la posture de sécurité lors du déploiement du projet. Cette section sert de guide pratique pour configurer les mesures de sécurité et aide les utilisateurs à comprendre les choix qui s’offrent à eux pour améliorer la sécurité globale de leurs déploiements.

Failles de sécurité connues et améliorations à venir

Communiquez en toute transparence sur les failles de sécurité existantes qui ont été identifiées, mais pas encore corrigées. Présentez également les améliorations de sécurité envisagées, mais pas encore mises en œuvre. Cette démarche instaure une culture de transparence et de collaboration, et encourage les contributeurs à participer activement à l’amélioration de la sécurité du projet.

Le fichier SECURITY.md joue un rôle essentiel dans la création d’un environnement sécurisé et ouvert pour votre projet. Il pose les bases de pratiques de sécurité responsables et constitue une ressource précieuse pour les contributeurs et les utilisateurs, contribuant ainsi à un écosystème de projets plus résilient et plus sûr.

Utilisez des règles de protection des branches

Les règles de protection des branches constituent une couche de sécurité essentielle dans un workflow DevSecOps. Elles empêchent les modifications non autorisées ou accidentelles des parties sensibles de votre base de code. Dans cette section, nous verrons ce que sont ces règles et comment les configurer dans GitHub pour renforcer la sécurité de votre base de code.

Dans GitHub, les règles de protection des branches sont un ensemble de contrôles que les administrateurs de dépôts peuvent configurer pour garantir la qualité du code et gérer la collaboration. Elles vous permettent de définir et d’imposer précisément la façon dont les modifications de code doivent être fusionnées dans une branche. C’est un aspect essentiel de la sécurité des applications et du code, car ces règles appliquent le principe du moindre privilège et veillent à ce que seuls les utilisateurs autorisés puissent modifier la base de code.

Voici quelques contrôles que vous pouvez appliquer avec les règles de protection des branches :

• Exiger la validation des pull requests avant leur fusion : ainsi, au moins une autre personne doit examiner et approuver les modifications avant qu’elles puissent être fusionnées dans une branche protégée.

• Exiger la réussite des vérifications d’état avant la fusion : cette option permet de s’assurer que tous les tests CI requis réussissent avant la fusion du code.

• Limiter les personnes autorisées à envoyer des modifications vers les branches correspondantes : vous pouvez ainsi préciser quels utilisateurs ou équipes sont autorisés à envoyer des modifications vers une branche protégée et 

• Imposer un historique de commits linéaire : l’historique des commits reste ainsi clair et facile à comprendre.

Configurer des règles de protection des branches

Pour configurer des règles de protection des branches dans GitHub, suivez les étapes ci-dessous :

1. Accédez à votre dépôt GitHub, puis ouvrez l’onglet Settings.

2. Dans la barre latérale gauche, cliquez sur Branches.

3. Sous Branch protection rules, cliquez sur Add rule.

4. Dans le champ Branch name pattern, saisissez le nom de la branche à protéger.

5. Sous Protect matching branches, sélectionnez les exigences à appliquer. Vous pouvez choisir parmi les options mentionnées ci-dessus.

6. Cliquez sur Create pour enregistrer votre nouvelle règle de protection des branches.

Une utilisation efficace des règles de protection des branches peut considérablement renforcer la sécurité et la fiabilité de votre base de code. Pour des raisons de sécurité, la plupart des dépôts utilisés au sein de Snyk ne permettent pas d’envoyer directement des modifications vers la branche principale : vous devez passer par une PR. Cette restriction est appliquée au moyen de règles de protection des branches.

Renouvelez vos jetons SSH et vos clés personnelles

Renouveler régulièrement vos jetons SSH et vos clés personnelles est essentiel pour renforcer la sécurité du code dans vos dépôts GitHub. Cette section vous explique comment procéder et pourquoi c’est important pour la sécurité des applications, la sécurité des conteneurs et le DevSecOps.

Le renouvellement des jetons SSH et des clés personnelles est une mesure de sécurité proactive qui contribue à empêcher tout accès non autorisé à vos dépôts GitHub. Si un acteur malveillant parvient à obtenir votre jeton SSH ou vos clés personnelles, il peut causer de graves dégâts dans votre base de code. Renouveler régulièrement ces identifiants complique la tâche des attaquants qui tentent de conserver l’accès à vos dépôts, et renforce ainsi la sécurité de vos projets open source.

Comment renouveler les jetons SSH et les clés personnelles

GitHub vous permet de renouveler facilement vos jetons SSH et vos clés personnelles. Voici la marche à suivre :

1. Connectez-vous à votre compte GitHub.

2. Accédez à Settings, puis à Developer settings et à Personal access tokens.

3. Cliquez sur Generate new token.

4. Donnez une description à votre jeton et sélectionnez les champs d’application (ou autorisations) que vous souhaitez lui accorder.

5. Cliquez sur Generate token.

Après avoir généré un nouveau jeton, veillez à remplacer l’ancien partout où il est utilisé.

Automatiser le renouvellement des jetons et des clés

Pour les équipes qui gèrent de nombreux dépôts ou de grands environnements DevOps, renouveler manuellement les jetons SSH et les clés peut vite devenir une tâche fastidieuse. Automatiser le processus garantit sa cohérence et permet de gagner du temps. Vous pouvez utiliser GitHub Actions ou vos outils de pipeline CI/CD, comme Jenkins, pour automatiser le renouvellement.

En conclusion, le renouvellement des jetons SSH et des clés personnelles est une pratique essentielle pour préserver la sécurité de vos dépôts GitHub. L’objectif n’est pas de vous compliquer la vie, mais de protéger votre code contre tout accès non autorisé.

Mettez automatiquement à jour vos dépendances

Maintenir une base de code à jour et sécurisée est essentiel pour la sécurité des applications, du code et des conteneurs, ainsi que pour le DevSecOps. La mise à jour régulière des dépendances en est un élément clé. Des vulnérabilités sont souvent découvertes dans les bibliothèques tierces obsolètes. Il est donc important de disposer d’une stratégie de mise à jour automatique des dépendances afin de réduire les risques d’incident de sécurité. Dans cette section, nous examinerons l’importance de la mise à jour des bibliothèques tierces et la façon d’automatiser ce processus à l’aide d’outils comme Snyk.

Les bibliothèques tierces font partie intégrante du développement logiciel : elles évitent aux développeurs de réinventer la roue en réutilisant du code écrit par d’autres. Cependant, si elles ne sont pas correctement gérées, elles peuvent devenir le maillon faible de votre chaîne de sécurité. Elles peuvent devenir obsolètes et présenter de sérieux risques si elles contiennent des vulnérabilités qui n’ont pas été corrigées dans les versions les plus récentes.

La mise à jour manuelle des dépendances peut être fastidieuse et prendre beaucoup de temps, en particulier pour les projets de grande envergure. C’est là que l’automatisation entre en jeu.

Automatisez la mise à jour des dépendances avec Snyk

Snyk est un outil puissant qui vous aide à détecter et à corriger les vulnérabilités dans vos dépendances. En plus de ses capacités d’analyse des vulnérabilités, Snyk peut également automatiser la mise à jour de vos dépendances.

Une fois intégré à GitHub, Snyk analyse vos dépôts pour détecter les dépendances obsolètes et les versions vulnérables des bibliothèques. Il ouvre ensuite des pull requests (PR) dans GitHub pour mettre à jour ces dépendances, afin que vous puissiez examiner et fusionner les modifications facilement.

Après avoir connecté GitHub à votre compte Snyk, vérifiez que l’option Automatic dependency upgrade pull requests est activée dans Integration Settings au niveau de l’organisation ou dans les paramètres du projet.

Snyk surveillera alors vos dépôts et créera des PR pour les dépendances obsolètes, afin de vous aider à maintenir votre base de code à jour et sécurisée.

En conclusion, automatiser la mise à jour des dépendances est une bonne pratique que tous les développeurs et professionnels DevOps devraient adopter. Cela renforce la sécurité de vos applications et vous fait gagner du temps et des efforts sur le long terme. En tirant parti d’outils comme Snyk, vous pouvez anticiper les vulnérabilités des bibliothèques tierces et préserver une base de code saine et sécurisée.

Utilisez des dépôts privés pour les données sensibles

Il est essentiel de savoir gérer les données sensibles sur des plateformes comme GitHub. L’un des moyens les plus simples de les protéger consiste à utiliser des dépôts privés. Dans cette section, nous verrons la différence entre les dépôts publics et privés, ainsi que les situations où il est préférable d’opter pour un dépôt privé.

GitHub propose deux types de dépôts : publics et privés.

1. Dépôts publics : comme leur nom l’indique, ces dépôts sont visibles de tous. Tout utilisateur GitHub peut consulter, cloner et créer une bifurcation d’un dépôt public. Cependant, seuls les collaborateurs du dépôt peuvent y envoyer des modifications. Cette ouverture favorise la collaboration et le développement open source.

2. Dépôts privés : ils sont uniquement visibles par leur propriétaire et les collaborateurs qu’il a explicitement ajoutés. Même si une personne dispose de l’URL d’un dépôt privé, elle ne pourra pas en consulter le contenu sans les autorisations nécessaires.

Quand utiliser des dépôts privés

Les dépôts publics sont adaptés aux projets open source et au développement collaboratif, mais ne conviennent pas aux données sensibles. Voici les situations où il est préférable d’utiliser un dépôt privé :

1. Protéger les données sensibles : si votre base de code contient des données sensibles, comme des clés API, des mots de passe ou des informations confidentielles, stockez-la dans un dépôt privé. Seuls les collaborateurs autorisés pourront ainsi accéder à ces données.

2. Code propriétaire : si votre base de code est propriétaire et ne doit pas être accessible au public, optez pour un dépôt privé. C’est souvent le cas des applications métier et des logiciels payants.

3. Phase de développement : si votre projet en est à ses débuts et n’est pas prêt à être rendu public, mieux vaut le conserver dans un dépôt privé. Vous pourrez ainsi contrôler les personnes qui y ont accès pendant son développement.

Désactivez la création de dépôts publics

Pour renforcer la sécurité et protéger les informations sensibles, les organisations qui n’ont pas besoin de dépôts publics devraient envisager de désactiver entièrement l’accès public. Cette mesure proactive contribue à éviter la création accidentelle de dépôts accessibles au public et réduit les risques d’exposition des données. En imposant des paramètres de dépôt privé via le chemin de navigation Your Organizations, Settings, puis Member Privileges, les organisations veillent à ce que seuls les utilisateurs autorisés puissent accéder aux dépôts. Cette approche respecte les bonnes pratiques de protection des données et simplifie la gestion des dépôts, pour un environnement plus sûr et mieux contrôlé pour le code de l’organisation.

En conclusion, l’utilisation de dépôts privés pour les données sensibles est une bonne pratique essentielle pour la sécurité sur GitHub. Elle contribue à protéger vos données sensibles et votre code propriétaire, et renforce ainsi la sécurité de votre code et vos pratiques DevSecOps. 

Choisissez vos applications GitHub avec discernement

Pour les applications GitHub, il est essentiel de faire des choix réfléchis. Développées par différentes entités, elles offrent de nombreuses fonctionnalités. Avant de vous lancer, voici quelques points importants à prendre en compte :

• Vérifiez les autorisations : ne cédez pas à la tentation d’accorder des autorisations à tout-va. N’accordez que celles qui sont absolument nécessaires. En limitant les accès, vous réduisez les risques inutiles.

• Interrogez-vous sur les accès : lorsqu’une application demande des accès étendus, vérifiez soigneusement qu’ils sont nécessaires. Évaluez les conséquences possibles en cas de problème. Il s’agit de mesurer les risques.

• Identifiez qui est à l’origine de l’application : avant d’intégrer une application à votre environnement de développement, vérifiez soigneusement la légitimité de ses créateurs. Faites comme si vous recrutiez un nouveau membre de l’équipe : la confiance est primordiale.

• Vérifiez la sécurité : considérez la sécurité d’une application comme la première ligne de défense de votre code. La moindre faille peut rendre votre code vulnérable. Examinez les protocoles de sécurité pour vous assurer qu’ils offrent une protection solide.

• Faites régulièrement le point : un entretien régulier est indispensable. Évaluez périodiquement si vos applications sont toujours nécessaires et dignes de confiance. Veillez ainsi à garder votre environnement de développement bien organisé.

N’oubliez pas que la sécurité de votre code est une affaire sérieuse. Restez vigilant, faites des choix avisés et préservez la stabilité et la sécurité de votre application.

Conclusion

En conclusion, nous avons vu le rôle essentiel que joue GitHub dans le développement logiciel moderne et l’importance d’adopter des bonnes pratiques de sécurité rigoureuses. Les dix recommandations abordées constituent une base solide pour sécuriser vos dépôts et projets GitHub. Chacune d’elles complète les autres pour créer une défense robuste contre de nombreuses menaces et vulnérabilités. 

À tous les développeurs et professionnels DevOps : nous vous encourageons à prendre ces bonnes pratiques de sécurité à cœur. La sécurité n’est pas la responsabilité d’une seule équipe ou d’une seule personne, mais un engagement collectif qui concerne chaque aspect du développement et de l’exploitation des logiciels. 

Comme nous le disons souvent en DevSecOps : « La sécurité est la responsabilité de tous. » Faisons chacun notre part pour garantir la meilleure protection possible de nos applications, de nos données et de nos utilisateurs. 

Dans une démarche d’apprentissage continu, restez toujours ouvert aux nouvelles pratiques, aux nouveaux outils et aux nouveaux processus susceptibles de renforcer la sécurité de votre environnement GitHub.

Bon codage et restez en sécurité !