Broadcom a déclaré mardi 27 octobre avoir fourni des correctifs pour 89 vulnérabilités de TrueSource Spring Enterprise aux clients d’infrastructures critiques et autres clients éligibles à l’accès anticipé, avant leur divulgation publique. L’entreprise a également présenté des outils destinés à aider les entreprises à identifier les applications concernées et à déployer les correctifs.
Pour les équipes de sécurité, la question pratique est de savoir quelles applications nécessitent ces correctifs et si les mises à jour atteignent la production. Identifier une dépendance vulnérable, approuver une modification et confirmer son déploiement sont trois étapes distinctes.
De nouveaux outils ciblent les lacunes de la correction
Broadcom a reconnu que les correctifs ne protègent les systèmes qu’une fois déployés, une préoccupation centrale dans la gestion des correctifs. Pour combler cette lacune, l’entreprise a ajouté TrueSource Hub, qui se connecte aux dépôts de code et fournit une vue en temps réel des applications Spring nécessitant des correctifs et des versions qui ne sont plus prises en charge.
L’entreprise a également présenté des plug-ins de build pour Application Advisor, qui s’intègrent aux workflows Maven et Gradle existants et génèrent automatiquement des pull requests pour les correctifs approuvés. En outre, une intégration avec JFrog Zero-Touch Remediation fournit des correctifs vérifiés directement dans les builds.
L’ampleur de l’effort
Broadcom a indiqué que ses ingénieurs avaient corrigé 406 nouvelles vulnérabilités dans les bibliothèques Spring et Reactor en 2026, fournissant plus de 1 090 correctifs au total, dont 798 rétroportages. L’équipe a examiné plus de 2 600 rapports de sécurité et écarté plus de 3 000 fausses alertes.
Parmi les correctifs précédents figuraient CVE-2026-41855, une faille de désérialisation de gravité élevée de Spring Framework touchant les environnements JMS non fiables ; CVE-2026-47691, une faille d’empoisonnement du cache DNS de Netty actuellement notée 8,7 par ses mainteneurs ; et CVE-2026-67404, une faille de RabbitMQ notée 9,2 qui pouvait permettre de falsifier des jetons d’authentification dans certaines configurations OAuth2 et de certificats.
« La sécurité n’est pas une initiative ponctuelle ; c’est un engagement permanent », a déclaré Purnima Padmanabhan, directrice générale de la division Tanzu de Broadcom. « En juin, nous nous sommes engagés à identifier et à corriger les vulnérabilités de Spring plus rapidement que jamais, et la publication d’aujourd’hui témoigne de la poursuite de notre dynamique. »
Ce que les équipes de sécurité doivent vérifier avant de déployer les correctifs
Commencez par établir une correspondance entre les applications Spring, leurs dépendances, les branches de versions prises en charge et leurs responsables. Demandez à Broadcom quels correctifs récemment annoncés s’appliquent à ces déploiements et si l’organisation est éligible à l’accès anticipé. Le décompte des vulnérabilités à l’échelle du portefeuille ne permet pas d’établir l’exposition d’une application donnée.
Selon Broadcom, les plug-ins d’Application Advisor génèrent des pull requests pouvant être révisées, tandis que l’intégration JFrog fournit les correctifs directement dans les builds. Les équipes doivent déterminer quelle voie chaque application utilise, qui approuve les modifications et quels tests doivent être réussis avant le déploiement. La gestion automatisée des correctifs doit s’intégrer aux contrôles de modification et aux procédures de restauration existants.
La compatibilité avec les outils existants de gestion des vulnérabilités doit également être vérifiée. Broadcom décrit la reconnaissance par Snyk de ses versions corrigées de Spring comme un partenariat continu. Vérifiez que le scanner utilisé reconnaît bien l’artefact corrigé exact avant de supprimer une détection ; conservez l’avis du fournisseur et les éléments relatifs au paquet qui justifient cette décision.
Les enregistrements de build peuvent aider à documenter les bibliothèques contenues dans une application, mais les équipes doivent également vérifier que l’artefact obtenu est bien parvenu jusqu’à la charge de travail en cours d’exécution. Une pull request fusionnée ou un build réussi ne doit pas, à lui seul, clôturer un ticket de correction.
Avant d’adopter ce workflow, les responsables informatiques doivent confirmer les coûts de licence, les exigences d’accès aux dépôts, les exportations de données d’audit et la compatibilité avec les outils de sécurité existants. Le véritable indicateur est de savoir si le processus réduit la durée pendant laquelle les applications concernées restent exposées, tout en préservant les preuves de test, d’approbation et de déploiement.
Broadcom indique que TrueSource Spring Enterprise, y compris Hub et les plug-ins de build, est généralement disponible. L’accès aux correctifs récemment annoncés est dans un premier temps limité aux clients éligibles bénéficiant de l’accès anticipé et aux clients d’infrastructures critiques ; les détails publics des vulnérabilités et la publication des CVE suivront.
En savoir plus : pour les besoins de correction au-delà des applications Spring, comparez les fournisseurs de gestion des correctifs selon leur couverture, leur automatisation et leurs contrôles de déploiement afin d’évaluer leur adéquation à votre environnement plus large.