L'audit de sécurité d'un client retarde la conclusion de l'accord
L'équipe de sécurité du client a détecté des composants non pris en charge dans votre produit et souhaite savoir qui se charge de les corriger. HeroDevs s'en charge et vous fournit la documentation nécessaire pour le prouver.

La transaction est bloquée par un problème que votre équipe d'ingénieurs ne parvient pas à résoudre
L'équipe de sécurité du client a analysé ce que vous fournissez et a identifié des paquets open source arrivés en fin de vie, ce qui signifie que leurs responsables ne publient plus de correctifs de sécurité pour ceux-ci. Le questionnaire demande qui en assure la maintenance, quand ils ont été mis à jour pour la dernière fois et quel est votre engagement en matière de correction. Vous n'avez aucune réponse qui réponde à l'une de ces trois questions.
Du coup, la transaction est au point mort, et c'est vous qui devez vous en occuper. Le service juridique a terminé son travail, le service des achats est prêt, et le seul obstacle est un composant que votre équipe n'a pas développé et qu'elle ne peut pas corriger. Le service commercial vous transmet le dossier, car il n'y a personne d'autre à qui s'adresser, et la même situation se répète pour chaque contrat d'entreprise en cours de négociation.
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
.webp)
Découvrez ce qu’un audit de sécurité mettra en évidence
Obtenez un rapport répertoriant toutes les dépendances en fin de vie présentes dans ce que vous livrez, qu'elles soient directes ou transitives.

Le problème
Chaque solution envisageable pour passer l'évaluation a un coût ailleurs
Passer à une version prise en charge
Cela répond de manière adéquate à l'objection. Cela implique également des modifications entraînant des incompatibilités, une série complète de tests de régression et une nouvelle version que chaque client existant devra prendre en charge, selon un calendrier dicté par un contrat plutôt que par les besoins techniques.
Prends l'engagement de y remédier plus tard
Un plan de remise en conformité daté peut débloquer une transaction. Il crée également une obligation contractuelle que vous devez désormais financer, dans un délai fixé par le client, et qui fera l'objet d'une vérification lors du renouvellement.
Faites de l'IA votre responsable de la maintenance
C'est précisément ce qu'exige la question : non pas un correctif ponctuel, mais un engagement permanent à corriger toutes les vulnérabilités futures. Un réviseur ne peut accepter cela, car on ne peut rien exiger d'un modèle. Il n'y a pas de contrat de niveau de service (SLA) à invoquer, aucune partie contractante, et aucune réponse à apporter lorsqu'on demande qui a révisé le code.
La solution
Cette objection n'a plus lieu d'être, car le composant est pris en charge par HeroDevs
Une version gérée par HeroDevs remplace le composant signalé
Une version sécurisée intégrée à la gamme de produits que vous commercialisez déjà, de sorte que la question « qui en assure la maintenance ? » trouve une réponse claire.
Une déclaration VEX et une attestation signée sont jointes à chaque mesure corrective
Dans le format déjà accepté par leur évaluateur, il n'y a donc rien à mettre en page une fois le questionnaire reçu.
Les nouvelles vulnérabilités CVE font l'objet de correctifs dans le cadre de notre SLA CVE de 14 jours
Un engagement que vous pouvez consigner par écrit, plutôt qu’une date de remise en état que vous devez financer.
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
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
Tout ce dont l'examen de sécurité a besoin pour que la transaction puisse être conclue
.webp)
.webp)
Ce que demandent les équipes de sécurité
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.
Une déclaration VEX par mesure corrective, précisant si la vulnérabilité CVE affecte le progiciel livré, ainsi qu'une attestation signée. Ces deux documents peuvent être joints directement au questionnaire.
Oui. Le produit de remplacement s'intègre directement à la gamme que vous commercialisez déjà ; vous ne leur demandez donc pas de réévaluer un produit différent de celui prévu dans l'accord.
Cela dépend si le paquet est déjà pris en charge. Si c'est le cas, la mise à jour correspond à un changement de version. Si ce n'est pas le cas, contactez-nous dès que possible, car la compilation prend du temps et le délai imparti pourrait ne pas suffire.
Les colis couverts relèvent du SLA CVE de 14 jours, qui constitue un engagement que vous pouvez formaliser par écrit, et non une simple intention.
Les mêmes justificatifs suffisent pour chaque contrôle. Vous ne les fournissez qu'une seule fois, et non à chaque transaction.
Ne s'applique pas aux éléments couverts. La prise en charge ne prend pas fin ; la réponse reste donc la même pour le cycle suivant et lors du prochain audit.
Un sujet qui n'est pas abordé ici ? Demandez conseil à un expert.