IBM et Red Hat annoncent que Lightwell a découvert et corrigé plus de 400 vulnérabilités jusqu’alors inconnues dans des bibliothèques Java largement utilisées.

Pour autant, aucune bibliothèque n’est nommée, aucune CVE citée, aucune répartition par gravité fournie. Impossible en l’état de vérifier le chiffre, ni pour une DSI de savoir si elle est concernée.

Les correctifs ont été développés puis rétroportés, c’est-à-dire intégrés à des versions anciennes encore déployées en production.

Lancé au printemps dernier, Lightwell est un programme visant à redéfinir l’avenir du logiciel open source et à sécuriser les chaînes d’approvisionnement logicielles des entreprises à l’ère de l’IA.

Pendant des années, la sécurité de la supply chain s’est structurée autour de la visibilité : inventorier les composants, repérer leurs vulnérabilités, hiérarchiser les risques. L’IA bouscule cet équilibre en accélérant la recherche de failles.

Selon Red Hat, un code ancien ou réputé stable n’est pas à l’abri : il suffit à un agent d’IA d’une faille, même mineure, pour amorcer une attaque en plusieurs étapes.

De son. côté, le programme Glasswing d’Anthropic donne un autre ordre de grandeur. Entre avril et juillet 2026, ses partenaires ont identifié au moins 129 000 vulnérabilités vérifiées, dont plus de 33 000 classées critiques ou élevées. Anthropic juge ces chiffres fortement sous-estimés.

Les deux chiffres ne mesurent pas la même chose : Glasswing recense des vulnérabilités découvertes dans des logiciels très variés, Lightwell des failles corrigées dans des bibliothèques Java. Il ne s’agit donc pas de dire que Lightwell n’a traité que 0,3 % du problème, mais de montrer que la découverte va beaucoup plus vite que la correction.

Corriger une faille en production, ce n’est pas installer la dernière version. Une mise à niveau peut changer les API, casser la compatibilité, introduire des régressions, relancer une certification. Certaines applications reposent même sur des versions que plus personne ne maintient en amont.

La parade s'appelle le backporting. Soit écrire le correctif pour la version réellement déployée puis l'intégrer à une branche ancienne. Cela suppose de comprendre le code, de prouver que le correctif fonctionne, de chasser les effets de bord, de tester et de distribuer. Rien d'automatique.

Pour Gunnar Hellekson, de Red Hat, détecter les bogues ne fait que la moitié du chemin. L'autre moitié est que les clients n'aient pas à choisir entre sécurité et disponibilité. C'est cette ingénierie, lente et coûteuse, que Lightwell veut industrialiser.

Avec un investissement annoncé de 5 milliards $ et plus de 20 000 ingénieurs, augmentés par des outils d'IA, Lightwell combine l'expertise d'ingénierie open source des deux groupes. En juillet, ils ont présenté un premier catalogue de plus de 6 500 dépendances remédiées, signées numériquement et certifiées pour les écosystèmes Java et Python, avec l'ambition de passer de milliers à potentiellement des millions de paquets.

Le Clearinghouse ajoute une étape. Au lieu de piocher dans un catalogue, l'entreprise peut soumettre les vulnérabilités ou les dépendances de son organisation pour un examen et une correction prioritaires applicables aux versions anciennes qu'elle utilise encore.

L'offre est vendue par abonnement annuel en deux niveaux. Lightwell Network donne accès à des correctifs vérifiés et aux logiciels corrigés, à intégrer aux workflows existants. Lightwell Clearinghouse offre un traitement sur mesure des dépendances soumises. Un programme prévoit en outre un accès gratuit pour certaines universités, ONG et think tanks américains.

Le positionnement est celui d'une infrastructure de maintenance où les correctifs sont distribués via des référentiels sécurisés. Les entreprises gardent leurs scanners, dépôts, pipelines et processus de test. Selon IBM et Red Hat, rien ne doit être remplacé. Le modèle économique est assumé : mutualiser un coût d'ingénierie élevé et le vendre aux entreprises qui ne peuvent pas l'assumer en interne.