Comment gérer un dépôt GitHub sécurisé

Ici, nous abordons quelques-uns des outils et techniques de sécurité essentiels disponibles pour les administrateurs de référentiel GitHub.

L’importance d’une stratégie de développement sécurisée

La sécurité des applications est importante. Les services d’actualités portent fréquemment des histoires sur certaines violations des systèmes d’une entreprise et des données privées et des données client qui ont été volées.

Alors, quels sont les problèmes à prendre en compte lors de la planification d’une stratégie de développement sécurisée ? Il est clair que nous devons protéger les renseignements contre la divulgation d’informations aux personnes qui ne devraient pas y avoir accès, mais plus important encore, nous devons veiller à ce que ces informations soient modifiées ou détruites uniquement lorsqu’elles sont appropriées.

Nous devons nous assurer que nous authentifient correctement les personnes qui accèdent aux données et qu’elles disposent des autorisations appropriées pour ce faire. Par le biais de données ou d’archives historiques ou de journaux, nous devons être en mesure de trouver des preuves quand quelque chose est incorrect.

Il existe de nombreux aspects pour créer et déployer des applications sécurisées. Voici trois éléments à prendre en compte :

• Il existe un problème de connaissance générale : de nombreux développeurs et autres membres du personnel supposent qu’ils comprennent la sécurité, mais ils ne le font pas. La cybersécurité est une discipline en constante évolution. Un programme d’éducation et de formation continue est essentiel.

• Le code doit être créé correctement et en toute sécurité : nous devons nous assurer que le code est créé correctement et implémente en toute sécurité les fonctionnalités requises. Nous devons également nous assurer que les fonctionnalités ont été conçues avec une sécurité à l’esprit.

• Les applications doivent se conformer aux règles et réglementations : nous devons nous assurer que le code est conforme aux règles et réglementations requises. Nous devons tester la conformité lors de la génération du code, puis retester régulièrement, même après le déploiement.

Sécurité à chaque étape

La sécurité n’est pas quelque chose que vous pouvez simplement ajouter ultérieurement à une application ou à un système. Le développement sécurisé doit faire partie de chaque étape du cycle de vie du développement logiciel. Ce concept est encore plus important pour les applications critiques et les applications qui traitent des informations sensibles ou hautement confidentielles.

En pratique, pour tenir les équipes responsables de ce qu’elles développent, les processus doivent se déplacer vers la gauche ou être terminés plus tôt dans le cycle de vie du développement. En déplaçant les étapes d’une porte finale au moment du déploiement vers une étape antérieure, moins d’erreurs sont effectuées et les développeurs peuvent passer plus rapidement.

Les concepts de sécurité des applications n’étaient pas axés sur les développeurs dans le passé. Outre les problèmes d’éducation et de formation, c’est parce que leurs organisations ont mis l’accent sur le développement rapide des fonctionnalités.

Toutefois, avec l’introduction des pratiques DevOps, les tests de sécurité sont plus faciles à intégrer dans le pipeline. Au lieu d’être une tâche effectuée par des spécialistes de la sécurité, les tests de sécurité doivent simplement faire partie des processus de livraison quotidiens.

Dans l’ensemble, lorsque le temps de remaniement est pris en compte, l’ajout de la sécurité à vos pratiques DevOps plus tôt dans le cycle de vie du développement permet aux équipes de développement de détecter les problèmes plus tôt. La prise de problèmes plus tôt peut réduire le temps global nécessaire pour développer des logiciels de qualité.

Le déplacement vers la gauche est un changement de processus, mais il ne s’agit pas d’un seul contrôle ou d’un outil spécifique. Il s’agit de rendre toute votre sécurité plus centrée sur les développeurs et de donner aux développeurs des commentaires sur la sécurité où ils sont.

Fonctionnalités de l’onglet Sécurité

GitHub offre des fonctionnalités de sécurité qui aident à sécuriser les données dans les référentiels et dans les organisations. Pour localiser l’onglet sécurité :

