Gérer les alertes de sécurité GitHub

8 minutes

GitHub centralise toutes les découvertes de sécurité dans l’onglet Sécurité de votre référentiel. L’onglet Sécurité fournit un tableau de bord unifié permettant de gérer les alertes d’analyse des secrets en même temps que les résultats de l’analyse du code et les vulnérabilités de dépendance. Comprendre comment naviguer et utiliser ces alertes vous permet de répondre efficacement aux expositions d’informations d’identification.

Accès aux alertes d’analyse des secrets

L’onglet Sécurité de GitHub sert de hub central pour toutes les informations relatives à la sécurité sur votre dépôt.

Accéder aux alertes de sécurité

Si vous souhaitez accéder aux alertes d’analyse de secrets dans votre référentiel :

Ouvrez votre référentiel sur GitHub.com.
Sélectionnez l’onglet Sécurité dans le menu de navigation du référentiel.
Sélectionnez Analyse des secrets (ou alertes d’analyse des secrets) pour afficher tous les secrets détectés.

L’onglet Sécurité fournit une vue complète de la posture de sécurité de votre référentiel, ce qui facilite l’identification et la hiérarchisation des problèmes.

Vue d’ensemble de la sécurité

La vue d’ensemble de la sécurité s’affiche :

Nombre d’alertes par type : nombre d’analyses secrètes, d’analyse de code et d’alertes Dependabot.
Statut ouvert vs résolu : problèmes nécessitant une attention versus ceux qui sont déjà résolus.
Modifications récentes : nouvelles alertes et alertes récemment résolues.

Cette vue générale vous aide à évaluer rapidement l’état de sécurité du référentiel et à hiérarchiser les efforts de réponse.

Découverte des alertes d’analyse de secrets

Chaque alerte d’analyse secrète fournit des informations détaillées sur les informations d’identification détectées pour vous permettre d’évaluer et de corriger l’exposition.

Composants d’alerte

Lorsque vous sélectionnez une alerte d’analyse des secrets, GitHub affiche plusieurs éléments clés d’informations.

Type de secret

Catégorie d’informations d’identification détectée, par exemple :

« Clé de compte de stockage Azure ».
« Clé API Stripe ».
« Clé d’accès Amazon Web Services (AWS) ».
« Jeton d’accès personnel GitHub ».
« Chaîne de connexion de base de données ».

Le type de secret vous aide à comprendre quel service est affecté et quelles actions de rotation sont nécessaires.

Informations sur l’emplacement

Détails précis sur l’emplacement où le secret s’affiche :

Chemin d’accès au fichier : chemin d’accès complet au fichier contenant le secret (par exemple, src/services/PaymentProcessor.cs).
Numéro de ligne : ligne exacte où se trouve le secret.
Branche : branche où le secret a été détecté.
Commit : commit spécifique ayant introduit le secret (précise le hachage et l’auteur du commit).

Ces informations vous permettent de localiser rapidement le code problématique et de comprendre quand l’exposition s’est produite.

Extrait de code

Aperçu du code contenant le secret, avec les informations d’identification mises en surbrillance :

// Example alert code snippet
public class PaymentService
{
    // SECRET DETECTED: Stripe API Key
    private const string _apiKey = "sk_live_51Abc123XYZ789...";
    
    public async Task ProcessPayment(...)
    {
        // Payment processing logic
    }
}

État de validité

Pour les secrets validés par un partenaire, GitHub indique si les informations d’identification sont les suivantes :

Valide : les informations d’identification sont confirmées actives et fonctionnelles.
Non valide : les informations d’identification sont révoquées ou ne sont plus actives.
Inconnu : La validité n’a pas pu être déterminée.

Cet état vous aide à hiérarchiser la correction : les informations d’identification valides nécessitent une rotation immédiate.

États d’alerte

Les alertes d’analyse de secrets peuvent se trouver dans plusieurs états :

Ouvert : le secret est détecté et nécessite une attention particulière.
Résolu : le secret est corrigé (pivoté et supprimé du code).
Ignoré : l’alerte est marquée comme un risque faux positif ou accepté.

Comprendre les états d’alerte vous aide à suivre la progression de la résolution des problèmes de sécurité.

