Les vulnérabilités CVE ne cessent d'apparaître, obligeant les ingénieurs à effectuer des interventions de maintenance imprévues

Il ne s'agit pas d'un carnet de commandes que vous pouvez liquider. Avec Evergreen, chaque dépendance de votre application est surveillée et prise en charge lorsqu'elle arrive en fin de vie, que ce soit aujourd'hui ou dans deux ans.

Liste des alertes Dependabot indiquant les vulnérabilités d’ Angular classées comme critiques, élevées et moyennes.

Chaque vulnérabilité CVE détectée dans un logiciel en fin de vie constitue un projet à part entière.

Un ingénieur doit évaluer la vulnérabilité, étudier le correctif fourni par le développeur en amont, l'adapter à une version pour laquelle il n'a pas été conçu, vérifier qu'aucun autre élément ne présente de dysfonctionnement, puis le déployer. Une fois qu'un logiciel open source arrive en fin de vie, les responsables de la maintenance cessent de publier des correctifs de sécurité ; chaque nouvelle vulnérabilité CVE le concernant devient donc la responsabilité de votre équipe, et non plus celle d'une version en amont.

Aucune de ces tâches n'était prévue. Elles viennent grignoter des ressources déjà affectées à autre chose, dont vous restez responsable de la réalisation. Et à mesure que l'arborescence des dépendances open source s'étoffe et que le nombre de CVE augmente, les interruptions se multiplient elles aussi.

Quels sont les problèmes qui surviennent lorsque les correctifs en amont cessent d'être fournis ?

Sécurité

Vulnérabilité CVE non corrigée

Conformité

Aucun élément ne permet de démontrer que

Feuille de route et budget

Migration effectuée, vitesse imprévue

Chronologie indiquant, à l'aide de coches vertes, le support actif et les correctifs de sécurité des logiciels libres (OSS), puis la transition vers la fin de vie accompagnée d'alertes CVE.

Combien de dépendances open source non prises en charge votre pile contient-elle ?

Obtenez un rapport répertoriant toutes les dépendances en fin de vie présentes dans vos dépôts, qu'elles soient directes ou transitives.

Résumé de l'analyse logicielle indiquant que 1 701 paquets ont été analysés, dont 218 en fin de vie, 1 322 n'étant pas en fin de vie et 157 dont le statut est inconnu, avec des indicateurs de risque.

Le problème

Les réponses courantes, et pourquoi elles ne sont pas viables

Confier cette tâche à quelqu'un de manière permanente

Un système de rotation pour la maintenance rend le travail prévisible sans pour autant réduire son volume. Vous avez transformé une interruption en coût fixe, et l'ingénieur en rotation ne réalise aucun projet au cours de ce trimestre.

Faites confiance aux mises à jour automatiques

Dependabot et Renovate effectuent leur analyse par rapport aux versions publiées. Sur une branche en fin de vie, aucune version publiée en amont ne contient le correctif ; l'alerte se déclenche donc, mais aucune pull request n'est générée. L'outil confirme la vulnérabilité et ne peut pas la résoudre.

Générer la correction à l'aide de l'IA

Rapide et de plus en plus courant. Une étude indépendante révèle que près de la moitié du code généré par l’IA introduit de nouvelles vulnérabilités, et qu’un correctif non vérifié soulève la question de savoir qui en assumera la responsabilité s’il ne détecte pas la vulnérabilité ou provoque une interruption de la production.

La solution

Avec Evergreen, la correction des incidents ne constitue plus une interruption, mais une file d'attente que vous contrôlez

Connectez vos dépôts une seule fois

Installez l'application GitHub HeroDevs sur l'ensemble des dépôts qui composent votre application.

Chaque dépendance se voit attribuer un état

L'analyse s'effectue automatiquement. Chaque dépendance fait l'objet d'une surveillance tant qu'elle est prise en charge, et est placée en file d'attente pour être corrigée dès qu'elle atteint sa fin de vie et qu'un CVE est publié.

Les remplacements sont soumis sous forme de pull requests

Une demande de fusion ouverte par dépendance, classée par niveau de gravité et avec un plafond quotidien. Vous les examinez et les fusionnez selon votre propre calendrier.

Pourquoi HeroDevs ?

Plus de 19 millions

versions des paquets suivies

1,000+

vulnérabilités corrigées

900+

clients professionnels protégés par HeroDevs

Logo Statista

Nous avons préservé notre niveau de sécurité sans remettre en cause notre feuille de route stratégique, tout en réalisant des économies substantielles par rapport à une migration complète.

Markus Wolf, architecte chez Statista

Une demande de fusion que vous pouvez fusionner, et une file d'attente que vous pouvez gérer

Capture d'écran de la plateforme EvergreenÉtat de la couverture pour le service de caisse, présentant trois catégories avec respectivement 603, 1 et 1 cas.

Ce que demandent les équipes chargées de la sécurité et de la conformité

Obtenez des réponses à certaines de nos questions les plus fréquemment posées.
Bien entendu, si vous ne trouvez pas la réponse que vous cherchez, n'hésitez pas à nous contacter.

Combien de pull requests cela va-t-il générer ?
Est-ce que cela remplace Dependabot ou Renovate ?
Faut-il fusionner toutes les demandes de modification ?
Que se passe-t-il lorsqu'une dépendance n'est pas encore prise en charge ?
Et si nous utilisions une version antérieure à celle que vous prenez en charge ?
À quelle partie de notre pile cela s'applique-t-il ?

Un sujet qui n'est pas abordé ici ? Demandez conseil à un expert.