1. Sur GitHub.com, accédez à la page principale du référentiel.

2. Sous le nom du référentiel, sélectionnez Sécurité.

Sous l’onglet Sécurité, vous pouvez ajouter des fonctionnalités à votre workflow GitHub pour éviter les vulnérabilités dans votre référentiel et votre codebase. Ces fonctionnalités sont les suivantes :

• Stratégies de sécurité qui vous permettent de spécifier comment signaler une vulnérabilité de sécurité dans votre projet en ajoutant un SECURITY.md fichier à votre référentiel.
• Alertes Dependabot qui vous avertissent lorsque GitHub détecte que votre dépôt utilise une dépendance ou un programme malveillant vulnérable.
• Conseils de sécurité que vous pouvez utiliser pour discuter en privé, corriger et publier des informations sur les vulnérabilités de sécurité dans votre référentiel.
• Analyse du code qui vous aide à rechercher, trier et corriger les vulnérabilités et les erreurs dans votre code.
• Analyse des secrets qui détecte les jetons, les informations d’identification et les secrets validés dans votre dépôt et peut les bloquer avant l’envoi push. La protection Push est activée par défaut sur les référentiels publics.

Pour plus d’informations, consultez les fonctionnalités de sécurité GitHub.

Ensuite, nous explorons certaines de ces fonctionnalités et apprenons à distribuer des responsabilités de sécurité et opérationnelles dans toutes les phases du cycle de vie du développement logiciel.

Communiquer une stratégie de sécurité avec SECURITY.md

Les avantages de la communauté gitHub sont importants, mais ils présentent également des risques potentiels. Le fait que tout le monde puisse proposer des correctifs de bogues publiquement vient avec certaines responsabilités. Le plus important est la divulgation responsable des informations susceptibles d’entraîner des attaques de sécurité avant que leurs bogues sous-jacents puissent être résolus. Les développeurs qui cherchent à signaler ou à résoudre les problèmes de sécurité recherchent un SECURITY.md fichier à la racine d’un dépôt afin de divulguer de manière responsable leurs préoccupations. Fournir des conseils dans ce fichier accélère finalement la résolution de ces problèmes critiques.

Pour en savoir plus sur SECURITY.md, consultez Ajout d’une stratégie de sécurité à votre référentiel.

Avis de sécurité GitHub

Les conseils de sécurité GitHub permettent aux gestionnaires de maintenance de référentiels de discuter et de corriger en privé une vulnérabilité de sécurité dans un projet. Une fois que les maintenances de référentiel collaborent sur un correctif, elles peuvent publier l’avis de sécurité pour divulguer publiquement la vulnérabilité de sécurité à la communauté du projet. En publiant des avis de sécurité, les responsables de référentiel facilitent la mise à jour des dépendances de package et recherchent les conséquences des vulnérabilités de sécurité. GitHub stocke les avis publiés dans la liste Common Vulnerabilities and Exposures (CVE). Cette liste est utilisée pour notifier automatiquement les dépôts affectés qui utilisent des logiciels qui ont une vulnérabilité répertoriée. Pour plus d’informations, consultez À propos des avis de sécurité des référentiels.

Conserver les fichiers sensibles hors de votre dépôt avec .gitignore

Il est facile pour les développeurs d’ignorer les fichiers inclus dans une validation. Parfois, ces fichiers négligés sont bénins, tels que les fichiers de build intermédiaires. Toutefois, il existe toujours le risque qu’une personne puisse commettre par inadvertance des données sensibles. Par exemple, quelqu’un peut valider une clé API ou des données de configuration privée qu’un acteur malveillant peut utiliser. Une technique permettant d’éviter ce risque consiste à créer et à gérer des .gitignore fichiers. Ces fichiers indiquent aux outils clients, tels que l’utilitaire de ligne de commande git, d’ignorer les chemins d’accès et les motifs lors de l’agrégation des fichiers pour un commit.

