Gestion des vulnérabilités
Les failles de vos dépendances, traitées dans le délai que vous fixez
Une application métier repose sur des centaines de bibliothèques que vous n'avez pas écrites. Des failles y sont publiées chaque semaine, et la plupart ne vous concernent pas. Le travail utile n'est pas de toutes les corriger, c'est de savoir lesquelles vous exposent réellement et de traiter celles-là dans un délai tenu.
Nous ne vendons pas un délai standard. Nous partons de votre exigence, celle de votre marché ou de votre donneur d'ordre, et nous dimensionnons le forfait de maintenance pour la tenir.
Ça vous parle ?
Le sujet n'apparaît jamais tant qu'il ne devient pas urgent
Ni l'éditeur qui a livré le logiciel, ni l'hébergeur qui gère les serveurs ne surveillent les dépendances de votre application. Trois situations dans lesquelles nos clients s'en aperçoivent.
Aucune des trois n'est urgente le jour où elle se présente. C'est précisément ce qui les rend coûteuses.
Un questionnaire sécurité arrive, et personne ne sait le remplir
Votre donneur d'ordre vous demande sous quel délai les failles de vos applications sont corrigées. La question est légitime, la réponse n'existe nulle part chez vous car personne ne s'occupe de ce sujet.
Une alerte tombe, et rien ne dit si elle vous concerne
Un outil signale douze vulnérabilités critiques sur votre projet. Aucune ne précise si le code fautif est seulement appelé par votre application.
La dernière montée de version date d'il y a trois ans
Chaque correctif de sécurité suppose désormais un saut de plusieurs versions majeures. Ce qui aurait pris une heure il y a deux ans en prend dix aujourd'hui.
EN RÉSUMÉ
Trois temps, dans cet ordre
Aucun des trois ne se saute. Une grille de délais écrite avant d'avoir compris ce qu'elle mesure ne tient pas, et un engagement pris sans outillage ne survit pas au premier trimestre.
Comprendre le sujet
Savoir ce qu'est une CVE, ce que mesure une note de gravité, et pourquoi une faille critique n'est pas toujours urgente. C'est le préalable à toute discussion de délai, et il ne se délègue pas.
Définir des délais d'intervention
Croiser votre exposition, vos obligations contractuelles et ce que vous êtes prêt à financer, pour écrire une grille qui tienne. La vôtre si vous en avez déjà une, la nôtre sinon.
- Grille par niveau de sévérité
- Délais exprimés en heures ouvrées
- Forfait dimensionné en conséquence
Tenir sur la durée
Un délai ne se tient pas à la volonté mais à l'outillage : dépendances à jour en continu, scans automatisés, chaîne de recette, et une preuve laissée à chaque intervention.
- Montées de version suivies
- Scans en intégration continue
- Rapport de scan avant et après
Notre principe
C'est votre exigence qui fixe le délai, pas notre catalogue
Un délai de correction n'est pas une caractéristique produit : c'est un niveau de service, et il se paie.
La plupart des prestataires annoncent une réactivité sans jamais la définir. Nous faisons l'inverse : nous écrivons le délai, nous disons dans quelles conditions il tient, et nous en tirons le prix. Un délai court mobilise davantage de veille, davantage de tests et davantage de mises en production : il coûte plus cher, et c'est normal.
Ce que nous apportons en amont, c'est la capacité à construire cette exigence avec vous quand elle n'existe pas encore, en nous appuyant sur des référentiels publics vérifiables plutôt que sur des habitudes maison.
Trois points de départ
Nous nous adaptons à ce que vous devez tenir
Nos clients n'arrivent pas au même endroit de la réflexion. Certains ont déjà une exigence écrite, imposée par un donneur d'ordre. D'autres découvrent le sujet parce qu'on vient de leur poser la question.
Dans les trois cas, le point d'arrivée est le même : une grille écrite dans le contrat, et un forfait calibré pour la tenir.
Vous avez déjà une grille imposée
Votre donneur d'ordre vous impose ses délais par niveau de sévérité. Nous les reprenons tels quels dans le contrat, et le forfait de maintenance est dimensionné pour les tenir. Un délai plus court coûte plus cher : ce n'est pas une posture commerciale, c'est le temps de veille, de test et de mise en production qu'il mobilise.
Vous n'en avez pas encore
Nous vous en proposons une, dérivée des référentiels publics plutôt que de nos préférences. Elle croise la gravité, l'exploitation réellement observée et l'atteignabilité du code concerné. Vous gardez la main : c'est vous qui arbitrez le curseur entre le niveau de service et son coût.
Vos exigences changent
Une nouvelle certification, un client plus exigeant, une application qui devient critique : le niveau de service se révise, et le forfait avec. Nous préférons rouvrir la discussion une fois par an plutôt que de vendre un engagement qui ne correspond plus à ce que vous vivez.
LA CONDITION
Deux choses rendent un délai tenable
Elles ne sont pas négociables, non par principe mais par mécanique : sans elles, le délai promis serait un mensonge poli.
Ce que nous demandons avant de nous engager
1. Que vous nous laissiez proposer les montées de version majeures, afin que votre application reste dans une zone de support éditeur. C'est ce qui garantit qu'un correctif existe le jour où il faut l'appliquer.
2. Qu'un forfait de maintenance technique couvre le travail de veille, de qualification, de mise à jour des dépendances et d'entretien de l'outillage du projet.
Les deux réunies, nous engageons les délais convenus au contrat. L'une des deux manquante, nous ne prenons aucun engagement de délai, et nous préférons l'écrire ici plutôt que de le découvrir ensemble au moment d'une alerte.
Notre méthode
Quatre temps, dont un seul demande un humain
Les trois autres s'outillent, et c'est ce qui rend le forfait raisonnable. Le temps de cerveau se concentre là où il change quelque chose.
Étape 1
Mettre à jour en continu, plutôt que rattraper
Les dépendances de votre application sont tenues à jour au fil de l'eau, dans le cadre du forfait de maintenance technique. C'est la mesure que l'ANSSI place parmi les plus rentables, et c'est celle qui règle l'essentiel du sujet avant qu'un délai contractuel ait à servir.
L'effet secondaire est le plus important : chaque saut de version reste petit, donc peu risqué. Une application suivie ne connaît pas de migration à sensation.
Étape 2
Détecter, puis qualifier
Les scans tournent dans la chaîne d'intégration : composer audit, npm audit et osv-scanner confrontent vos dépendances aux bases publiques de vulnérabilités.
Chaque alerte est ensuite qualifiée, et c'est le travail que rien n'automatise : le composant est-il utilisé en production ou seulement en développement, la fonction vulnérable est-elle appelée par le code, la faille est-elle exploitée dans la nature.
Étape 3
Corriger sans casser la production
Un correctif de sécurité n'est pas neutre : il peut modifier un comportement. Il passe donc par la chaîne habituelle, intégration puis recette puis production, avec les tests automatisés du projet.
C'est ce qui rend un délai tenable. Appliquer un correctif sans recette reviendrait à échanger un risque de sécurité contre un risque d'indisponibilité.
Étape 4
Laisser une preuve
Le livrable de référence est un rapport de scan repassé au vert, avec l'état avant et après l'intervention. C'est la pièce la plus simple à comprendre, y compris par quelqu'un qui ne lit pas de code, et elle se produit en même temps que le travail.
Rapports composer audit, npm audit, osv-scanner ou scan applicatif : fournis à la demande, quand vous en avez l'usage.
Périmètre et livrables
Ce que nous couvrons, et ce que vous recevez
La frontière est écrite ici pour qu'elle ne se découvre pas le jour d'un incident.
Et les livrables sont ceux dont vous avez l'usage : un rapport qui prouve, plutôt qu'un rapport qui occupe.
Ce que nous couvrons, et ce que nous ne couvrons pas
- Notre périmètre : Les vulnérabilités du code applicatif et de ses dépendances : bibliothèques PHP et JavaScript, framework, outillage du projet. C'est là, et seulement là, que nous engageons des délais.
- Celui de l'hébergeur : La couche d'hébergement relève de Clever Cloud : système, runtime, services managés. Nous ne la revendiquons pas, et si votre exigence porte dessus, un contrat en direct avec l'hébergeur est la bonne réponse.
- Nos horaires : Du lundi au vendredi, de 9 h à 18 h. Les délais annoncés sont des délais en heures ouvrées. Nous n'avons pas d'astreinte de nuit et de week-end, et nous préférons l'écrire plutôt que de laisser imaginer une surveillance permanente.
Ce que vous recevez
- Le livrable de référence : Un rapport de scan repassé au vert, avec l'état avant et après l'intervention. Il se comprend sans expertise, il se transmet tel quel à un auditeur, et il ne demande aucune mise en forme puisqu'il est produit par le travail lui-même.
- Le reste à la demande : Rapports d'audit de dépendances, scan applicatif, point détaillé sur l'état des versions. Nous produisons ce qui sert, pas ce qui rassure.
- Notre préférence : Une heure de démonstration en direct une fois par an, où l'on regarde ensemble l'état réel du projet, plutôt que des documents que personne n'ouvre. Nous le disons plutôt que de facturer du reporting.
De quoi répondre à un questionnaire fournisseur
- Ce qui vous est demandé : Un inventaire des composants, une veille sur les failles publiées, une évaluation de votre exposition, et des délais de correction définis à l'avance.
- Ce que nous apportons : Les quatre existent et se documentent, autrement que par une intention : la méthode qui les fonde est publiée.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Celui que nous avons convenu ensemble et écrit dans le contrat. Nous ne publions pas de grille unique, parce que le bon délai dépend de votre exposition, de vos obligations et de ce que vous êtes prêt à financer. Si votre donneur d'ordre vous impose une grille, nous l'appliquons et nous dimensionnons le forfait en conséquence. Si vous n'en avez pas, nous vous en proposons une appuyée sur les référentiels publics.
Nous ne prenons alors aucun engagement de délai, et nous le disons clairement dès la proposition. La raison est mécanique : sur une version sortie du support de son éditeur, le correctif de sécurité n'est pas publié. Le traiter suppose de monter d'une ou plusieurs versions majeures, ce qui est un projet, pas une intervention. Une montée majeure ne s'improvise pas un vendredi soir.
Non. Nous couvrons le code applicatif et ses dépendances. La couche d'hébergement, système et services managés, relève de Clever Cloud. C'est une séparation nette et nous préférons l'annoncer : promettre un périmètre que nous ne maîtrisons pas serait le meilleur moyen de décevoir au pire moment. Si votre exigence porte sur cette couche, un contrat direct avec l'hébergeur est la réponse adaptée.
Seulement si vous en voulez. Nous produisons les livrables dont vous avez l'usage, et pas davantage : un rapport envoyé toutes les semaines à quelqu'un qui ne l'ouvre pas ne prouve rien. Beaucoup de nos clients préfèrent une heure de démonstration en direct une fois par an, où l'on regarde ensemble l'état réel du projet. Les rapports de scan restent disponibles à la demande, notamment quand un audit les réclame.
Le délai porte sur l'application d'un correctif : il ne peut pas courir sur un correctif qui n'est pas publié. Nous basculons alors sur des mesures compensatoires, désactiver la fonction concernée, restreindre les accès qui y mènent, renforcer la surveillance, et nous vous informons de la situation et du risque résiduel. C'est le cas le plus fréquent sur une dépendance dont le mainteneur a cessé son travail, et c'est souvent le signal qu'il faut en changer.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.