GitHub : prioriser la sécurité selon la protection des dépôts

L’évaluation des risques de sécurité GitHub indique désormais si les constats concernent des dépôts protégés ou non protégés. Ce repère ne remplace ni l’analyse d’une vulnérabilité ni la connaissance du produit ; il aide en revanche à voir où la couverture de sécurité manque, puis à organiser une amélioration mesurable plutôt qu’à empiler des alertes.

Un contexte de couverture pour mieux orienter l’effort

GitHub ajoute ce statut aux évaluations de risque de code et de secrets. Les administrateurs d’organisation et responsables sécurité peuvent les lancer depuis l’onglet Security, section Assessments. L’information répond à une question opérationnelle simple : les résultats que nous observons se trouvent-ils dans des dépôts déjà protégés, ou dans des zones qui n’ont pas encore le même niveau de garde-fous ?

Une étiquette « non protégé » ne veut pas dire qu’un dépôt est compromis, et une étiquette « protégé » ne garantit pas l’absence de risque. Elle sert à rapprocher les constats de sécurité de la configuration qui les entoure. C’est particulièrement utile quand une organisation a grandi par produits, équipes ou acquisitions et que les pratiques de protection ne sont pas homogènes.

Transformer le constat en plan de couverture

Segmenter avant de généraliser

Commencez par regrouper les dépôts non protégés selon leur exposition : service public, application interne, bibliothèque partagée ou prototype archivé. Ajoutez le propriétaire, la branche de production et les données manipulées. Cette cartographie évite d’appliquer la même réponse à un dépôt de démonstration et à une API qui traite des données clients.

Définir un socle vérifiable

Pour chaque groupe, convenez d’un minimum : analyse de code ou de secrets adaptée, responsables de traitement, processus de correction et revue régulière. Conservez une exception documentée lorsqu’un dépôt ne peut pas être couvert immédiatement. Le résultat attendu n’est pas seulement un pourcentage de dépôts activés, mais un niveau de protection justifié, observable et maintenable.

Éviter les faux raccourcis de priorisation

La protection du dépôt est un critère parmi d’autres. Une vulnérabilité atteignable sur un service exposé mérite une réponse urgente, même si des protections sont déjà actives. À l’inverse, un dépôt non protégé sans usage actif peut relever d’un chantier planifié. Croisez ce nouveau signal avec l’exposition, la criticité métier, la date du dernier déploiement et la capacité réelle de correction.

Cette démarche complète notre méthode pour prioriser les alertes Dependabot par atteignabilité : l’une situe une alerte dans le code exécuté, l’autre aide à localiser les écarts de couverture à l’échelle du portefeuille. Pour les dépôts qui contiennent des identifiants, la protection des secrets avant le push ajoute une barrière complémentaire.