• Accueil
  • Solutions
    • DLP Poste de Travail
    • CTEM - Digital Supply Chain & Attack Surface
    • Prévention des fuites de données sans agent (DLP)
    • Gestion continue des menaces dues aux codes tiers dans vos sites web
    • SaaS Security Posture Management (SSPM)
    • Sensibilisation à la Cybersécurité
    • Protection prédictive (PRE-CRIME)
    • Cyber Security Ratings
    • Breach & Attack Simulation
    • Multi Factor Autentication & Micro Segmentation
    • EDR (EndPoint Detection & Response)
    • Collaboration optimisée et sécurisée
    • Sécurité de la messagerie
    • Chiffrement des données
  • News
  • Contact
  • Plate-forme
    • Vue Générale
    • Intégrations
  • Cas d'usages
    • Gestion des erreurs de configuration
    • Analyse des intégrations tierces parties
    • Détection et réponse de sécurité SaaS
    • Exposition des données SaaS
  • Ressources
    • Blog
    • Documentations

Traduction depuis : https://www.suridata.ai/blog/githubs-new-security-feature-made-available-to-everyone

Haviv Ohayon / 17 mai 2023

La nouvelle fonctionnalité de sécurité de GitHub mise à la disposition de tous

GitHub, le service d’hébergement Internet populaire pour le développement de logiciels et le contrôle de version, a récemment annoncé la disponibilité d’un nouveau service qui recherche les secrets dans le code des développeurs. Il offre une « protection push » qui bloque la publication accidentelle de secrets pouvant entraîner des failles de sécurité. Il s’agit d’une avancée significative en matière de sécurité des applications.

Image Credits: Suridata

Qu’est-ce qu’un secret ?

Pour les utilisateurs de GitHub, le mot « secret » a une signification distincte de la compréhension générale du mot. Dans le contexte de GitHub et du développement de logiciels, un secret est tout type d’information privée, telle qu’un jeton, un mot de passe ou une authentification privée utilisée par un fournisseur de services pour permettre les interactions entre les applications. Le développement de logiciels implique souvent l’utilisation de secrets et l’intégration de ces secrets dans le code.

Avec les secrets, cependant, vient le risque qu’un secret ait été compromis. Un développeur peut commettre un secret sur un morceau de code sans s’en rendre compte et, ce faisant, le révéler publiquement, ce qui rend le secret peu sécurisé. En d’autres termes, le secret n’est plus un secret. Sa capacité à fournir des connexions privées uniques n’est plus assurée. Un acteur malveillant peut utiliser le secret comme informations d’identification volées pour monter une attaque.

La nouvelle protection push d’analyse de secret de GitHub

Pour atténuer le risque d’intégrer des secrets dans le code et de les rendre publics, il est nécessaire d’analyser le code pour détecter l’existence du secret avant de le publier. Un développeur ne doit pas utiliser un secret dans le code, surtout si le code est publié sur Internet. Cela semble assez simple, mais il y a deux défis dans ce scénario. On identifie correctement les secrets dans le code, car leur structure varie d’un service à l’autre. Ensuite, il y a la prévention. Comment le développeur saura-t-il s’il a des secrets dans son code avant de le publier ?

GitHub offre une solution. Il a offert un service intégré qui détecte les secrets et alerte les développeurs si ces secrets sont dans leur code. Cette fonctionnalité est utile, mais elle analyse uniquement le code qui a déjà été publié. Ce n’est pas idéal, car cela rend la sécurité des applications réactive par nature. Inévitablement, certaines vulnérabilités secrètes divulguées passeraient entre les mailles du filet.

La nouvelle fonctionnalité de « protection push », récemment annoncée par GitHub, change la dynamique de la situation. La protection push vérifie plus d’une centaine de types de jetons/secrets lorsque les développeurs poussent le code en production. Il bloque la poussée s’il détecte la présence d’un secret. GitHub décrit le processus comme une recherche de ce qu’il appelle des « secrets à haute confiance », ce qui a un faible taux de faux positifs.

La protection push a deux objectifs. Tout d’abord, il empêche les secrets d’entrer dans le code. Deuxièmement, il vise à sécuriser le code sans perturber l’expérience du développeur. Les alertes sont intégrées à l’environnement de développement intégré (IDE) ou à l’interface de ligne de commande (CLI) du développeur. L’alerte peut contenir des recommandations pour résoudre le problème. Cette approche permet aux développeurs d’examiner les alertes et de supprimer les secrets de leur code avant de le pousser à nouveau. Si la correction suggérée ne fonctionne pas ou a du sens, le développeur peut aller de l’avant avec la poussée en résolvant le secret en tant que cas de test ou faux positif. Ou il ou elle peut le marquer comme une instance réelle, mais résoudre le problème plus tard.

Un développeur peut contourner la protection push. Cependant, dans ce cas, GitHub crée une alerte de sécurité fermée. Si le développeur a signalé un secret comme quelque chose à traiter ultérieurement, GitHub génère une alerte de sécurité ouverte afin que le développeur et l’administrateur du référentiel puissent collaborer à la correction lorsqu’ils sont prêts à résoudre le problème.

Pourquoi la protection push est un gros problème ?

Il peut sembler que la protection push ne soit pas une avancée majeure dans AppSec. Il s’agit d’une fonctionnalité incrémentielle qui s’ajoute aux capacités d’analyse secrète existantes de GitHub. Cependant, il s’agit d’un développement important car il fait passer la protection du code d’une protection réactive à une protection proactive. Désormais, au lieu d’attendre que les analyses du code publié révèlent la présence de secrets, les développeurs peuvent connaître les secrets avant de les valider et de les mettre en production. Cela rend le code plus sécurisé.

La protection push de l’analyse secrète donne déjà des résultats. Depuis sa version bêta en avril 2022, lorsqu’elle a été mise à la disposition des utilisateurs de GitHub Advanced Security, la protection push a empêché 17 000 fuites secrètes potentielles. Cela a permis d’économiser plus de 95 000 heures qui auraient été consacrées à la révocation, à la rotation et à la correction des secrets exposés.

Conclusion

La fuite d’un secret expose les applications à des risques. Les méthodes réactives existantes pour détecter et remédier aux fuites secrètes étaient déficientes. Elles n’étaient pas alignées sur la façon dont les développeurs travaillaient, et ils laissaient trop de temps s’écouler entre la découverte d’une fuite et sa correction, si une telle correction se produisait un jour. GitHub a compris que les développeurs devaient faire partie de la solution, être habilités à gérer les secrets, mais d’une manière qui n’affecterait pas négativement leur productivité ou leur expérience globale. La protection push de l’analyse de secret est la solution. Elle permet une détection proactive et la correction des secrets divulgués.

Suridata s’assurera que votre installation GitHub est configurée pour activer la nouvelle fonctionnalité de protection push. Pour plus d’informations, contactez-nous

Réserver une démonstration