Sommaire
- Plus de 500 000 nouveaux paquets malveillants recensés
- Les défis des composants tiers
- La problématique des mises à jour
- Napper les pièges du développement : un défi constant
- Les nouvelles menaces et leur portée
- Exemples d’attaques récentes
- La clé : une gestion rigoureuse des vulnérabilités
- Des sources d’information souvent peu fiables
- L’importance et limites du SBOM
- Conclusion : un appel à l’action pour les développeurs
Plus de 500 000 nouveaux paquets malveillants recensés
Selon un rapport récent de Sonatype, spécialiste de la gestion de la chaîne d’approvisionnement en logiciels, le nombre de logiciels malveillants dans l’écosystème open source est en hausse de manière alarmante. En effet, si on compte depuis novembre 2023, plus de 500 000 nouveaux paquets malveillants ont été identifiés dans les registres les plus utilisés tels que Java, JavaScript, Python et .NET. Un chiffre qui représente plus de 70% des 700 000 paquets malveillants suivis par Sonatype depuis 2019.
Les défis des composants tiers
Cette crise des logiciels malveillants renforce les difficultés rencontrées par les développeurs intégrant des composants open source dans leurs applications. En moyenne, chaque application d’entreprise utilise près de 180 composants tiers, un volume qui rend leur gestion complexe. Par ailleurs, 80% des applications vulnérables ne reçoivent pas de mises à jour dans l’année suivant leur découverte, malgré la possibilité de remédier à presque toutes (95%) ces vulnérabilités avec des alternatives sécurisées.
La problématique des mises à jour
Un exemple révélateur est celui de Log4j, dont la vulnérabilité Log4Shell, découverte en décembre 2021, continue de poser problème. Près de 13% des téléchargements de Log4j depuis Maven Central concernent encore des versions vulnérables, même trois ans après la découverte de la faille. Sonatype alerte donc sur la nécessité d’optimiser les politiques de sécurité pour mieux gérer ces menaces.
Napper les pièges du développement : un défi constant
Les logiciels malveillants se déclinent en plusieurs catégories et leurs impacts varient considérablement. Près de la moitié des nouveaux paquets malveillants sont classés comme applications potentiellement indésirables (PUA : potentially unwanted applications). Ces dernières, bien que peu nocives, soulèvent des préoccupations sur la transparence à destination des utilisateurs. En parallèle, 12% des paquets ont été signalés comme malveillants et remplacés par des composants sûrs pour attirer l’attention.
Les nouvelles menaces et leur portée
Les conséquences peuvent être plus graves pour la chaîne d’approvisionnement logicielle : 14% des paquets malveillants sont des tentatives d’hameçonnage, faisant passer de faux composants pour des paquets internes. De plus, certains sont conçus pour voler des données sensibles, compromettant ainsi la sécurité des entreprises.
Exemples d’attaques récentes
Certaines attaques récentes illustrent ce danger : un développeur a téléchargé 14 000 faux paquets sur NPM pour profiter d’incitations à la contribution open source, tandis que d’autres ont utilisé le typosquatting pour propager des malwares à travers des noms de paquets trompeurs.
La clé : une gestion rigoureuse des vulnérabilités
Sonatype estime qu’en moyenne, chaque application d’entreprise hérite de 13 vulnérabilités graves chaque année. Il est donc impératif de disposer d’outils capables d’identifier efficacement les dépendances et les failles potentielles.
Des sources d’information souvent peu fiables
Le rapport souligne que certaines bases de données, comme la National Vulnerability Database (NVD), affichent un arriéré de plus de 17 000 vulnérabilités à résoudre. Cela signifie que les entreprises peuvent passer à côté de vulnérabilités critiques ou prendre des décisions erronées quant à leur gravité initiale.
L’importance et limites du SBOM
L’utilisation d’un inventaire logiciel, ou SBOM (Software Bill of Materials), faciliterait la gestion des dépendances et la détection de vulnérabilités. Sonatype rappelle que les projets utilisant un SBOM pourraient réduire le temps de résolution des problèmes de 264 jours en moyenne. Cependant, malgré une adoption croissante des normes SBOM, seulement 61 000 sur les 7 millions de nouveaux composants open source publiés au cours de l’année écoulée étaient dotés d’un SBOM.
Conclusion : un appel à l’action pour les développeurs
À l’heure où la quantité de logiciels malveillants continue d’augmenter, il est crucial pour les organisations de renforcer leurs politiques de sécurité et d’optimiser leurs outils de gestion des dépendances. Les défis sont grands, mais une approche proactive peut faire la différence dans la sécurisation de l’écosystème open source.