Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
L'IA est sur le point de prendre le pas sur la détection des failles logicielles, mais pas sur leur correction.
En avril 2026, Anthropic a annoncé le projet Glasswing aux côtés de onze partenaires majeurs, dont AWS, Apple, Cisco, Google, JPMorgan Chase, la Linux Foundation, Microsoft et Palo Alto Networks.
Cette initiative s'appuie sur Claude Mythos Preview, un modèle de pointe qui a déjà identifié des milliers de vulnérabilités à haut risque, notamment des failles présentes dans tous les principaux systèmes d'exploitation et navigateurs Web. Certaines de ces failles avaient échappé à des décennies de contrôles effectués par des humains, ce qui change la donne pour tous ceux qui commercialisent des logiciels comportant des composants open source.
Même si l'accès est pour l'instant limité, la tendance est claire : la détection des vulnérabilités devient plus rapide, moins coûteuse et de plus en plus automatisée – et elle ne restera pas l'apanage d'un petit groupe de spécialistes de la sécurité.
En matière de sécurité de la chaîne d'approvisionnement open source, tout se résume depuis toujours à une seule question : qui est chargé de corriger quoi, et dans quels délais. Depuis l'arrivée de Glasswing, la détection des vulnérabilités par l'IA évolue à la vitesse de l'ordinateur, tandis que l'application des correctifs suit toujours le rythme des calendriers.
Cette pression s'exerce sur deux aspects distincts du risque lié à l'open source : ce que l'on installe, et ce qui se passe ensuite. Le premier concerne la confiance dans le logiciel lui-même. Le second porte sur la question de savoir si les vulnérabilités sont un jour corrigées. Ces deux aspects sont sur le point d'être mis à l'épreuve, chacun à sa manière.
Et les autorités de régulation ont été claires : si vous commercialisez le logiciel binaire, vous êtes responsable du bug.
Le projet Glasswing et la vague de vulnérabilités CVE qui s'abat sur vos dépendances
Mythos Preview n'est pas un scanner plus rapide. Il analyse des bases de code complexes et génère des exploits fonctionnels, et non de simples résultats théoriques. Anthropic a restreint l'accès aux partenaires de Glasswing précisément parce que ces mêmes capacités risqueraient de tomber entre les mains d'attaquants. La marge de manœuvre des défenseurs est réduite, et la plupart des équipes n'ont pas encore revu leurs hypothèses.
Deux conséquences particulières revêtent une importance particulière pour les organisations qui s'appuient sur des logiciels libres.
Tout d'abord, le nombre de CVE va augmenter. Mythos a déjà mis au jour des milliers de failles dans des codes ayant fait l'objet d'audits rigoureux. Les bibliothèques open source destinées à la production qui n'ont jamais été soumises à un tel niveau de contrôle subiront le même sort à mesure que des modèles comparables se généraliseront sur le marché. La plupart des équipes de sécurité ont déjà du retard sur le traitement des CVE en attente.
Deuxièmement, le délai entre la divulgation et l'exploitation est réduit à néant. Un accord de niveau de service (SLA) prévoyant un délai de correction de 30 jours avait été établi en fonction du délai entre la publication d'un CVE et l'apparition d'un exploit fonctionnel correspondant. Mythos comble ce délai en une seule session.
Si votre stratégie de correction repose sur l'hypothèse d'un flux constant et gérable de CVE dans les paquets faisant l'objet d'une maintenance active, ces deux aspects de cette hypothèse sont sur le point de voler en éclats.
Pour résumer :
- La découverte des vulnérabilités s'accélère
- La création d'exploits s'accélère
- La vitesse de correction n'est pas
C'est dans cette faille que le risque s'amplifie.
Vous êtes responsable de toutes les dépendances que vous fournissez
Ce changement réglementaire a fait moins de bruit que l'annonce concernant l'IA, mais il n'en est pas moins déterminant.
En vertu de la loi européenne sur la cyber-résilience, les fabricants sont responsables de la sécurité des produits comportant des éléments numériques pendant toute la durée de leur support, y compris tous les composants open source intégrés. Les sanctions peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial. Le fabricant est l'entité qui met le produit sur le marché. Peu importe qui a écrit la dépendance, si le responsable de la maintenance est rémunéré ou si le projet en amont a été abandonné. Si vous le commercialisez, vous en assumez la responsabilité.
FedRAMP a évolué dans le même sens. Les fournisseurs de services cloud sont tenus d'assurer la sécurité de chaque composant relevant de leur périmètre d'autorisation, avec des processus de correction documentés et les logiciels en fin de vie signalés comme un problème d'autorisation connu. Dans le cadre de FedRAMP 20x, les SBOM correspondant à ce qui est réellement en exécution deviennent une exigence de base.
Les contrats clients ont également évolué. Les équipes chargées des achats exigent désormais des SBOM, des documents VEX et des SLA de correctifs comme éléments standard. « Nous utilisons une bibliothèque tierce » n'est pas une réponse valable lorsqu'une faille de sécurité touche l'environnement de production.
Le principe juridique est simple à résumer. La responsabilité dépend du système binaire, et non de la licence du code source. L'argument de la « surveillance collective » n'a jamais été valable sur le plan juridique, et depuis l'affaire Glasswing, il ne l'est plus non plus sur le plan technique.
L'open source comporte deux risques distincts
L'intégration de logiciels libres dans votre infrastructure comporte deux risques distincts. Le premier concerne l'intégrité de la chaîne d'approvisionnement : ce que contient réellement le paquet le jour où vous l'installez. Le second concerne les correctifs : la rapidité avec laquelle une vulnérabilité connue est corrigée, et ce qui se passe lorsqu'aucun correctif n'est prévu.
Il s'agit là de problèmes distincts, avec des modèles de menace différents. Les attaques de la chaîne d'approvisionnement relèvent d'un problème d'identifiants et de confiance. Glasswing n'a rien à voir avec elles, et celles-ci ne cessent de s'intensifier depuis des années, suivant leur propre trajectoire. C'est au niveau des correctifs que Glasswing change la donne, tant pendant la phase de maintenance active qu'après la fin de vie (EOL). C'est cette combinaison qui constitue la nouveauté. La même équipe de sécurité qui devait déjà faire face à un flux constant d'attaques de la chaîne d'approvisionnement doit désormais gérer un afflux plus rapide et plus important de CVE à travers l'ensemble de l'arborescence des dépendances.
La responsabilité civile ne se soucie pas de la nature du problème qui vous touche. Passons-les en revue un par un.
La menace dès le premier jour : les paquets compromis
Le premier risque lié à toute dépendance réside dans ce qu’elle contient au moment de son installation. Depuis des années, des artefacts altérés, des comptes de responsables détournés et des sites miroirs créés par typosquatting parviennent à se glisser dans les environnements de production via des installations provenant de registres qui semblent fiables.
Mars 2026 Axios est l'exemple récent le plus marquant : des identifiants ont été volés au principal responsable du projet, et un hook post-installation malveillant a été diffusé pendant trois heures à environ 100 millions de téléchargeurs hebdomadaires.
Parmi les autres cas récents, on peut citer le ver Shai-Hulud et l' incident lié à l'interface CLI de Bitwarden qui visait les identifiants d'un outil de codage basé sur l'IA.
Cette catégorie suit son propre chemin. Glasswing ne facilite ni ne complique les attaques visant la chaîne d'approvisionnement npm, et Mythos ne permet pas à un pirate de compromettre le compte d'un responsable de maintenance. Mais la menace ne cesse de s'intensifier depuis des années, uniquement sous l'effet des motivations des pirates, et dans le cadre de la CRA, elle relève de la même catégorie de responsabilité que tout autre élément que vous distribuez. La détection intervient plusieurs heures après les faits.
La prévention nécessite une source de paquets vérifiée, signée et recompilée à partir d'un code source vérifiable, plutôt que directement extraite d'un registre public.
La menace liée aux failles de sécurité non corrigées : vulnérabilités actives et fin de vie
Les attaques visant la chaîne d'approvisionnement portent sur la question de savoir qui contrôle le logiciel. Le délai de correction, quant à lui, concerne autre chose : la rapidité avec laquelle un bug connu, présent dans un paquetage authentique et non altéré, est corrigé dans le code que vous exécutez.
Ce problème se manifeste sous deux formes : des correctifs lents pour les bibliothèques maintenues, et l'absence totale de correctifs pour celles en fin de vie (EOL). Glasswing aggrave ces deux situations.
Quand les correctifs sont publiés après la découverte de failles
Le délai de correction varie considérablement au sein de l'écosystème. Les projets de premier plan, qui ont mis en place un système de divulgation coordonnée, publient le correctif dès que le CVE est rendu public. Les autres projets, moins nombreux, avancent plus lentement : quelques heures pour les corrections mineures, mais plusieurs semaines, voire plus, lorsque le responsable doit effectuer un portage vers les versions antérieures, préserver la compatibilité des API ou concilier cette tâche avec son travail quotidien.
Le déploiement dans votre environnement allonge donc la durée initialement prévue.
Cette fenêtre était autrefois acceptable. Le développement des exploits était suffisamment lent pour que les défenseurs aient une bonne longueur d'avance sur les attaquants.
Mythos comble ce retard. La détection et l'exploitation s'effectuent désormais en une seule étape, et cette capacité ne restera pas l'apanage des défenseurs. Dès que des modèles similaires tomberont entre les mains des attaquants, la fenêtre de correction deviendra une fenêtre d'exposition. Au moment où le correctif sera déployé, l'exploit circulera déjà depuis plusieurs jours.
Le paquet est à jour et le responsable est réactif. Mais tout cela n'est d'aucune aide pour un système compromis dès le troisième jour d'un cycle de mise à jour de quatorze jours.
Bibliothèques EOL après Glasswing
La période suivant la date de fin de vie correspond à la période sans correctifs, durant laquelle aucun correctif ne sera jamais publié.
Log4Shell (CVE-2021-44228) figure toujours parmi les 10 vulnérabilités les plus ciblées, plus de quatre ans après sa divulgation, car Log4j reste intégré dans des applications héritées que personne ne souhaite migrer. Le même schéma se répète dans la longue liste des bibliothèques non maintenues : des bogues connus, des exploits publics et une base installée dont la mise à niveau serait trop perturbante. Le rapport « State of DevSecOps 2026 » de Datadog a révélé que les services fonctionnant sur des versions de langage en fin de vie (EOL) présentent un taux de vulnérabilités exploitables de 50 %, contre 31 % pour les versions prises en charge, la dépendance médiane accusant un retard de 278 jours par rapport à la dernière version.
Appliquez maintenant la découverte de la classe Glasswing à cette population.
Un correctif pour une bibliothèque maintenue finit toujours par être publié, même si cela prend du temps. Lorsque Mythos détecte une faille « zero-day » dans un élément tel que Python 3.7, une version du Spring Framework en fin de vie, ou l’un des milliers de paquets npm dont le responsable n’a plus publié de commentaire depuis deux ans, le bug est rendu public et restera à jamais sans correctif. Les mises à niveau forcées sont la solution vers laquelle tout le monde se tourne en premier. Dans la pratique, elles nécessitent des migrations impliquant des changements radicaux dans le code d'applications qui n'ont pas été modifiées depuis des années, avec un risque de régression et des coûts d'ingénierie que les équipes de conformité ne peuvent pas assumer.
C'est là que la fin de vie cesse d'être un simple problème de maintenance pour devenir un risque permanent pour la sécurité.
Dans un monde post-Glasswing, un logiciel non maintenu n'est pas seulement risqué : il est, de manière prévisible et répétée, vulnérable à des attaques, sans qu'aucun correctif ne soit jamais publié.
Comment SecureChain pour les logiciels libres comble cette lacune
SecureChain pour les logiciels libres remplace vos registres de paquets publics par une source contrôlée et sécurisée en permanence. Vos développeurs continuent à travailler comme ils le font déjà.
Une seule URL de registre entraîne trois changements :
- Chaque paquet est recompilé à partir du code source vérifié
Chaque paquet est recompilé dans un environnement sécurisé et isolé à partir d'un code source vérifiable. Pas de binaires hérités, pas d'artefacts en amont opaques.
- Les logiciels malveillants sont bloqués avant même d'atteindre votre infrastructure
Chaque paquet est analysé au niveau du code source afin de détecter tout code malveillant, tout mécanisme d'installation suspect et toute signature de menace connue avant d'être ajouté au registre.
- Les correctifs sont fournis en continu, même après la fin de vie du produit
SecureChain fournit des correctifs dans le cadre d'un contrat de niveau de service (SLA) dès l'apparition de nouvelles vulnérabilités CVE, y compris celles signalées par notre équipe lorsque les développeurs en amont ne parviennent pas à y remédier. La couverture se poursuit même après la fin de la maintenance, sur la version que vous utilisez déjà, sans mise à niveau obligatoire ni réécriture du code.
Prêt pour un audit dès le premier jour
En matière de conformité, ce problème comporte ses propres exigences. Chaque colis expédié par SecureChain est muni de une traçabilité de niveau 3 selon la norme SLSA , une SBOM signée correspondant au binaire que vous recevez, ainsi que des documents VEX indiquant pour chaque CVE signalé dans le paquet s’il a été corrigé dans la version que vous utilisez ou s’il ne s’applique pas à celle-ci.
Ces trois éléments sont précisément ce que les équipes d'audit et d'approvisionnement exigent. La provenance SLSA de niveau 3 prouve que le paquet a été compilé à partir d'un code source que vous pouvez inspecter, dans un environnement de compilation sécurisé, et qu'il n'a pas été altéré pendant le transfert. La SBOM indique précisément à votre auditeur ce qui se trouve en production. Le document VEX indique à votre scanner ce qui a été corrigé et ce qui ne s'applique pas à cette version, afin que votre équipe n'ait pas à trier les CVE qui ont déjà été corrigés.
Ajoutez à cela un engagement de correction garanti par un SLA, et l'augmentation du nombre de CVE ne se traduira pas par une augmentation des constatations d'audit. La documentation dont votre équipe chargée de la conformité a besoin est générée automatiquement par l'application des correctifs.
Ce que vos équipes en retirent
L'open source reste la meilleure façon de développer des logiciels. On a souvent tendance à croire, sous la pression, que l'adoption d'un logiciel est une décision ponctuelle qui n'entraîne aucun coût de sécurité à long terme.
SecureChain vous offre la rapidité et la flexibilité de l'open source sans les risques.
Votre équipe se concentre sur le développement de produits plutôt que sur la recherche de failles de sécurité. Vos développeurs continuent d'installer les paquets qu'ils utilisent déjà. Votre pipeline de compilation pointe vers SecureChain plutôt que vers le registre public. Les correctifs continuent d'affluer pour les composants essentiels, y compris ceux que la communauté open source a abandonnés. La traçabilité et les SBOM sont générées automatiquement. Lorsque la prochaine faille de type Glasswing sera révélée, la réponse consistera en une mise à jour de version, et non en un incident qui durera six semaines.
Vous n'avez pas besoin de remplacer votre pile pour réduire ce risque, mais vous devez modifier la manière dont elle est prise en charge.
La responsabilité de ce que vous expédiez ne change pas. C'est le transport qui change.
