Il existe une vulnérabilité CVE et aucun correctif n'est disponible, car la version est en fin de cycle de vie.

Le correctif en amont n'est disponible que plusieurs versions majeures plus tard, si tant est qu'il existe. HeroDevs compile une version sécurisée de la version que vous utilisez déjà, ce qui permet de clore le problème sans avoir à effectuer de mise à jour.

Angular La version 1.8.3 présente une vulnérabilité à haut risque (CVE-2024-21490) affectant les versions 1.3.0 à 1.8.3, pour laquelle aucun correctif n'est disponible.

Il n'existe pas de version corrigée vers laquelle basculer.

Votre scanner signale une vulnérabilité CVE affectant un paquet en production. Vous cherchez la version corrigée, mais elle n'existe pas. La branche de version que vous utilisez a atteint sa fin de vie, et l'avis de sécurité mentionne une version corrigée qui se situe deux ou trois versions majeures plus loin que celle que vous utilisez actuellement.

Le problème reste donc en suspens. Il réapparaît à chaque analyse, il est signalé lors du prochain audit et figure dans le prochain questionnaire de sécurité que vous envoie un client. Rien ne se résout tout seul, car la personne qui serait normalement chargée d'y remédier n'est plus là.

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

Les migrations forcées qui mettent en péril la feuille de route

Chronologie des versions du noyau Linux, présentant les versions 4.1.7 à 4.2.2 avec les alertes CVE et les avis de fin de vie.

Vous connaissez déjà le CVE ?

Recherchez les vulnérabilités corrigées par HeroDevs pour voir s'il existe déjà une version sécurisée de votre paquet.

Sévérité
ID
Technologie
Catégorie
Version(s) affectée(s)
Haut
Apache Struts
Déni de service
>=2.1.8 <=2.3.37, >=2.5.0 <=2.5.33, >=6.0.0 <=6.10.0, >=7.0.0 <=7.2.1
Haut
.NET
Injection de ressources
Microsoft.Build.Tasks.Core >= 17.0.0 <= 17.8.3; as bundled in the .NET 6 SDK through NES for .NET 6.0.44
Haut
.NET
Résolution incorrecte des liens avant l'accès au fichier (« suivi de lien »)
Microsoft.Build.Tasks.Core >= 17.8.0 <= 17.14.8; as bundled in the .NET 6 SDK through NES for .NET 6.0.44
Haut
.NET
Allocation des ressources sans limites ni restriction
Microsoft.AspNetCore.App >= 6.0.0 <= 6.0.44
Moyen
.NET
Faiblesse cryptographique
Microsoft.NETCore.App >= 6.0.0 <= 6.0.44
Haut
.NET
Exécution de code à distance
Microsoft.NETCore.App >= 6.0.0 <= 6.0.44
Haut
Apache Struts
Déni de service
>=2.0.0 <2.3.38, >=2.5.0 <2.5.34, >=6.0.0 <6.11.0, >=7.0.0 <7.3.0
Moyen
Usurpation de contenu
>=2.16.0 <2.24.0
Faible
Contournement de l'autorisation
>=2.0.0 <=2.39.0
Critique
Contournement de l'autorisation
>=2.11.0 <=2.44.0
Haut
.NET
Débordement d'entier ou bouclage
SkiaSharp < 4.148.0
Haut
Jackson
Déni de service
>=2.9.0 <2.18.8, >=2.19.0 <2.21.4
Haut
Node.js
Autorisation incorrecte
22.x <= 22.23.1; 24.x <= 24.18.0; 26.x <= 26.5.0; 20.x (End-of-Life, all versions)
Haut
.NET
Exécution de code à distance
Microsoft.WindowsDesktop.App >= 6.0.0 <= 6.0.43
Moyen
.NET
Contrôle d'accès mal configuré
Microsoft.NETCore.App >= 6.0.0 <= 6.0.43
Icône d'exclamation
Aucun résultat trouvé

La vulnérabilité que vous avez saisie n'a pas été trouvée dans notre répertoire.

Nous vous remercions ! Votre demande a bien été reçue !
Oups ! Un problème s'est produit lors de l'envoi du formulaire.

Le problème

Toute solution alternative coûte plus cher que ce que devrait coûter la réparation

Passez à la version qui contient le correctif

La version corrigée correspond à une version majeure supérieure ; il s'agit donc d'une migration plutôt que d'une simple mise à jour : des changements incompatibles à tous les points d'appel, d'autres paquets liés à la version majeure que vous quittez, ainsi qu'une série complète de tests de régression. Des semaines de travail d'ingénierie, planifiées et menées à bien dans le but de corriger une faille de sécurité.

Faites-le vous-même

Créez une branche du projet, réintégrez le correctif et assurez la maintenance de cette branche indéfiniment. Vous vous retrouvez alors avec du code que personne en dehors de votre équipe ne vérifie, et c'est également à vous qu'il reviendra de gérer la prochaine vulnérabilité CVE concernant ce même paquet.

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 assume la responsabilité s’il passe à côté de la vulnérabilité ou perturbe l’environnement de production.

La solution

HeroDevs assure la maintenance de la branche de versions laissée par le projet

Nous assurons une mise en production sécurisée au sein de l'environnement que vous exploitez déjà

Les ingénieurs de HeroDevs appliquent les correctifs de sécurité à une version prise en charge de votre branche, plutôt que de vous demander de passer à la version majeure actuelle.

Vous modifiez la référence de dépendance

La nouvelle version est compatible avec l'API ; le code de l'application reste donc inchangé. Si vous utilisez une version antérieure à celle prise en charge, vous devez d'abord effectuer la mise à jour vers cette dernière, ce qui reste dans le cadre de la version que vous utilisez déjà.

De nouvelles vulnérabilités CVE font régulièrement l'objet de correctifs

Les offres couvertes sont soumises au contrat de niveau de service (SLA) CVE de 14 jours de NES, tant que vous utilisez le logiciel.

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

"Au-delà des avantages techniques, la solution d'HeroDevs a apporté une valeur commerciale significative. Nous avons maintenu notre niveau de sécurité sans compromettre 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 modification, ainsi que les éléments permettant de clore le rapport de problème

Capture d'écran de la plateforme EvergreenVue du dépôt de code affichant le dossier « Compliance » contenant des fichiers JSON et PDF, dont l'un est marqué comme « Non concerné ».

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.

S'agit-il d'un fork du projet ?
Dois-je modifier le code de l'application ?
Dans quel délai appliquez-vous un correctif pour une nouvelle vulnérabilité CVE ?
Et si le framework dont j'ai besoin n'était pas encore pris en charge ?
Comment puis-je présenter cela à un auditeur ?
Et si c'était l'ensemble du projet qui était en fin de vie, et pas seulement ma version ?
Est-ce que cela m'empêchera de migrer plus tard ?

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

Vérifiez si le framework qui vous pose problème est déjà pris en charge