Ces dernières semaines ont été particulièrement difficiles. L'ordinateur portable d'un développeur a été à l'origine du plus gros vol de l'histoire des cryptomonnaies chez Binance. LiteLLM a de nouveau été compromis sur PyPI. Les failles PHP2Shell et Node2Shell ont touché PHP et Node.js, qui, à eux deux, font tourner une part considérable du Web. Et n'oublions pas eMudhra et ces clés privées qui pouvaient être récupérées en quelques secondes.
Ces incidents reposaient sur des techniques bien connues et ne faisaient preuve que de très peu de sophistication. Les pirates ont toutefois agi rapidement, et le délai entre la divulgation et l'exploitation se réduit à vue d'œil. Pour certaines vulnérabilités, ce délai est déjà écoulé.
Les équipes doivent partir du principe qu'un ordinateur portable, un fournisseur, un progiciel ou un exécuteur d'infrastructure de continuité (CI) de leur parc sera compromis à un moment ou à un autre. Lorsque cela se produit, l'ampleur des dégâts dépend de la portée de l'attaque.
Vous trouverez ci-dessous six mesures que nous vous recommandons d'adopter pour assurer votre sécurité jusqu'à la fin de l'année 2026.
Rendre les identifiants volés inutilisables
Nous avons constaté l'ampleur des dégâts que peuvent causer des identifiants volés entre les mains de pirates ; il est donc primordial de limiter la portée des répercussions dès qu'un identifiant est compromis. La plupart des équipes n'ont pas prévu de plan d'action pour le cas où leurs identifiants seraient effectivement volés. Partir du principe qu'ils seront compromis facilite la mise en place des mesures de contrôle compensatoires appropriées.
Concrètement, cela signifie :
- Utilisez des jetons à durée de vie limitée ou un accès « juste à temps » (JIT), afin qu’un service ou une personne n’ait accès à un secret que pendant la durée nécessaire à la réalisation de la tâche. Si ces identifiants sont compromis, leur durée de validité est déjà presque arrivée à terme ou a déjà expiré.
- Limitez strictement les périmètres d'accès. Si un service n'a besoin que d'un accès en lecture, ne lui accordez pas également un accès en écriture.
- Rendez l'authentification à trois facteurs obligatoire sur tous les outils. Activez l'authentification à deux facteurs (2FA) partout où cela est possible. Par exemple, imposez l'authentification à deux facteurs sur GitHub et ajoutez des restrictions d'adresse IP.
- Passez en revue vos applications afin d'identifier toutes les clés API et tous les jetons qui ont été émis. Déterminez à quelles fins ils sont utilisés. Assurez-vous de bien comprendre leur champ d'application. Révoquez ceux qui ne sont pas nécessaires ou profitez de cet audit pour élaborer un plan de rotation des identifiants.
Sécurisez le code que vous n'avez pas écrit
PHP2Shell a clairement mis en évidence à quel point le code dont on hérite comporte des risques. Les images de base et les bibliothèques open source s'accompagnent de leurs propres aléas, tout comme les environnements d'exécution sous-jacents. Vous en devenez responsable dès l'instant où ce code intègre votre infrastructure. Vous ne pouvez pas éviter d'hériter de code, mais vous pouvez choisir ce dont vous héritez et comment.
En pratique :
- Commencez par des images de conteneurs minimalistes. Elles contiennent bien moins de paquets que les images standard, ce qui se traduit par une surface d'attaque réduite et, par défaut, un nombre moindre de vulnérabilités CVE.
- Associez des images minimalistes à un fournisseur d'images de conteneurs sécurisées, afin que toute vulnérabilité CVE détectée soit corrigée rapidement.
- Créez des fork ou des miroirs de bibliothèques en interne et utilisez-les depuis votre propre flux.
- Utilisez des bibliothèques « hardened » pour les dépendances en fin de vie, ou chaque fois que vous avez besoin d'un support étendu tout au long du cycle de vie, avec des correctifs de sécurité rétroportés.
- Identifiez les produits en fin de vie en vérifiant si votre parc contient des versions qui ne sont plus prises en charge.
- Utilisez analyse de la composition logicielle (SCA) pour suivre toutes les dépendances open source, y compris les dépendances transitives, ainsi que pour signaler et corriger les vulnérabilités détectées.
- Appliquez les correctifs dès la publication d'informations critiques. Les failles sont désormais exploitées quelques jours seulement après leur divulgation.
Supprimez les fournisseurs dont vous n'avez pas besoin
La prolifération des fournisseurs est bien réelle, et chaque fournisseur que vous intégrez à votre organisation représente un risque s’il n’est pas correctement géré. Ce plugin GitHub que vous avez installé l’année dernière et que vous n’avez utilisé qu’une seule fois ? C’est un risque. Il en va de même pour la dépendance npm que vous avez installée pour un projet que vous avez depuis abandonné. Le terme « fournisseurs » désigne toute entité dont le code ou les services s’exécutent au sein de votre infrastructure, qu’il s’agisse d’entreprises que vous rémunérez ou de responsables de projets open source.
En pratique :
- Constituez un inventaire bien géré de toutes les applications, extensions, intégrations et services présents dans votre environnement.
- Supprimez les fournisseurs tiers dans la mesure du possible. Pour ceux que vous conservez, mettez en miroir ou redirigez leurs services via votre propre source d'artefacts.
- Limitez au strict minimum les extensions et les plugins de l'IDE.
- Répertoriez toutes les autorisations OAuth, toutes les applications GitHub, tous les jetons d'accès personnels et toutes les intégrations SaaS connectées, puis révoquez celles que vous n'utilisez pas.
- Évaluez chaque fournisseur avant de l'intégrer à votre système. Demandez qui en assure la maintenance et de quels droits d'accès il a besoin, puis vérifiez si l'un de vos outils existants remplit déjà la même fonction.
- Les prestataires externes sont immédiatement remerciés dès la fin d'un projet ou l'expiration d'un contrat.
- Intégrez des scénarios de violation de sécurité chez vos fournisseurs à votre plan d'intervention en cas d'incident et testez-les. Imaginez qu'un de vos fournisseurs soit victime d'une violation de sécurité, puis simulez la réaction de votre équipe.
Mettez hors ligne ce qui n'a pas besoin d'être en ligne
PHP2Shell a montré que les équipes doivent justifier chaque service qu'elles maintiennent en ligne et identifier rapidement les processus en cours d'exécution sur l'ensemble de leur infrastructure.
Ce serveur web oublié datant de 2019, celui qui « n'était censé fonctionner que pour des travaux de développement internes », est exactement le genre de ressource informatique non mise à jour que ciblent les attaquants. Souvent, les équipes ne découvrent son existence que lorsqu'il est trop tard.
En pratique :
- Faites un état des lieux de votre parc informatique, y compris de votre surface d’attaque externe, et dressez un inventaire de tous les services et systèmes en fonctionnement.
- Examinez attentivement cette liste et soyez prêt à justifier la présence de chaque élément.
- Assurez la traçabilité des ressources en attribuant à chacune d'elles un responsable et un objectif. Attribuez également des étiquettes aux environnements et imposez cette pratique par le biais d'une politique.
- Évitez de connecter les systèmes à l'Internet public, sauf si cela s'avère nécessaire. Protégez les outils internes à l'aide d'un VPN ou d'un système d'accès « zero-trust ».
- Entraînez-vous bien à votre procédure de correction, afin d'être prêt lorsque des informations critiques seront rendues publiques.
- Utilisez des programmations d'arrêt automatique afin que les ressources informatiques ne soient actives que lorsque cela est nécessaire. Un cluster Kubernetes de développement que vous n'utilisez que le mardi peut être arrêté le reste de la semaine, ce qui vous permettra également de réduire votre facture.
Contrôler ce qui s'exécute sur les ordinateurs des utilisateurs
Les attaques de logiciels malveillants contre les appareils se multiplient, et en une seule semaine ,Aikido en a bloqué près de 500. Les machines des développeurs constituent une cible de choix, car elles contiennent des identifiants et permettent d’accéder à des systèmes parfois critiques. Les sections ci-dessus expliquent comment limiter les actions possibles avec ces identifiants, et le fait de contrôler ce qui s’exécute réellement sur les machines des développeurs réduit encore davantage la surface d’attaque. La faille de sécurité subie par Vercel cette année nous a également montré comment une simple extension de navigateur peut être à l’origine d’un incident.
Concrètement, cela signifie :
- Effectuer un audit des postes de travail des utilisateurs et dresser un inventaire des logiciels installés et de leurs versions, y compris les extensions de navigateur, les extensions IDE, les serveurs MCP et les outils d'IA.
- Bloquer l'installation de nouveaux plugins et extensions jusqu'à ce qu'ils aient été approuvés.
- Tenez à jour une liste blanche pour que les utilisateurs n'aient pas à attendre pour les adresses courantes.
- Imposer un délai minimum avant l'installation d'un paquet, ou « délai de sécurité ». La plupart des paquets malveillants sont détectés en l'espace de quelques heures ; ce délai de sécurité réduit donc le risque d'installer une version malveillante.
- Ne stockez pas vos secrets sur le disque dur. Les programmes de vol d'informations recherchent en priorité les jetons en clair dans les fichiers .env et l'historique du shell. Les gestionnaires de secrets et les jetons à durée de vie limitée sont vos alliés dans ce cas.
Commence par t'attaquer toi-même
« Vérifiez par vous-même avant de vous mettre dans le pétrin » : voilà un conseil de sécurité avisé. Réalisez des tests d'intrusion sur votre réseau et automatisez les tests simulant les attaques sur l'ensemble des services que vous gérez, afin de détecter les failles avant que quelqu'un d'autre ne le fasse.
Réparer une fuite avant qu'elle ne se transforme en inondation, cela semble évident, mais le faites-vous vraiment ? Les outils automatisés facilitent la tâche. En pratique :
- Déployez des outils de gestion des actifs ( gestion de la surface d’attaque , ASM) sur l'ensemble de votre parc informatique afin d'identifier tous les éléments exposés, y compris ceux dont vous aviez oublié l'existence.
- Effectuez régulièrement des tests d'intrusion sur le réseau externe, et pas seulement une seule fois.
- Testez en continu les applications dont les mises à jour sont fréquentes, plutôt que de considérer les tests comme une simple formalité à accomplir une fois par an.
- Simulez une intrusion à l'aide d'exercices sur table et testez ce qu'un attaquant pourrait réellement obtenir à partir d'une machine compromise ou d'un exécuteur de CI.
Liste de contrôle complète
Préparez votre équipe étape par étape.
Cette semaine
- Recherchez sur les machines des développeurs les identifiants d'cloud , les clés SSH, les jetons API et les fichiers .env.
- Définissez un délai minimum de 48 heures pour chaque gestionnaire de paquets que vous utilisez, y compris npm et PyPI.
- Commencez à bloquer les logiciels malveillants dès leur installation grâce à Safe Chain d'Aikido .
- Vérifiez ce qui est accessible depuis Internet et mettez hors ligne tout ce qui n'a pas besoin d'y figurer.
Ce mois-ci
- Transférez les secrets de production des ordinateurs portables vers un gestionnaire de secrets, et procédez à la rotation des identifiants que vous avez trouvés sur les machines des développeurs.
- Vérifiez les dépendances et supprimez celles qui ne sont pas utilisées ou qui ne sont plus mises à jour.
- Créez un inventaire des fournisseurs qui recense vos applications, vos plugins, vos dépendances et vos services, et attribuez un responsable à chacun d'entre eux.
- Définissez des plannings d'arrêt automatique pour les ressources de calcul hors production.
- Retirez les droits d'administrateur local sur les postes des utilisateurs lorsque cela est possible.
- Exécutez « analyse de code par IA » sur le code exposé à Internet et sur le code qui gère l'authentification ou les paiements.
- Enregistrez le fournisseur d'identité, l'audit d'cloud , le contrôle de version et les journaux d'intégration continue dans un emplacement où les identifiants de production ne peuvent pas les supprimer.
- Fixer un délai de correction pour les vulnérabilités critiques exposées à Internet, exprimé en heures ou en jours.
Avant la fin de l'année 2026
- Déployez « gestion de la surface d’attaque » sur l'ensemble de votre parc informatique.
- Réalisez un test d'intrusion réseau externe et réservez le prochain pour 2027.
- Organisez des exercices de simulation qui envisagent une faille due à un fournisseur compromis, à l'ordinateur portable d'un développeur, à un exécuteur de CI ou à un progiciel.
- Procédez à un bilan de fin d'année de l'ensemble de vos fournisseurs et de vos stocks de services, afin que chaque article ait un responsable à l'aube de l'année 2027.
Pour en savoir plus, consultez les bonnes pratiques de l'sécurité de la chaîne d’approvisionnement logicielle .
Conclusion
De nouvelles vulnérabilités (CVE) et de nouveaux paquets compromis continueront d'apparaître jusqu'à la fin de l'année, et bien au-delà. Partez du principe que vous serez touché à un moment ou à un autre, et assurez-vous d'être dans la meilleure position possible lorsque cela se produira. Les équipes qui limitent la portée d'une seule intrusion parviendront à contenir le prochain incident plus rapidement que celles qui s'attachent à bloquer tous les points d'entrée.
Pour une perspective à plus long terme, lisez « PHP2Shell », après-demain.
