Corriger un demi-million de vulnérabilités de sécurité

Les hackathons sont réputés au sein des équipes de développement logiciel pour stimuler l’innovation et la collaboration. Et si nous appliquions ce modèle à la cybersécurité afin d’améliorer la posture de sécurité des applications d’une organisation ? Ce serait un rêve devenu réalité pour tout RSSI et professionnel de la sécurité — et c’est exactement ce que nous avons entrepris chez Snyk en février 2023.

Découvrez quelques-uns des moments les plus drôles de nos tables rondes.

Notre mission : corriger 200 000 vulnérabilités de sécurité. Voici comment cela s’est passé.

Organiser un hackathon dédié à la correction des vulnérabilités

Pour qu’un événement soit une réussite, il est essentiel que les développeurs et les professionnels de la sécurité prennent plaisir à apprendre de nouvelles compétences qu’ils pourront mettre en pratique dans leurs projets personnels ou professionnels. Dans cette optique, nous avons mis en place les éléments suivants :

1. Grâce à un accompagnement continu, les participants au hackathon sont invités à rejoindre leurs pairs dans la communauté Discord de Snyk pour suivre des formations en sécurité et obtenir de l’aide pour corriger les vulnérabilités.

2. Une diffusion en direct de 24 heures, qui a tenu notre promesse de favoriser la formation, était au cœur du Big Fix de cette année. Nous avons organisé cette diffusion en direct de 24 heures à l’échelle mondiale sur YouTube et Twitch, avec des intervenants d’Atlassian, Dynatrace, Morgan Stanley, The Linux Foundation, Sysdig, AWS, StackHawk et d’autres entreprises.

3. Récompenses : nous voulions saluer les efforts de chaque participant pour créer des logiciels plus sécurisés. Ainsi, toute personne ayant corrigé au moins une vulnérabilité de sécurité a reçu un t-shirt The Big Fix en édition limitée ou un crédit de 15 $ sur OpenCollective, utilisable pour faire un don à des projets et à des responsables de la maintenance open source.

4. Classement : pour ajouter une touche de compétition, nous avons publié le classement des meilleurs correcteurs. Les trois participants ayant corrigé le plus de vulnérabilités de sécurité ont respectivement remporté un casque VR (1re place), une enceinte sans fil (2e place) et un kit de démarrage Arduino (3e place).

L’un des grands avantages du hackathon, c’est qu’il n’était pas nécessaire d’avoir une expérience préalable en sécurité des applications ou du cloud pour participer et grimper dans le classement.

C’est possible grâce à l’approche de Snyk qui place les développeurs au premier plan, à son riche écosystème d’intégrations et à ses capacités de correction automatisée, qui vous permettent de détecter et de corriger facilement les problèmes de sécurité. Que vous soyez développeur, ingénieur DevOps, spécialiste de la sécurité ou de l’assurance qualité, Snyk a les outils qu’il vous faut pour vous lancer.

C’est le moment idéal pour commencer avec Snyk Code, Snyk Open Source, Snyk Container et Snyk Cloud.

Sécuriser les logiciels du monde entier

Alors, quel est le bilan ? Maintenant que le Big Fix est terminé, analysons les données et passons en revue les résultats de cet événement qui a donné aux développeurs les moyens de corriger les problèmes de sécurité.

En un mois, les participants au Big Fix ont contribué 597 589 corrections de sécurité à leurs projets logiciels, qu’ils soient privés ou open source. Plus de 1 800 utilisateurs inscrits à l’événement nous ont rejoints. Parmi eux, on comptait plus de 120 employés de Snyk, plus de 220 clients et plus de 1 480 ingénieurs issus de différentes entreprises.

Nous avons analysé plus en profondeur la base de données Snyk afin de déterminer l’impact de l’événement sur la sécurité des projets surveillés avec Snyk. Les indicateurs et observations qui suivent présentent ainsi l’ensemble des données analytiques produit recueillies pour toute activité de compte associée à l’événement. Elles couvrent davantage de projets et de vulnérabilités détectées et corrigées que les seuls projets ajoutés au hackathon.

