Pas le temps de tout suivre ?
On l’a fait pour vous. Voici l’essentiel de l’actualité tech à ne pas manquer.
Écrit par Laurent Meunier
Le nouveau Top 10 de l’OWASP est sorti en fin d’année 2025. Ce Top 10 a pour but de fournir une liste des dix risques de sécurité les plus critiques pour les applications web. Sans connaître de gros changements, cette révision 2025 comporte néanmoins quelques ajustements.
La catégorie Broken Access Control reste en tête du classement, et elle est rejointe par la catégorie Security Misconfiguration qui passe de la cinquième à la deuxième place.
L’ancienne catégorie Vulnerable and Outdated Components est renommée en Software Supply Chain Failure. Le périmètre de cette catégorie s’étend pour englober les vulnérabilités liées aux dépendances, aux systèmes de builds et de distributions. Ce type d’attaque est devenu plus courant ces dernières années (comme cela a été le cas dernièrement avec plusieurs paquets NPM compromis) et il est normal que ces menaces soient prises en compte dans le Top 10 OWASP.
La catégorie Injection, regroupant les attaques par injections SQL ou attaques Cross-site scripting (XSS), descend dans le classement. Type d’attaque plutôt fréquent il y quelques années, cette catégorie est passée de la première place en 2017, à la troisième en 2021 et se retrouve en cinquième position en 2025. La sensibilisation auprès des équipes de développement a porté ses fruits, les développeurs sont désormais bien équipés entre l’usage de bibliothèques adaptées et d’outils de tests performants.
Côté nouveauté, on peut noter l’apparition d’une nouvelle catégorie Mishandling of Exceptional Conditions. Cette catégorie se focalise sur les vulnérabilités liées à une mauvaise gestion des erreurs et à des conditions d’exécution anormales rencontrées par les applications.
Pour conclure, une mise à jour du Top 10 est toujours la bienvenue. Les applications et les attaques ont évolué au cours de ces quatres dernières années. Cette mise à jour est donc importante pour les équipes de développement car celles-ci doivent constamment rester informées des nouveautés et doivent s’adapter face aux nouveaux types de menaces, et ce Top 10 répond parfaitement à ce besoin.
# Quis custodiet ipsos custodes ? Mais qui garde les gardiens ?
Écrit par Thomas Broyer
Le 1er mars, le projet GitHub de Trivy (un scanneur de vulnérabilités) est victime d’une attaque : une pull request déclenche un workflow GitHub Actions avec des permissions relativement élevées, mais ce workflow tire sa définition du code proposé par l’attaquant en pull request, ce qui permet à celui-ci d’avoir accès aux secrets du projet. Ces secrets seront ensuite utilisés pour compromettre complètement le projet : renommage et passage du projet en accès privé, création d’un nouveau projet vierge à la place, suppression de toutes les releases, et publication d’une version vérolée de l’extension VSCode dans la marketplace Open VSIX (utilisée notamment par VSCodium, la version pleinement open source de VSCode).
Aqua Security (l’entreprise qui développe Trivy) réagit promptement en coupant les accès frauduleux (révocation des secrets), en restaurant le projet en accès public, ainsi que ses releases, et en supprimant l’extension VSCode.
À peine 3 semaines plus tard, un des secrets récupérés lors de la première attaque (c’est en réalité plus compliqué que ça) permet à l’attaquant de créer une nouvelle release contenant du code compromis. Mais il ne s’arrête pas là : il a vraisemblablement accès à toute l’organisation GitHub et en profite donc pour attaquer les projets connexes trivy-action et setup-trivy pour leur faire télécharger cette nouvelle version vérolée. Celle-ci va récupérer tous les secrets possibles pour les exfiltrer. Le but ici est donc de ratisser large en passant sous les radars pour attaquer les utilisateurs de Trivy.
La façon dont l’attaquant a pu mettre la main sur ce secret n’est pas encore clair : Aqua Security avait pourtant visiblement fait le ménage complet lors de la première attaque. Une piste serait que les révocations n’aient pas été atomiques, et que l’attaque ait pu alors récupérer le nouveau secret pendant qu’il avait encore accès au projet.
À nouveau, Aqua Security supprime rapidement la release compromise, mais le lendemain l’attaquant arrive encore à pousser de nouvelles versions… de l’image Docker cette fois !
À Atol, nous utilisons Trivy (bien que nos automatisations reposent plutôt sur Syft et Dependency Track), mais n’avons pas été compromis parce que nous nous sommes protégés contre ce type d’attaques : pour une application qui potentiellement accède au daemon Docker (pour analyser des images), et a donc virtuellement un accès root sur la machine, nous avions décidé de construire nos propres images Docker, en téléchargeant les binaires depuis les releases GitHub avec une vérification du checksum pour éviter toute compromission. Nous avons bien un mécanisme automatisé pour mettre à jour notre image, mais il requiert une approbation manuelle.
Lors de la première attaque, la reconstruction hebdomadaire de notre image (pour mettre jour l’image de base) avait échoué parce que la release n’existait plus (ce qui nous avait alors alerté sur l’attaque en cours, avant même la communication officielle d’Aqua Security). Lors de cette seconde attaque, c’est notre processus automatisé de mise à jour qui a échoué et nous a alerté (cette fois-ci parce qu’Aqua Security avait déjà supprimé la release compromise, entre le moment où notre workflow l’a initialement vue, et le moment où il a voulu récupérer le nouveau checksum pour mettre à jour notre image).
Laisser un commentaire