Intel est notre flux de renseignements sur les menaces de sécurité open source alimenté par l'IA et notre équipe de recherche interne. Intel surveille et découvre les vulnérabilités dans les packages open source avant qu'elles ne soient divulguées. Beaucoup ne le sont jamais.
67 % des vulnérabilités logicielles corrigées en silence n'ont jamais été divulguées
Les logiciels open-source alimentent le monde, littéralement. Cependant, la sécurité open-source est également un domaine de préoccupation majeure en matière de sécurité. Les outils open-source, comme tout le reste, peuvent introduire des vulnérabilités de sécurité. Celles-ci peuvent être utilisées par les attaquants pour exploiter votre application, exposant les éditeurs de logiciels à des attaques sans qu'ils en soient responsables. Cela fait de la sécurité open-source un sujet très important.
Non seulement nous nous appuyons sur la communauté open source pour construire et maintenir ces outils, mais nous comptons également sur elle pour corriger toute vulnérabilité de sécurité connue. Il est important de noter que nous comptons également sur ces mainteneurs pour signaler publiquement les vulnérabilités lorsqu'elles sont découvertes. La divulgation publique des vulnérabilités par la communauté constitue le fondement de la sécurité open source.
Le patching silencieux, ou patching furtif, se produit lorsqu'un correctif de sécurité est appliqué (patché) mais jamais divulgué. C'est un problème majeur car cela signifie que les fournisseurs peuvent exécuter des logiciels vulnérables sans en être conscients du risque.
Nous lançons Aikido Intel pour révéler les logiciels patchés en silence qui pourraient vous affecter. Avec Aikido Intel, nous pouvons donner aux développeurs l'alerte la plus précoce possible si nous trouvons des vulnérabilités qui pourraient les affecter et améliorer la sécurité de l'open source.
Qu'est-ce qu'Aikido Intel ?
Aikido Intel est une initiative menée par l'IA + notre équipe de recherche interne pour améliorer la sécurité de l'open source en découvrant les vulnérabilités dans la chaîne d'approvisionnement open source le plus tôt possible, avant même qu'elles ne soient divulguées dans une base de données de vulnérabilités. Pour ce faire, nous utilisons des LLM entraînés sur mesure pour examiner les modifications des packages et identifier quand un problème de sécurité a été corrigé.
Comme tous les logiciels, l'open source tient un journal des modifications (change log) de ce qui a été ajusté à chaque nouvelle version. Intel utilise l'IA pour lire tous ces journaux de modifications et notes de version publics afin de trouver des exemples où des problèmes de sécurité ont été corrigés. Cela est ensuite comparé à 5 bases de données de vulnérabilités pour voir si le problème a été signalé. Si ce n'est pas le cas, nous demandons à un ingénieur en sécurité d'analyser et d'évaluer la vulnérabilité, en lui attribuant un numéro et une gravité Aikido Vulnerability, et en l'annonçant publiquement afin que vous sachiez si vous êtes affecté. Lisez plus de détails à ce sujet plus tard
Découvrez Aikido Intel maintenant
Aikido Intel en chiffres
Depuis son lancement en janvier, Aikido, Intel a découvert 511 vulnérabilités qui ont été corrigées mais non divulguées publiquement, présentant une réelle menace pour quiconque utilise ces packages.
Il peut parfois s'écouler un certain temps entre le correctif d'une vulnérabilité et l'attribution d'un numéro CVE au problème. Chaque semaine, Aikido réévalue le statut des vulnérabilités précédentes pour voir si un CVE leur a été attribué. Nous pouvons révéler que 67 % des vulnérabilités que nous avons découvertes n'ont jamais été divulguées publiquement à aucune base de données de vulnérabilités !
S'il n'est pas surprenant que les vulnérabilités de faible gravité soient plus fréquemment corrigées silencieusement, il est tout de même choquant que plus de 50 % des vulnérabilités élevées et critiques ne soient jamais divulguées. Cela crée un énorme angle mort pour les développeurs et les éditeurs de logiciels.
Je sais que certains d'entre vous se tortilleront sur leurs sièges en disant que ce sont peut-être de petits projets open source, peu populaires, avec des politiques de sécurité limitées, mais en réalité, vous auriez tort. Nous avons découvert des vulnérabilités non divulguées dans de très grands projets.
Axios, un client HTTP basé sur des promesses pour le navigateur et node.js avec 56 millions de téléchargements hebdomadaires et plus de 146 000 dépendances, a corrigé une vulnérabilité de pollution de prototype en janvier 2024 qui n'a jamais été divulguée publiquement.
Fait amusant à propos de cette vulnérabilité : C'était en fait la première vulnérabilité découverte par Aikido Intel (voir le numéro 2023-10001)… Elle reste non divulguée à ce jour !
Je ne veux pas leur donner le bâton pour se faire battre, Axios n'est pas seul, quelques autres noms méritent une mention spéciale. Apache a discrètement corrigé une vulnérabilité de type cross-site scripting dans le logiciel echarts qui n'avait jamais été divulguée.
Un autre exemple intéressant que nous avons découvert était une vulnérabilité critique de traversée de chemin dans Chainlit qui a été corrigée en septembre, mais la vulnérabilité n'a jamais été divulguée publiquement.
Les vulnérabilités les plus courantes
Le cross-site scripting était la vulnérabilité non divulguée la plus courante, représentant 14,8 %, suivie de l'exposition d'informations sensibles à 12,3 %. Au total, nous avons détecté 90 types de vulnérabilités différents, créant une longue liste de résultats, dont voici quelques-uns des plus courants.
Les vulnérabilités les plus courantes découvertes
Si nous nous concentrons uniquement sur les vulnérabilités critiques et élevées, nous pouvons voir une image légèrement différente, l'exécution de code à distance occupant la première place de la liste.
Les vulnérabilités les plus courantes découvertes - Critiques et Élevées uniquement
Délai de divulgation
Alors qu'au moment de la rédaction de cet article, 67 % des packages n'ont jamais divulgué leurs vulnérabilités, 31 % l'ont fait, que ce soit par les mainteneurs ou les chercheurs en sécurité (bravo à eux). Parmi les packages qui ont divulgué les vulnérabilités, il a fallu en moyenne 27 jours entre la publication du correctif et l'attribution d'un CVE. Le délai le plus rapide que nous ayons observé n'était que d'un jour et le délai le plus long était de 9 mois !
Comment Intel fonctionne (en détail)
Je sais que nous sommes tous fatigués du discours excessif sur la nouvelle IA, mais Intel est une initiative de l'équipe de recherche en sécurité d'Aikido et l'équipe d'IA d'Aikido s'appuie sur l'IA avec un humain dans la boucle pour fournir un flux de menaces public afin d'améliorer la sécurité open source.
Intel fonctionne en parcourant tous les journaux de modifications (changelogs) et notes de version (release notes) disponibles publiquement afin de déterminer si des correctifs de sécurité ont été apportés mais non divulgués. Pour ce faire, deux modèles LLM sont utilisés : l'un pour filtrer les données et supprimer tout contexte inutile, permettant au second LLM de se concentrer sur l'analyse des vulnérabilités. Un ingénieur en sécurité humain examine ensuite les découvertes du LLM, valide les résultats et publie une alerte Intel lorsqu'une vulnérabilité est confirmée.
C'est une méthode si efficace car elle consomme remarquablement moins de puissance de calcul que d'essayer de scanner tous ces systèmes à la recherche de vulnérabilités. Pourtant, elle a prouvé sur plus d'un an qu'elle trouve de nombreux résultats réels.
Comment Aikido Intel analyse les journaux de modifications (changelogs)
Les journaux de modifications sont des documents tenus dans les projets open source qui enregistrent les mises à jour, les corrections de bugs, les ajouts de fonctionnalités et les correctifs. Parmi les exemples figurent CHANGELOG.md fichiers, messages de commit et notes de version GitHub.
L'Intel LLM identifie les entrées suggérant des modifications liées à la sécurité en recherchant :
- Mots-clés : « vulnérabilité », « sécurité », « correctif », « exploit », « validation des entrées », etc.
- Indices contextuels : « Correction d'un bug critique », « Patch d'un dépassement de tampon », « Résolution de problèmes d'authentification ».
Exemples d'entrées signalées par le LLM :- Correction d'un problème de désinfection des entrées dans le gestionnaire de connexion.
- Résolution d'une fuite de mémoire pouvant entraîner des attaques par déni de service.
- Correction d'une vulnérabilité de traversée de chemin dans la fonctionnalité de téléchargement de fichiers.
Sécurité open-source : comment les vulnérabilités sont divulguées correctement
Comme indiqué précédemment, la divulgation publique est un élément majeur de la sécurité open source. Plusieurs bases de données sont utilisées pour divulguer les vulnérabilités logicielles. La principale est la National Vulnerability Database (NVD), maintenue par le gouvernement américain. Cette base de données est utilisée non seulement par les entreprises pour vérifier leur chaîne d'approvisionnement, mais aussi par les logiciels de sécurité qui comparent les projets à cette base de données et à d'autres (logiciels SCA). Il existe de nombreuses autres bases de données, notamment la Common Vulnerabilities and Exposures database (CVE) de Mitre, la GitHub Advisory Database, et bien d'autres ; au total, Aikido effectue des vérifications sur 5 bases de données différentes. Cependant, la plupart de ces bases de données ont en commun d'exiger que les vulnérabilités soient divulguées publiquement, généralement après la publication d'un correctif.
Pourquoi les vulnérabilités ne sont-elles pas divulguées ?
C'est une bonne question et je tiens à commencer par dire qu'il n'y a aucune bonne raison de ne pas divulguer les vulnérabilités. Le risque le plus courant est peut-être le risque de réputation, que votre logiciel soit considéré comme non sécurisé, mais je dirais qu'il y a beaucoup plus à perdre en ne divulguant pas qu'en divulguant.
Pourquoi le shadow patching est un problème pour la sécurité open source
Ne pas divulguer publiquement les vulnérabilités de votre logiciel crée un risque énorme pour vos utilisateurs. Comme le dit l'adage, si ce n'est pas cassé, ne le réparez pas, cela s'applique assez souvent aux logiciels.
La mise à jour des composants de votre logiciel peut souvent créer des problèmes de performance et d'utilisabilité, ou simplement casser votre application. Dans cette optique, il n'est pas toujours courant de mettre à jour immédiatement les packages dès qu'une nouvelle version est disponible.
Cependant, lorsqu'il y a un problème de sécurité dans un composant, il est important de le savoir car cela modifie l'urgence avec laquelle vous mettez à jour vos composants open source et tiers. Ne pas divulguer cette information signifie que les utilisateurs sont moins susceptibles de mettre à jour, ce qui implique qu'ils auront des failles de sécurité inconnues dans leurs outils, d'où le problème du patching furtif.
Ne laissez pas les vulnérabilités cachées compromettre votre sécurité.
Collaborez avec Aikido Security dès aujourd'hui pour protéger votre chaîne d'approvisionnement et avoir l'esprit tranquille.
Sécurisez votre logiciel dès maintenant.