Les images de conteneurs sont les plus exposées aux vulnérabilités, mais aussi les plus faciles à corriger.

Parmi les millions de vulnérabilités de sécurité détectées dans les projets de conteneurs, de code et d’infrastructure surveillés avec Snyk, les projets classés comme conteneurs Docker affichaient un taux de correction de 73,3 %. Il est raisonnable de penser que ce taux élevé s’explique en grande partie par le fait que Snyk Container propose des corrections automatisées via des pull requests et recommande des images de base alternatives comportant moins de vulnérabilités.

Les actions de sécurité portant sur le code et les dépendances affichent un taux de correction relativement faible. Snyk Code a détecté plus de 82 160 vulnérabilités potentielles dans le code, dont 10,2 % ont été corrigées par les participants. Snyk Open Source, qui détecte les vulnérabilités publiquement connues dans les dépendances open source, a affiché un taux de correction de 14,4 %. Les corrections de dépendances étant automatisées via des pull requests et les problèmes de sécurité du code étant traités dans l’IDE grâce au moteur de recommandations de Snyk, des milliers de vulnérabilités ont été atténuées tôt — et rapidement — au cours du processus de développement.

Examinons de plus près les données sur les projets d’images de conteneurs. Les 10 principaux projets de conteneurs Docker surveillés par Snyk affichent un taux particulièrement élevé de correction des problèmes de sécurité, ce qui confirme l’affirmation précédente : ces problèmes sont bien plus faciles et rapides à corriger. Les distributions de base Ubuntu et les images de conteneurs telles que ubuntu:rolling et les images node affichent des taux de correction des problèmes de sécurité supérieurs à 90 %.

13 à 30 % des vulnérabilités de sécurité publiquement connues sont corrigées plus tôt et plus rapidement

En examinant de plus près les écosystèmes de langages, nous pouvons également observer les taux de correction appliqués à chaque langage de programmation. Ces chiffres peuvent être biaisés par la découverte de vulnérabilités présentant un faible niveau de risque, comme celles signalées dans les dépendances de développement. D’autres problèmes de sécurité peuvent être impossibles à corriger parce que les projets concernés ne sont plus maintenus. Dans l’ensemble, le taux de correction des vulnérabilités liées aux dépendances est d’environ 13 à 30 %. L’automatisation de ces corrections permet aux développeurs de logiciels de se concentrer sur la création d’applications plutôt que sur le traitement des problèmes de sécurité.

Le code Go est exposé aux attaques par déni de service et aux erreurs de codage sécurisé liées au flux de contrôle et aux pointeurs

Les principales vulnérabilités corrigées en Go montrent que les développeurs consacrent du temps à atténuer les erreurs de codage sécurisé liées au flux de contrôle des programmes, au déni de service et à la gestion des pointeurs. Voici les 5 principales vulnérabilités de sécurité corrigées dans les projets Go :

• CWE-400 : consommation incontrôlée de ressources

• CWE-266 : attribution incorrecte de privilèges

• CWE-787 : écriture hors limites

• CWE-674 : récursion incontrôlée

• CWE-476 : déréférencement d’un pointeur NULL

Les projets Python sont particulièrement exposés aux problèmes de mémoire, à la validation des entrées et au flux de contrôle des programmes

Les principaux types de vulnérabilités Python ressemblent à ceux des projets Go : consommation incontrôlée de ressources, écriture hors limites et lecture hors limites. Parmi les autres principales vulnérabilités détectées dans les bases de code Python, citons :

• CWE-369 : division par zéro

• CWE-617 : assertion atteignable

• CWE-1333 : complexité inefficace des expressions régulières

Les bases de code Java et JavaScript présentent les mêmes principaux types de vulnérabilités

