Leçons de sécurité avec un Snyk Ambassador

Par Andres Haro, ambassadeur Snyk

La sécurité préoccupe le secteur technologique depuis des années. Pourtant, de nombreuses entreprises ne respectent pas leurs propres protocoles ou guides lorsqu’il s’agit de sécuriser leur code.

On peut facilement croire que les incidents de sécurité sont rares (ou qu’ils risquent peu de se produire dans sa propre organisation). Pourtant, le récent incident chez Uber n’est qu’un exemple parmi tant d’autres. Un jeune de 18 ans a eu recours à l’ingénierie sociale pour convaincre un employé d’Uber de se connecter à un faux site Uber. Il a ainsi pu récupérer les identifiants saisis en temps réel et se connecter au véritable site Uber.

La fuite de données chez Uber : enseignements à retenir

À l’époque, Uber avait activé l’authentification multifacteur (MFA) : une application invitait l’employé à appuyer sur un bouton de son smartphone au moment de la connexion. Pour contourner cette protection, le pirate a saisi plusieurs fois les identifiants sur le véritable site. L’employé, confus ou fatigué, a fini par appuyer sur le bouton. À ce moment-là, le pirate avait déjà réussi à se connecter.

Imaginez maintenant qu’Uber n’ait rien pu faire. Malgré la MFA, un utilisateur malveillant a fait preuve d’assez d’ingéniosité pour obtenir des informations personnelles de l’entreprise et causer des dégâts. Imaginez ce qui aurait pu se passer si l’entreprise n’avait pas pris de mesures pour sécuriser son code.

Comment protéger votre code ?

Si vous faites partie de la communauté tech, vous consultez probablement Stack Overflow assez souvent pour trouver du code open source et des réponses à vos questions. C’est un excellent outil de collaboration et de résolution de problèmes, mais copier directement dans votre application du code provenant d’un site tiers peut vous exposer à de nombreuses vulnérabilités potentielles.

Pour éviter ces risques potentiels, je vous recommande d’utiliser l’outil Code Checker de Snyk pour analyser le code de votre choix avant de le copier dans une branche de votre environnement de production.

Vous vous demandez peut-être ce que Snyk peut vous apporter. En plus de vous aider à analyser le code issu de n’importe quelle plateforme, Snyk vous indique les problèmes potentiels dans vos dépôts actuels et vous conseille sur la façon de les corriger.

Comme vous pouvez le voir sur l’image ci-dessous, Snyk est connecté à mon compte GitHub.

En connectant Snyk à votre compte GitHub, vous pourrez vérifier quelles dépendances ne sont pas à jour, ce qui corrompt votre code et quels éléments doivent être mis à jour.

L’image suivante présente un rapport Snyk qui répertorie les vulnérabilités détectées lors de l’analyse et les classe selon leur gravité : faible, moyenne, élevée ou critique. Vous disposez alors de toutes les informations nécessaires pour décider d’ignorer ou de corriger chaque vulnérabilité.

En tant que spécialiste DevSecOps, je donne toujours la priorité aux vulnérabilités critiques et j’encourage les équipes à consulter le tableau de bord pour déterminer si elles peuvent les corriger immédiatement. Pourquoi ? Parce que vos ingénieurs logiciels devront être informés des vulnérabilités détectées et vérifier s’ils ont le temps de les corriger dans leur sprint en cours. À l’inverse, certaines équipes choisissent de corriger les vulnérabilités élevées ou critiques le jour même de leur découverte. Tout dépend des ressources et du personnel dont dispose votre organisation. Snyk est particulièrement utile, car il prend en charge ces deux approches : vous pouvez corriger une vulnérabilité plus tard ou créer immédiatement une pull request (PR).

Si vous cliquez sur « Corriger cette vulnérabilité », voici ce qui s’affiche :

L’écran Créer une PR de correction répertorie toutes les vulnérabilités détectées lors de l’analyse et peut susciter des questions précises. Pour en savoir plus sur un problème de la liste des PR, cliquez sur l’une des vulnérabilités. Dans cet exemple, nous allons cliquer sur « Déni de service par expression régulière (ReDoS) » dans la section Problèmes avec une correction.

Vous obtenez alors une analyse détaillée du problème. S’il s’agit d’un faux positif ou d’une détection erronée, vous pouvez le signaler en cliquant sur « Vous avez repéré une erreur ? ». Vous accéderez à un autre écran où vous pourrez fournir des précisions.

Si vous ne connaissez pas une vulnérabilité, vous pouvez en apprendre davantage sur Snyk Learn. Pour reprendre notre exemple, consultez la page des leçons sur ReDoS.

Une fois mieux informés et plus confiants, nous pouvons créer la PR. Voici à quoi elle devrait ressembler dans GitHub :

Vous pourrez ensuite fusionner la nouvelle PR et la nouvelle branche contenant toutes les corrections.

Si vous choisissez de fusionner, voici ce qui s’affiche :

Pour savoir ce qui a changé dans votre dépôt, consultez les fichiers modifiés dans GitHub :

Comme vous pouvez le constater, certaines mises à jour étaient nécessaires pour rester à jour. Vous pouvez maintenant retourner au tableau de bord Snyk et vérifier si tout a été corrigé. Si vous devez envoyer un rapport à la direction, je vous conseille d’ajouter les personnes concernées à votre compte Snyk et de partager ce type de rapport avec elles.

Développez votre expertise en sécurité avec Snyk

Pour en savoir plus sur la sécurité des développeurs, consultez Snyk Learn : vous y trouverez de nombreuses leçons interactives sur les vulnérabilités dans divers langages et écosystèmes. Vous préférez les vidéos ? Rendez-vous sur la chaîne YouTube officielle de Snyk. Si vous avez besoin de conseils en sécurité, n’hésitez pas à contacter les Snyk Ambassadors : ce sont des personnes formidables qui possèdent une vaste expertise en cybersécurité, et le groupe ne cesse de s’agrandir !