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

Effectué

Nous présentons ici certains des outils et des techniques de sécurité de base disponibles pour les administrateurs de dépôts GitHub.

Remarque

Le contenu suivant ne couvre pas les principes fondamentaux de l’écriture de code sécurisé, mais plutôt des considérations importantes en matière de sécurité, les outils et les fonctionnalités à utiliser dans un dépôt GitHub.

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

La sécurité de l’application est importante. Les actualités racontent souvent des histoires sur la violation des systèmes de certaines entreprises mais aussi de données privées volées des clients et des entreprises.

Quels sont donc les problèmes auxquels réfléchir 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 être sûrs d’authentifier correctement les utilisateurs qui accèdent aux données et que ces utilisateurs disposent pour cela des autorisations appropriées. Grâce aux données ou aux journaux d’archivage ou d’historique, nous devons être en mesure de trouver des preuves lorsque quelque chose se passe mal.

La création et le déploiement d’applications sécurisées peuvent être considérées sous de nombreux aspects. Voici trois choses à prendre en compte :

• Il y a un problème général de connaissance : De nombreux développeurs et d’autres membres du personnel considèrent qu’ils comprennent la sécurité, mais en fait, ce n’est pas le cas. La cybersécurité est une discipline en constante évolution. Un programme d’éducation et de formation en continu est essentiel.

• Le code doit être créé correctement et de façon sécurisée : Nous devons vérifier que le code est correctement créé et qu’il implémente de façon sécurisée les fonctionnalités nécessaires. Nous devons également nous assurer que les fonctionnalités ont été conçues avec à l’esprit la sécurité.

• Les applications doivent se conformer aux règles et aux réglementations : Nous devons nous assurer de la conformité du code aux règles et aux réglementations obligatoires. Nous devons tester la conformité pendant la génération du code et la retester périodiquement, même après le déploiement.

Sécurité à chaque étape

La sécurité n’est pas un élément 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 des logiciels. Ceci concept est encore plus important pour les applications critiques, et pour celles qui traitent des informations sensibles ou hautement confidentielles.

En pratique, pour responsabiliser les équipes par rapport à ce qu’elles développent, il est nécessaire de baser les processus du cycle de vie du développement sur une approche déplacer vers la gauche ou d’être terminées plus tôt. En déplaçant les étapes du point de contrôle final au moment du déploiement à une étape antérieure, moins d’erreurs sont commises, et les développeurs peuvent agir plus rapidement.

Les concepts de sécurité des applications n’étaient pas une préoccupation majeure des développeurs par le passé. Outre les problèmes d’éducation et de formation, cela est dû au fait que les organisations ont privilégié le développement rapide de fonctionnalités.

Cependant, 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 faire partie des processus de livraison quotidiens.

En gros, quand le temps nécessaire pour retravailler 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 d’intercepter des problèmes plus rapidement. La prise en compte de problèmes plus tôt peut réduire le temps nécessaire au développement de logiciels de qualité.

Le « Shift Left » est un changement de processus, mais il ne s’agit pas d’un unique contrôle ou d’un outil spécifique. Il s’agit de centrer toute votre sécurité davantage sur les développeurs et de leur apporter des commentaires sur la sécurité où ils se trouvent.

Fonctionnalités de l’onglet Sécurité

GitHub propose des fonctionnalités de sécurité qui permettent de sécuriser les données dans les référentiels et dans les organisations. Pour trouver 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é.

À partir de 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. Les voici :

• 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 fichier SECURITY.md à 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.
• Avis 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 à trouver, trier et corriger les vulnérabilités et les erreurs dans votre code.

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

Remarque

Les avis d’alerte Dependabot pour les programmes malveillants sont actuellement en version bêta et peuvent être modifiés. Seuls les avis qui ont été examinés par GitHub déclenchent des alertes Dependabot.