Filtrage et tri des alertes

Lorsque vous utilisez plusieurs alertes, les fonctionnalités de filtrage et de tri vous aident à vous concentrer sur des problèmes spécifiques.

Filtrer par type de secret

Filtrez les alertes pour vous concentrer sur des types d’informations d’identification spécifiques :

Dans la vue des alertes de scan secret, recherchez les options Filtre.
Sélectionnez Type de secret dans le menu filtre.
Choisissez un ou plusieurs types de secrets à afficher (par exemple, « Clé d’accès Amazon Web Services (AWS), » « Informations d’identification Azure »).

Le filtrage par type vous permet d’examiner des types spécifiques d’exposition ou d’effectuer des corrections ciblées.

Filtrer par état

Affichez les alertes en fonction de leur état de résolution :

Alertes ouvertes : secrets nécessitant une investigation et une correction.
Alertes résolues : des secrets détectés précédemment qui sont traités.
Alertes ignorées : alertes marquées comme faux positifs.

Le filtrage par état vous permet de vous concentrer sur les problèmes actifs tout en conservant une visibilité sur le travail de sécurité historique.

Trier et rechercher

Triez la liste des alertes par :

Les plus récents d'abord : Secrets récemment détectés (par défaut).
Plus ancien en premier : problèmes de longue date qui pourraient être négligés.
Type de secret : regroupez des types d’informations d’identification similaires.

Utilisez la fonctionnalité de recherche pour rechercher des alertes par nom de fichier, chemin d’accès ou type de secret.

Résolution des alertes d’analyse de secrets

Après avoir corrigé un secret, marquez l’alerte comme résolue pour conserver des enregistrements de sécurité précis.

Exigences de résolution

Une alerte doit être marquée comme résolue après avoir effectué les étapes de correction suivantes :

Rotation des informations d’identification : le secret exposé est révoqué et remplacé par un nouveau secret.
Supprimé du code : le secret n’est plus codé en dur dans les validations (y compris l’historique Git).
Stockage sécurisé implémenté : les informations d’identification sont désormais accessibles via des variables d’environnement ou un service de gestion des secrets.
Fonctionnalité vérifiée : les applications utilisant les informations d’identification pivotées fonctionnent correctement.

Important

La suppression d’un secret de la dernière validation n’est pas suffisante s’il reste dans l’historique Git où il peut toujours être découvert.

Comment résoudre une alerte

Pour marquer une alerte comme résolue :

Accédez à l’alerte spécifique sous l’onglet Sécurité.
Passez en revue les détails de l’alerte pour confirmer que la correction est terminée.
Sélectionnez la liste déroulante Fermer l’alerte .
Choisissez une raison de résolution :
- Révoqué : il est effectué une rotation des informations d’identification, et celles-ci ne sont plus valides.
- Faux positif : la détection n'était pas réellement un secret.
- Utilisé dans les tests : données de test plutôt qu’informations d’identification de production.
Ajoutez éventuellement un commentaire expliquant la résolution.
Confirmez la résolution.

L’alerte passe à l’état résolu et n’apparaît plus dans la liste des alertes ouvertes.

Suppression des secrets de l’historique Git

Étant donné que Git conserve l’historique complet, la suppression d’un secret de votre code actuel n’élimine pas l’exposition. Les informations d’identification restent accessibles dans les commits historiques.

Pour les commits récents (pas encore envoyés)

Si vous devez envoyer (push) les commits contenant le secret :

# Amend the most recent commit
git add .
git commit --amend --no-edit

# For older commits, use interactive rebase
git rebase -i HEAD~5  # Adjust number based on commit depth

Marquez les commits problématiques pour modification, supprimez le secret, puis poursuivez le rebaser.

Pour les commits déjà envoyés (push)

Pour les validations déjà présentes dans le référentiel distant, vous devez réécrire l’historique à l’aide d’outils tels que git filter-repo ou d’autres outils similaires :

# Install git-filter-repo if not available
pip install git-filter-repo

# Remove a specific string from all files in history
git filter-repo --replace-text <(echo "sk_live_51Abc123XYZ==>REDACTED")

Après la réécriture de l’historique, forcez les modifications :

git push --force-with-lease origin main