L’exemple suivant illustre certains des cas d’usage courants pour ignorer les fichiers :

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Votre référentiel peut inclure plusieurs .gitignore fichiers. Les paramètres sont hérités des répertoires parents, avec des champs de remplacement dans de nouveaux fichiers .gitignore qui prévalent sur les paramètres parents pour leurs dossiers et sous-dossiers. Il est important de maintenir le fichier racine .gitignore , bien que l’ajout d’un .gitignore fichier dans un répertoire de projet puisse être utile lorsque ce projet a des exigences spécifiques qui sont plus faciles à gérer séparément du parent, tels que les fichiers qui ne doivent pas être ignorés.

Pour en savoir plus sur .gitignore, consultez Ignorer les fichiers. Consultez également la collection de fichiers .gitignore de démarrage proposés pour différentes plateformes dans le dépôt gitignore.

Supprimer des données sensibles d’un référentiel

Si les fichiers .gitignore peuvent être utiles pour aider les contributeurs à éviter de valider des données sensibles, ils ne sont que fortement conseillés. Les développeurs peuvent toujours contourner un .gitignore fichier pour ajouter des fichiers s’ils sont suffisamment motivés, et parfois les fichiers peuvent glisser parce qu’ils ne répondent pas à la configuration du .gitignore fichier. Les participants au projet doivent toujours être à l’affût des validations qui contiennent des données qui ne doivent pas être incluses dans le référentiel ou son historique.

Règles de protection de branche

Vous pouvez créer une règle de protection de branche pour appliquer certains flux de travail pour une ou plusieurs branches. Par exemple, vous pouvez exiger une évaluation approuvée ou effectuer des vérifications d’état pour toutes les demandes de tirage fusionnées dans la branche protégée.

Vous pouvez utiliser les flux de travail qui protègent la branche pour :

• Exécutez une build pour vérifier que les modifications du code peuvent être générées ;
• Exécutez un linter pour vérifier les fautes de frappe et la conformité aux conventions de codage internes ;
• Exécutez des tests automatisés pour vérifier les modifications de comportement du code ;
• Et ainsi de suite.

Réviseurs requis dans les demandes de tirage

Vous pouvez améliorer la sécurité des référentiels en exigeant des révisions avant que le code ne soit fusionné dans des branches importantes. Les réviseurs requis aident à appliquer la qualité, la sécurité et la responsabilité.

Pour configurer les réviseurs requis :

1. Accédez au référentiel sur GitHub.
2. Sous le nom du référentiel, cliquez sur Branches de paramètres>.
3. En regard de la branche que vous souhaitez protéger, cliquez sur Ajouter une règle ou modifiez une règle existante.
4. Sélectionnez Exiger des révisions de demande de tirage avant de fusionner.
5. Si vous le souhaitez, vérifiez :
   • Exiger une révision des propriétaires de code
   • Ignorer les approbations des demandes de tirage obsolètes lorsque de nouvelles validations sont envoyées (push)
   • Exiger l’approbation d’une personne autre que le dernier pusher

Les révisions requises ne peuvent pas être ignorées sans autorisations d’administrateur. Ils garantissent que les modifications proposées sont examinées par un autre contributeur ou propriétaire de code désigné avant d’être fusionnées.

Pour plus d’informations, consultez À propos des branches protégées.

Ajouter un fichier CODEOWNERS

En ajoutant un fichier CODEOWNERS à votre dépôt, vous pouvez affecter des membres d’équipe individuels ou des équipes entières en tant que propriétaires de code à des chemins d’accès dans votre dépôt. Ces propriétaires de code sont alors indispensables pour les révisions de requêtes Pull sur les modifications apportées aux fichiers dans un chemin pour lequel ils sont configurés.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Vous pouvez créer le fichier CODEOWNERS à la racine du référentiel ou dans le dossier docs ou .github.