Dans un monde numérique moderne, presque toutes les entreprises sont des sociétés de développement de logiciels. Votre entreprise peut développer des applications qui offrent des expériences client numériques ou créer des logiciels qui permettent la productivité des employés. Les développeurs utilisent GitHub pour collaborer efficacement et gérer le contrôle de version, l'enregistrement et le contrôle des modifications logicielles. Les équipes de sécurité savent qu'elles doivent surveiller GitHub car les référentiels stockent souvent des informations sensibles en clair, ce qui en fait des cibles attrayantes pour les cybercriminels. Cependant, ce processus manuel chronophage peut entraîner des erreurs et les violations de données.
Comprendre comment les acteurs de la menace trouvent les informations sensibles stockées dans GitHub et mettre en œuvre les meilleures pratiques pour surveiller les fuites de données GitHub peut aider à atténuer les risques de violation de données et à améliorer votre programme de sécurité global.
Que sont les secrets ?
Dans GitHub, les secrets font référence à tous les identifiants d'authentification numérique qui permettent l'interopérabilité des services, des infrastructures et des applications, notamment :
- 0Jetons d'authentification
- Clés API
- Nom d'utilisateur
- Mots de passe
- Clés de chiffrement
- Certificats de sécurité
Le stockage de ces informations sous forme de texte brut dans le code source est appelé codage en dur.
Pourquoi les développeurs stockent des secrets dans GitHub
Chaque jour, les développeurs doivent écrire un nouveau code et le tester dans leurs environnements de production. En codant en dur les secrets, ils peuvent exécuter des tests sans avoir à se souvenir et à saisir manuellement chaque identifiant, à chaque fois.
Pendant ce temps, les infrastructures numériques modernes créent des interconnexions complexes entre les applications et les services, nécessitant tous des secrets pour pouvoir fonctionner comme une unité complète. De plus, diverses équipes internes doivent partager des informations d'identification pendant les processus de développement de code, notamment :
- DevOps
- Ingénieurs en fiabilité du site (SRE)
- Sécurité
Les secrets de codage en dur permettent aux développeurs de mettre à jour plus facilement les services, de mettre à l'échelle les applications et d'externaliser le travail de développement. Cependant, étant donné que ces secrets donnent accès à des ressources critiques, le codage en dur crée un risque de sécurité. Par exemple, chaque fois que les développeurs clonent, extraient ou bifurquent le code source, le processus réplique les secrets en clair.
Comment les acteurs de la menace trouvent et divulguent des secrets GitHub
Tout comme l'ajout de nouvelles applications étend une surface d'attaque externe, les secrets de codage en dur étendent la surface d'attaque GitHub. Lorsque les développeurs travaillent avec les secrets codés en dur, ils créent une prolifération de secrets, ce qui signifie qu'ils perdent le contrôle sur qui peut accéder aux secrets et où ils stockent les secrets.
Utilisation accidentelle de comptes personnels
GitHub Enterprise exige que les développeurs utilisent un compte "personnel" pour rejoindre le référentiel de l'organisation. Même si le compte est lié à l'e-mail d'entreprise du développeur, tout référentiel créé sous ce compte est considéré comme un référentiel personnel et les référentiels personnels sont définis sur public par défaut.
Lorsque les développeurs de logiciels publient leur code, ils doivent sélectionner de manière proactive leur entreprise en tant que propriétaire. En fonction du fonctionnement de GitHub, ils peuvent accidentellement sélectionner leur nom d'utilisateur, créant ainsi le référentiel en tant qu'emplacement personnel et public par défaut. Si le code comprend des informations d'identification, les pirates peuvent facilement les rechercher.
Attaques de phishing
Les attaques de phishing fonctionnent pour l'accès GitHub de la même manière qu'elles fonctionnent pour l'accès informatique de l'entreprise. Les attaquants utilisent des tactiques d'ingénierie sociale pour découvrir les membres de votre équipe de développement, puis ils envoient de faux e-mails qui semblent légitimes, forçant les gens à renoncer à leurs mots de passe.
Étant donné que les employés doivent utiliser un compte GitHub personnel pour accéder à leur référentiel privé, un identifiant de développeur volé peut compromettre le référentiel de votre organisation.
Mots de passe réutilisés ou partagés
Les développeurs doivent accéder à des ressources, telles que GitHub, afin de pouvoir effectuer leurs tâches. De plus, ils ont besoin de ces autorisations numériques pour pouvoir mettre à jour le code et le publier à temps. Lorsque les entreprises ne disposent pas de mesures de sécurité rigoureuses, elles peuvent être plus sujettes aux erreurs humaines accidentelles. Par exemple, mots de passe réutilisés et partager des secrets par e-mail ou des outils de communication, comme Slack.
Secrets oubliés dans les fichiers de code d'application
Les développeurs peuvent coder en dur un identifiant pendant le développement, dans l'intention mais oublier de supprimer plus tard. Lorsqu'ils le font, les secrets codés en dur restent stockés dans le système de contrôle de version (VCS). Les attaquants utilisant des scanners qui recherchent des modèles liés au type d'informations d'identification peuvent découvrir ces secrets.
Pipelines d'actions GitHub
GitHub Actions est une automatisation du workflow CI/CD. Si votre action GitHub extrait des images de conteneur pour exécuter des composants d'application ou des environnements de test, elle peut inclure des informations d'identification codées en dur. Avec ces secrets écrits en clair, les attaquants peuvent analyser vos fichiers de configuration pour localiser les secrets exposés.
Importance de la surveillance des fuites de données GitHub
Pour les développeurs, les identifiants de codage en dur sont synonymes de rapidité et de productivité. Les entreprises veulent que les logiciels soient livrés à temps, et les identifiants de codage en dur permettent aux ingénieurs logiciels de tester facilement les applications.
Pendant ce temps, les équipes de sécurité débordées souffrent déjà de la fatigue des alertes rien qu'en surveillant la pile technologique de l'entreprise. L'ajout d'un autre emplacement crée encore un autre fardeau. De plus, la plupart des solutions de surveillance GitHub examinent le code pour les secrets intégrés, et non le référentiel pour les accès anormaux.
Cet écart entre les outils de développement et les technologies de surveillance de la sécurité signifie que les entreprises manquent souvent de capacités de détection en temps réel. Ils ne découvrent les secrets compromis qu'après que les attaquants les ont vendus ou les ont utilisés dans une attaque de suivi.
Pour les entreprises qui assument que leurs référentiels privés atténuent les risques, Rapport de recherche de GitGuardian ont constaté que les référentiels privés étaient quatre fois plus susceptibles de subir un incident. En outre, les statistiques de la recherche ont montré l'ampleur du problème en notant :
- 1,050 400 secrets uniques, en moyenne, ont été divulgués pour une entreprise typique avec 4 développeurs et XNUMX ingénieurs AppSec
- 1 ingénieur AppSec doit gérer en moyenne 3,413 XNUMX occurrences de secrets
- Plus de 6 millions de secrets ont été détectés dans des référentiels publics
- 3 dépôts publics commettent sur 1,000 XNUMX exposés au moins un secret
- 84 informations d'identification AWS IAM ont été divulguées pour 10,000 XNUMX validations de référentiel public analysées
- Plus de 500 messages de validation publics contenaient des jetons d'accès personnels GitHub
Les organisations doivent prendre des mesures proactives pour atténuer les risques et mettre en place une surveillance pour détecter les secrets compromis.
L'un de nos clients est une entreprise Fortune 100 qui utilise la surveillance des fuites de code source et GitHub de Flare pour automatiser le suivi des relations entre les actifs entre les référentiels GitHub, les utilisateurs, les domaines et les e-mails au sein des équipes de développeurs multinationales. Apprenez-en davantage sur la manière dont nos clients suivent et traitent les secrets divulgués sur GitHub. sans recherches manuelles fastidieuses et inefficaces.
Meilleures pratiques de prévention des fuites de données GitHub
Bien qu'il puisse être difficile d'empêcher les fuites de secrets GitHub, vous pouvez prendre plusieurs mesures pour atténuer les risques.
Limiter l'accès au référentiel
Lorsque vous fournissez un accès, utilisez le principe du moindre privilège en limitant qui peut lire ou modifier le code. De plus, vous devez documenter toutes les activités afin de pouvoir suivre les modifications du code.
Implémenter et appliquer des mots de passe forts
Les mots de passe qui autorisent l'accès à votre référentiel doivent suivre les meilleures pratiques en matière de mot de passe. Au minimum, vous devez vous assurer que vous définissez un paramètre approprié :
- longueur du câble
- Complexité
- Date d'expiration
- Rotation
Protéger les identifiants d'accès
Les développeurs utilisent des identifiants de connexion combinés à des mots de passe ou des clés privées pour accéder à votre référentiel. Voici quelques façons de protéger ces informations d'identification :
- Mot de passe protégeant les clés privées
- Donner des jetons matériels aux développeurs
- Touches d'accès rotatives
Surveiller les sessions privilégiées
La gestion des accès à privilèges (PAM) est aussi essentielle dans les environnements de développement que dans les environnements informatiques d'entreprise. Vous devez surveiller, documenter et enregistrer les sessions privilégiées sur :
- hybrides
- Utilisateurs
- Scripts
- Outils d'automatisation
Rechercher les informations d'identification codées en dur
En analysant votre référentiel à la recherche d'informations d'identification codées en dur, vous pouvez détecter un risque avant qu'une compromission ne se produise. Lorsque vous détectez une fuite potentielle, vous devez :
- Révoquer le secret exposé
- Nettoyer l'historique du référentiel
- Inspecter les journaux
Lorsque vous nettoyez un référentiel après avoir identifié un secret potentiellement exposé, vous devez vous rappeler que le secret sera visible dans tous les commits et forks de référentiel précédents. Toutes les versions en miroir sont toujours risquées.
Surveiller les référentiels publics personnels des membres
Vous pouvez utiliser workflows pour aider à surveiller les référentiels personnels de vos développeurs à la recherche de code potentiellement divulgué.
Scannez GitHub pour le code qui a fui
By scanner GitHub à la recherche de code divulgué, vous recherchez au-delà des référentiels de vos membres des secrets potentiellement compromis.
Comment Flare peut aider
Avec Flare, les équipes de sécurité peuvent intégrer Surveillance GitHub tout en réduisant les charges traditionnelles associées au processus. Nous combinons des systèmes de collecte de données de pointe avec notre moteur de réduction du bruit et de hiérarchisation afin que les équipes de sécurité disposent du contexte nécessaire pour classer la criticité d'une fuite de données.
Avec Flare, votre équipe de sécurité peut créer des processus efficaces qui lui permettent de répondre de manière proactive aux fuites de données techniques, réduisant ainsi le temps et les coûts associés à un incident secret.