Parmi les 10 principaux types de vulnérabilités surveillés pendant le Big Fix, nous avons identifié plusieurs CWE communes aux bases de code Java et JavaScript :

• CWE-400 : consommation incontrôlée de ressources

• CWE-94 : contrôle inadéquat de la génération de code (« injection de code »)

• CWE-22 : limitation inadéquate du chemin d’accès à un répertoire restreint (« traversée de répertoires »)

• CWE-200 : exposition d’informations sensibles à un acteur non autorisé

Ruby est particulièrement exposé aux dénis de service, aux scripts intersites et à la contrebande de requêtes HTTP

Ruby, surtout connu pour Ruby on Rails, est principalement associé au développement web. Il n’est donc pas surprenant que ses 5 principales vulnérabilités de sécurité, également corrigées pendant l’événement, concernent les applications web :

• CWE-1333 : complexité inefficace des expressions régulières

• CWE-400 : consommation incontrôlée de ressources

• CWE-79 : neutralisation inadéquate des entrées lors de la génération de pages web (« scripts intersites »)

• CWE-444 : interprétation incohérente des requêtes HTTP (« contrebande de requêtes/réponses HTTP »)

• CWE-200 : exposition d’informations sensibles à un acteur non autorisé

En fait, l’une des principales vulnérabilités détectées et corrigées par les participants est un problème de sécurité peu connu : la contrebande de requêtes HTTP.

Les vulnérabilités de sécurité les plus faciles à corriger sont détectées par les tests statiques des applications

Les tests statiques des applications s’appuient sur des informations au niveau du code et des flux d’exécution, comme les arbres syntaxiques abstraits, pour détecter les vulnérabilités potentielles et les pratiques de codage non sécurisées. Ils permettent de fournir rapidement des commentaires aux développeurs et de les alerter sur les problèmes de sécurité pendant qu’ils écrivent le code, plutôt qu’à une étape ultérieure, une fois les fonctionnalités développées.

Snyk Code fournit des informations de sécurité intégrées à l’IDE et des recommandations de correction que les développeurs peuvent facilement appliquer en installant l’extension VS Code (IntelliJ et d’autres IDE sont également pris en charge). Brian Clark et Nate Michalov montrent comment détecter et corriger les problèmes de sécurité dans cette session de programmation en direct :

Play Video: How to Get Started with Snyk Code (feat. Nate Michalov) - The Big Fix 2022 by Snyk

Parmi tous les problèmes détectés par l’outil SAST Snyk Code, les types de vulnérabilités suivants étaient les plus courants :

• ​​CWE-94 : contrôle inadéquat de la génération de code (« injection de code »)

• CWE-79 : neutralisation inadéquate des entrées lors de la génération de pages web (« scripts intersites »)

• CWE-916 : utilisation d’un hachage de mot de passe avec un effort de calcul insuffisant

• CWE-798 : utilisation d’identifiants codés en dur

• CWE-352 : falsification de requête intersite (CSRF)

Et maintenant ?

Nous tenons à remercier toutes les personnes qui ont participé au Big Fix cette année et à vous inviter à l’un de nos prochains événements publics. Vous pourrez en apprendre davantage sur la sécurité des applications et rencontrer d’autres professionnels de la cybersécurité :

• Atelier CTF 101 (25 mai 2023) : un atelier pratique pour apprendre à résoudre des défis de type capture du drapeau !

• Atelier de piratage éthique (21 juin 2023) : un atelier pratique pour apprendre à mener des opérations de piratage éthique et à divulguer les vulnérabilités de manière responsable.

• DevSecCon (27 juin 2023) : notre conférence communautaire phare consacrée à tout ce qui touche au DevSecOps.

Enfin, si vous souhaitez échanger avec des développeurs et des professionnels de la sécurité qui partagent vos centres d’intérêt, rejoignez le Discord DevSecOps.