Avertissement

La réécriture de l’historique envoyé affecte tous les collaborateurs. Coordonnez avec votre équipe, elle devra cloner à nouveau ou réinitialiser soigneusement ses référentiels locaux après un envoi (push) forcé.

Pour les référentiels publics

Si un secret a été exposé dans un référentiel public :

Renouvelez immédiatement les identifiants. Supposons que les informations d’identification sont compromises (les dépôts publics sont analysés en continu).
Pour empêcher la découverte future dans les scénarios de haute sécurité, vous devrez peut-être supprimer le secret de l’historique Git. Avertissement : les forks et les clones peuvent contenir le secret. Si l’historique Git est réécrit, les membres de l’équipe doivent recloniser ou réinitialiser leurs dépôts locaux.
Surveillez l’utilisation non autorisée de l’ancienne information d’identification.

Travail avec des faux positifs

L’analyse des secrets détecte parfois des modèles qui ne sont pas des secrets réels. La gestion correcte des faux positifs permet à votre liste d’alertes de se concentrer sur les problèmes réels.

Quand ignorer

Ignorer les alertes uniquement lorsque vous êtes certain qu’elles ne sont pas des secrets réels :

Données de test : exemples d’informations d’identification dans les appareils de test clairement marqués comme faux.
Documentation : Exemples d’extraits de code montrant des formats d’informations d’identification sans valeurs réelles.
Coïncidence du modèle : chaînes aléatoires qui correspondent aux modèles secrets, mais qui ne sont pas des informations d’identification.

Avertissement

Soyez conservateur avec les licenciements. S’il y a un doute si un modèle détecté est réel, traitez-le comme un secret et faites-le pivoter.

Comment ignorer

Pour ignorer un faux positif :

Accédez à l’alerte sous l’onglet Sécurité.
Passez en revue attentivement l’alerte pour confirmer qu’elle n’est pas un véritable secret.
Sélectionnez Fermer l’alerte et choisissez Faux positif.
Ajoutez un commentaire détaillé expliquant pourquoi ce n’est pas un vrai secret.
Confirmez le licenciement.

Documentez toujours les licenciements avec une justification claire pour les audits futurs de référence et de sécurité.

Meilleures pratiques pour la gestion des alertes

Implémentez ces pratiques pour gérer efficacement les alertes d'analyse de secrets.

Répondre rapidement

Lorsque l’analyse des secrets détecte un identifiant :

Évaluer immédiatement : passez en revue l’alerte pour confirmer qu’il s’agit d’un véritable secret.
Rotation rapide : révoquez et remplacez les informations d’identification exposées dès que possible.
Supprimer du code : implémentez un stockage sécurisé et supprimez le secret codé en dur.
Vérifier la correction : assurez-vous que les applications fonctionnent correctement avec les informations d’identification réinitialisées.

Plus vous répondez rapidement, plus la fenêtre d’opportunité est réduite pour un accès non autorisé.

Hiérarchiser en fonction du risque

Tous les secrets n’ont pas un risque égal. Concentrez-vous d’abord sur :

Informations d’identification valides : les alertes marquées comme « Valide » indiquent des secrets actifs et fonctionnels.
Systèmes de production : informations d’identification pour les environnements de production plutôt que pour le développement.
Accès à privilèges élevés : identifiants administratifs ou à privilèges élevés.
Dépôts publics : expositions dans des dépôts publics où le secret est largement accessible.

Utiliser des alertes comme opportunités d’apprentissage

Quand des secrets sont détectés :

Comprendre comment le secret s'est retrouvé dans le code.
Identifiez les lacunes dans les pratiques de développement ou les outils.
Partagez des connaissances avec votre équipe sur la gestion sécurisée des secrets.
Mettez à jour les modèles et la documentation pour empêcher les expositions similaires.

Utiliser GitHub Copilot

GitHub Copilot peut aider à corriger les alertes de deux manières :

Mode Demander : Analyser les alertes, comprendre l’étendue de l’exposition et planifier des stratégies de correction.
Mode agent : implémentez des modifications de code pour supprimer des secrets codés en dur et utiliser un stockage sécurisé.

Commentaires

Cette page a-t-elle été utile ?