Nous explorons ensuite 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 néanmoins aussi des risques potentiels. Le fait que tout le monde puisse proposer publiquement des correctifs de bogues implique certaines responsabilités. La plus importante est la divulgation responsable des informations qui pourraient conduire à des failles de sécurité avant que leurs bogues sous-jacents puissent être résolus. Les développeurs qui souhaitent signaler ou résoudre des problèmes de sécurité recherchent un fichier SECURITY.md à la racine d’un dépôt afin de divulguer de façon responsable leurs préoccupations. La fourniture de directives dans ce fichier accélère la résolution de ces problèmes critiques.

Pour plus d’informations sur SECURITY.md, consultez Ajout d’une stratégie de sécurité à votre dépôt.

Avis de sécurité GitHub

Les avis de sécurité GitHub permettent aux chargés de maintenance des dépôts de discuter et résoudre en privé une vulnérabilité de sécurité dans un projet. Après avoir collaboré sur un correctif, les mainteneurs de dépôt peuvent publier l’avis de sécurité pour rendre publique la vulnérabilité de sécurité auprès de la communauté du projet. En publiant des avis de sécurité, les mainteneurs de dépôt facilitent la mise à jour des dépendances de package et la recherche de l’impact des vulnérabilités de sécurité pour leur communauté. GitHub stocke les avis publiés dans la liste Vulnérabilités et risques courants (CVE). Cette liste sert à notifier automatiquement les dépôts affectés qui utilisent des logiciels ayant 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 en dehors votre dépôt avec .gitignore

Il est facile pour les développeurs de ne pas prendre garde aux fichiers inclus dans un commit. Parfois, ces fichiers négligés sont de peu d’importance, comme les fichiers de build intermédiaires. Il existe toutefois toujours le risque qu’une personne valide par inadvertance des données sensibles. Par exemple, une personne peut valider une clé API ou des données de configuration privée utilisables par un acteur malveillant. Une technique permettant d’éviter de ces risques est de créer et de gérer des fichiers .gitignore. Ces fichiers indiquent aux outils clients, comme l’utilitaire en ligne de commande git, d’ignorer les chemins et les modèles lors de l’agrégation de fichiers pour un commit.

L’exemple suivant illustre quelques cas d’utilisation courants où il est utile d’ignorer des 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 dépôt peut contenir plusieurs fichiers .gitignore. 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. La maintenance du fichier racine .gitignore représente un effort considérable, même si ajouter un fichier .gitignore dans un répertoire de projet peut s’avérer utile quand ce projet a des exigences spécifiques plus faciles à gérer séparément du parent, comme les fichiers ne devant pas être ignorés.

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

Supprimer les données sensibles d’un dépôt

Si les fichiers .gitignore peuvent être utiles pour aider les contributeurs à éviter de valider des données sensibles, il s’agit simplement d’une suggestion forte. Les développeurs, s’ils sont suffisamment motivés, peuvent néanmoins toujours la contourner pour ajouter des fichiers et des fichiers peuvent aussi parfois échapper à ce contrôle, car ils ne satisfont pas à la configuration du fichier .gitignore. Les participants au projet doivent être attentifs aux commits contenant des données ne devant pas être incluses dans le dépôt ou dans son historique.

Important

Vous devez supposer que toutes les données commitées dans GitHub peuvent avoir été compromises à un moment ou à un autre. Le simple remplacement d’un commit n’est pas suffisant pour garantir l’accessibilité des données dans le futur. Pour obtenir le guide complet de la suppression de données sensibles dans GitHub, consultez Suppression de données sensibles dans un dépôt.

Règles de protection de branche

Vous pouvez créer une règle de protection de branche pour appliquer certains workflows à 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 workflows qui protègent la branche afin de :

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

Ajouter un fichier CODEOWNERS

En ajoutant un fichier CODEOWNERS à votre dépôt, vous pouvez affecter des membres individuels de l’équipe ou des équipes entières en tant que propriétaires de code à des chemins 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.