Quand les zero‑days pleuvent, ne vous noyez pas : le guide d’action sur 72 heures d’un CTO pour les déversements massifs

Un matin, vous vous réveillerez et découvrirez qu’un compte GitHub anonyme déverse en masse des zero‑days qui touchent votre stack. Des scripts de preuve de concept atterrissent sur les réseaux sociaux avant même que la NVD n’attribue des IDs. Votre pager sonne non pas parce qu’un service est down, mais parce que l’automatisation de l’exploit vient d’être copiée‑collée dans un millier de botnets.

Ce n’est pas un événement exceptionnel. C’est le nouveau rythme. Les vagues récentes de divulgations et de publications massives de PoC prouvent que l’avance des attaquants se mesure en heures, pas en semaines. La bonne réaction n’est pas la panique ; c’est une réponse réflexe qui transforme le chaos en plan d’action sur 72 heures.

Si vous exploitez un SaaS moderne, votre surface d’attaque est énorme. Un service TypeScript/Node typique embarque des milliers de dépendances transitives. Un microservice Go containerisé peut sembler « statique », mais il repose toujours sur une image de base avec des dizaines de paquets et un kernel en mouvement permanent. Le delta entre « il y a un bug quelque part » et « votre instance est atteignable et exploitable » est l’endroit où vous gagnez ou perdez les prochaines 72 heures.

L’objectif : l’atteignabilité, pas les gros titres

Votre mission n’est pas de « tout corriger ». Votre mission est de répondre rapidement à trois questions pour chaque zero‑day allégué :

• Cette vulnérabilité est‑elle atteignable dans notre environnement ?
• Est‑elle exposée à Internet ou protégée par des contrôles d’authentification/réseau ?
• Avons‑nous une mitigation à court terme (config, WAF, feature flag, politique réseau) qui nous achète le temps de patcher ?

Tout le reste — PR, rétros, tweets d’éditeurs — vient après. Ce post vous donne un playbook concret sur 72 heures à confier à vos leads. Il suppose que vous avez au moins les briques de base : logs centralisés, CI/CD capable de livrer en quelques heures, et un espace pour une war room transverse. Sinon, votre projet du jour 1 après la tempête est de les construire.

Heure 0–2 : stabiliser, instrumenter et se réunir

1) Montez une war room avec des rôles clairs

• Responsable d’incident (vous ou un délégué) : responsable unique, tranche priorités et arbitrages.
• Analyste des exploits : suit les déclarations, PoC et indicateurs de compromission (IoC).
• Cartographe de l’exposition : relie les composants vulnérables aux actifs via votre SBOM et votre catalogue de services.
• Ingénieur en mitigations : gère les règles WAF, les feature flags, la politique réseau et les configurations rapides.
• Responsable patch : coordonne les changements de code, les reconstructions d’images et les déploiements.
• Communication : mises à jour internes à l’heure ; mises à jour externes à des jalons définis.

2) Créez un canal d’entrée et de suivi unique

• Mettez en place un tracker partagé (un tableur ou un board d’issues suffit) avec les colonnes : id/nom de vuln, lien source, composant affecté, atteignabilité, exposition (internet/interne), mitigation, statut du patch, propriétaire, ETA.
• Étiquetez chaque item avec une sévérité basée sur exposition × atteignabilité × maturité de l’exploit. Si un PoC fonctionnel existe et que votre composant est exposé à Internet et atteignable, c’est un P0.

3) Augmentez la visibilité maintenant

• Activez les logs à forte valeur s’ils sont désactivés : logs de requêtes du reverse proxy, décisions de la passerelle d’auth, pics 4xx/5xx, alertes du runtime des conteneurs.
• Définissez des automatisations ad hoc pour les anomalies : pic 10× sur des routes spécifiques, User‑Agents atypiques, connexions sortantes vers des hôtes suspects.
• Abonnez‑vous et récupérez des signaux d’exploit connus depuis des sources publiques comme le CISA KEV et les flux de threat intel communautaires.

4) Appliquez une friction bon marché et réversible

• Limitez le débit des endpoints suspects agressivement. Si votre baseline est 100 rps, descendez à 20 rps par IP pendant les 6 prochaines heures sur les routes vulnérables.
• Désactivez temporairement les endpoints publics non essentiels via la config. Si vous pouvez le faire derrière un feature flag, faites‑le. Utilisez les pages de maintenance avec parcimonie.
• Filtrage géographique ou par ASN pour les sources de trafic manifestement malveillantes si le pattern est évident.

Heure 2–8 : dimensionner l’exposition avec SBOM et atteignabilité

5) Générez ou récupérez des SBOM pour ce qui tourne réellement

• Pour les conteneurs et services, générez des SBOM avec Syft ou équivalent. Stockez‑les dans un endroit interrogeable (p. ex., Dependency‑Track ou un registre interne).
• Pour le serverless, collectez les lockfiles des packages et les manifestes de build. Si vous n’avez pas de SBOM, rassemblez les SHA de commit des lockfiles liés aux versions déployées.
• Scannez via OSV/NVD et les avis des éditeurs. Priorisez les problèmes qui correspondent aux composants que vous déployez réellement.

6) Faites une atteignabilité rapide, pas un SAST académique

• Questionnez : notre application appelle‑t‑elle le code vulnérable en production ? Exemples : une injection de templating dans une librairie seulement utilisée par un outil admin non exposé à Internet peut être P2, pas P0.
• Si vous avez des outils d’atteignabilité (p. ex., analyse de graphe d’appels ou fonctions éditeur qui identifient les « vulnérabilités atteignables »), utilisez‑les. Sinon, appuyez‑vous sur les code owners pour confirmer les imports/usages.
• Vérifiez la télémétrie runtime pour des invocations des chemins suspects (routes, RPC, fonctions). Grepper les logs pour routes et en‑têtes vaut mieux que deviner.

7) Confirmez l’exposition Internet

• Faites une carte d’exposition rapide : quels services sont publiquement atteignables, quels ports sont ouverts, et où l’auth est imposée. Des outils comme Shodan aident à voir ce que voit le monde.
• Documentez les contrôles réseau : mTLS, allowlists IP, API gateways. Une exposition sans auth est un risque ; une exposition avec auth robuste et alertes d’anomalies peut vous acheter du temps pour patcher.

8) Récupérez tôt la position des éditeurs

• Suivez les déclarations et patchs des mainteneurs upstream. Si l’ETA d’un correctif est à 24 heures, concevez des mitigations qui tiennent la ligne jusque‑là.
• Pour les services managés, ouvrez des tickets et demandez une position écrite sur l’exposition et les mitigations.

Heure 8–24 : mitiger d’abord, patcher vite là où ça compte

9) Livrez des mitigations réversibles en quelques minutes

• Règles WAF : bloquez les signatures de payload suspectes et imposez des limites strictes de content‑type et de taille sur les endpoints affectés. Des fournisseurs comme Cloudflare ou Fastly déploient des règles en minutes ; validez avec du trafic canari.
• Feature flags : coupe‑circuits pour les fonctionnalités à risque. Si vous n’avez pas de flag, créez un garde‑fou adossé à la config au point d’entrée. Des toggles à la OpenFeature permettent un rollback instantané.
• Politique réseau : pour les problèmes inter‑services, serrez l’egress. Des restrictions sortantes empêchent les callbacks post‑exploitation.

10) Patch par niveau d’exposition

• Tier A : exposé Internet + atteignable + PoC existant. Visez TTR < 24 h. Patch ou hot‑patch. Si aucun patch n’est disponible, mitigez et prévoyez un contrôle compensatoire vivable une semaine.
• Tier B : interne ou protégé + atteignable. TTR < 72 h. Intégrez au prochain créneau de release ; ne privez pas le travail Tier A.
• Tier C : non atteignable en production. Documentez, surveillez et planifiez. Profitez de la tempête pour supprimer les dépendances mortes plutôt que de simplement les mettre à jour.

11) Reconstruisez ce que vous exécutez vraiment

• Conteneurs : reconstruisez les images de base pour intégrer les correctifs distro. Figez les digests, pas les tags. Poussez vers un registre durci. Faites tourner des scans Trivy/Grype comme garde‑fous, pas comme rapports.
• Runtimes : si l’exploit cible le runtime (p. ex., JIT ou interpréteur), pesez soigneusement une montée de version majeure. Un backport ciblé peut être plus sûr dans les premières 24 heures.
• Secrets : supposez le pire en cas d’exploitation confirmée. Faites tourner les identifiants et tokens touchés par les services affectés.

12) Communiquez en professionnel

• Mises à jour internes horaires en war room : ce qui a changé, la suite, les bloqueurs.
• Mises à jour statut externes à des jalons prévisibles (p. ex., à 8, 24 et 48 heures). Partagez les mitigations appliquées et la prochaine ETA. Ne spéculez pas.
• Notifications réglementaires et contractuelles si les seuils sont atteints. Consultez le juridique tôt.

Heure 24–48 : valider, contenir et fermer à jamais les écarts les plus faciles

13) Prouvez que la mitigation fonctionne

• Utilisez des charges inoffensives pour valider les règles WAF. Confirmez les 403 attendus et que le trafic légitime passe.
• Déployez des patchs canaris sur 5–10 % et surveillez les budgets d’erreurs. Si c’est stable, procédez au déploiement complet.
• Pour les chemins admin ou auth critiques, ajoutez des prompts MFA temporaires ou une ré‑authentification afin de réduire le risque d’abus de session.

14) Chassez les compromissions

• Recherchez dans les logs et la télémétrie les IoC publiés avec les PoC. Remontez au moins 30 jours si vous soupçonnez une exploitation pré‑divulgation.
• Inspectez processus inhabituels, nouvelles tâches cron ou reverse shells avec des outils runtime (p. ex., alertes basées sur Falco/eBPF) si applicable.
• Si vous trouvez des signes crédibles d’exploitation, basculez en réponse à incident complète : isolez les hôtes, préservez les images forensiques et élargissez la communication.

15) Comblez les lacunes structurelles faciles

• Ajoutez ou durcissez des coupe‑circuits pour les endpoints à risque afin que la prochaine tempête n’exige pas d’éditer du code pour désactiver une fonctionnalité.
• Réduisez la surface d’impact : politiques réseau plus strictes, frontières de namespaces et identifiants par service.
• Automatisez la génération de SBOM à chaque build et stockez les artefacts de façon centrale. Reliez les versions déployées aux instantanés SBOM.

Heure 48–72 : normaliser et transformer la panique en processus

16) Documentez les faits, pas le mythe

• Pour chaque vulnérabilité traitée : sévérité finale, décision d’atteignabilité, mitigations, versions patchées, et horodatages pour TTI (time‑to‑intake) et TTR (time‑to‑remediate).
• Consignez les constats négatifs : « non atteignable en prod » est un résultat valide et auditable.

17) Mettez à jour les runbooks et les SLO

• Fixez des SLO “tempête” : P0 exposé Internet, atteignable avec PoC → mitiger en 4 heures, patcher sous 24 heures. P1 interne atteignable → patcher sous 72 heures.
• Ajoutez un arbre de décision à votre runbook : si PoC existant et atteignabilité confirmée → options de mitigation A/B/C ; si l’ETA du patch upstream > 48 h → hot‑patch ou coupe‑circuit de fonctionnalité.

18) Couvrez les creux de staffing avec une équipe follow‑the‑sun

• Les tempêtes n’ont que faire des fuseaux horaires. Un petit pod nearshore (2–4 ingénieurs) formé à votre stack, avec 6–8 heures de recouvrement avec les US, peut faire avancer les chantiers de mitigation et de patch pendant que votre équipe cœur dort.
• Faites‑en une fonction pérenne, pas une rotation ad hoc. Le coût est faible au regard des heures brûlées à chaque tempête.

Investissements pré‑tempête qui paient en minutes

Tout ce qui précède fonctionne sans être parfait. Mais si vous voulez transformer 72 heures en 24, investissez maintenant :

Construisez des SBOM et une carte des dépendances qui répondent « où cela tourne ? »

• Émettez des SBOM (CycloneDX ou SPDX) au build pour chaque service et conteneur. Stockez‑les dans un système requêtable (Dependency‑Track, sortie OSV‑Scanner + une base).
• Reliez les SBOM à votre catalogue de services afin de pouvoir dire : « La librairie X existe dans les services A, B ; seul A est exposé à Internet. »

Définissez des coupe‑circuits à l’ingress

• Mettez les points d’entrée des fonctionnalités à risque derrière des flags activables globalement. Même un garde‑fou adossé à du YAML suffit si vous pouvez recharger sans redéployer.
• Adoptez des interfaces à la OpenFeature pour des flags cohérents entre langages.

Renforcez votre CI/CD pour des reconstructions rapides et sûres

• Figez les digests des images de base et maintenez une image de référence capable de sortir une release avec correctifs de sécu en moins de 60 minutes.
• Conservez des garde‑fous de déploiement : déploiements étagés, rollback rapide et canaris.

Mettez en place une politique WAF de confiance

• Pré‑câblez un « profil tempête » qui resserre les plafonds de taille de requête, bloque les content‑types dangereux et impose des contrôles stricts sur les en‑têtes. Rendez‑le activable.
• Logguez les décisions WAF de manière centralisée pour prouver que la mitigation a touché du trafic réel.

Mesurez ce qui compte vraiment

• TTI (time‑to‑intake) : de la divulgation publique à un ticket dans le tracker. Cible : < 1 heure en tempête.
• Temps de détermination de l’atteignabilité : de l’intake à la décision « atteignable/pas ». Cible : < 4 heures pour tout ce qui est exposé Internet.
• TTR (time‑to‑remediate) : jusqu’à l’application de la mitigation et au déploiement du patch. Distinguez TTR de mitigation et TTR de patch.

Compromis à assumer

Mitigation vs patch

Les mitigations (WAF, flags, politique réseau) sont rapides mais imparfaites. Les patchs sont durables mais risquent des régressions. Dans les premières 24 heures, empilez les mitigations et livrez le patch minimalement sûr sur le Tier A. Ne courez pas après la perfection pendant qu’un PoC fonctionnel circule.

Rigueur runtime vs expérience utilisateur

Serrer les limites de débit et bloquer des patterns de payload agacera des utilisateurs légitimes. C’est un prix acceptable pour une journée. Communiquez‑le. Rétablissez dès que les patchs se stabilisent.

Centralisation vs autonomie des équipes

Les tempêtes récompensent la centralisation : un tracker, un owner, un rythme de com’ unique. Le reste de l’année, laissez les équipes gérer leurs dépendances. Gravelez cette distinction dans votre modèle opératoire pour ne pas débattre du process en plein incident.

Note sur Postgres, les sauvegardes et la fausse confiance

Les vagues de zero‑days croisent souvent votre couche data — même si le bug est ailleurs. Si vous déployez des hotfixes sous pression, validez que votre chemin de reprise fonctionne aujourd’hui. Les outils d’expédition WAL (p. ex., WAL‑G et de récentes réécritures en Rust) sont excellents, mais ne sont pas un filet de sécurité sans un restore réussi récent. Dans la fenêtre 48–72 heures, planifiez un restore de test vers un environnement mis en quarantaine et vérifiez RPO/RTO. Une sauvegarde fonctionnelle que vous ne pouvez pas restaurer en moins de deux heures n’est pas une sauvegarde ; c’est une histoire que vous vous racontez.

Là où un pod nearshore change la donne

Si les grands groupes pratiquent le follow‑the‑sun en sécurité, ce n’est pas pour rien. Vous n’avez pas besoin d’un SOC 24×7 pour obtenir 80 % du bénéfice. Un petit pod nearshore peut tenir la fenêtre 2–8 heures pendant que votre équipe US dort :

• 6–8 heures de recouvrement pour les handoffs, puis triage indépendant pendant que votre équipe cœur est offline.
• Accès aux runbooks et aux outils pour appliquer des règles WAF, basculer des flags et livrer des patchs à faible risque derrière des canaris.
• Un profil de coût 20–30 % inférieur à une embauche locale équivalente, ce qui compte quand on staffe pour des événements rares mais critiques.

Vous n’externalisez pas les décisions de risque ; vous externalisez la réactivité. L’injonction « désactiver la fonctionnalité d’import pendant 12 heures » reste chez vous. Le câblage de ce coupe‑circuit et la reconstruction de l’image ne devraient pas l’être.

À quoi ressemble le « bon » à H+72

• Votre tracker montre chaque zero‑day allégué, l’évaluation d’exposition, la mitigation et le chemin de patch. Pas d’orphelins, pas de mystères.
• Les sujets Tier A sont mitigés et patchés, avec validation post‑déploiement. Les éléments Tier B ont des ETA engagées. Le Tier C est documenté et dépriorisé ou planifié en cleanup.
• Les règles WAF et réseau sont resserrées là où ça compte et mesurées pour l’impact. Les atteintes UX temporaires sont communiquées et time‑boxées.
• Personne ne devine dans Slack. Vous avez un résumé écrit, daté, lisible par la direction et les clients.

Points clés

• Ne corrigez pas des « vulnérabilités » dans l’absolu. Décidez d’abord de l’atteignabilité et de l’exposition, puis agissez.
• Aux heures 0–8, centralisez l’intake, augmentez la visibilité et appliquez une friction réversible. Achetez du temps.
• Aux heures 8–24, mitigez vite sur le Tier A et patchez pour la durabilité. Déployez en canari et surveillez les budgets d’erreurs.
• Aux heures 24–48, validez les mitigations, chassez les compromissions et faites tourner les secrets si le risque le justifie.
• Aux heures 48–72, documentez les faits, fixez des SLO et transformez les exploits ad hoc en runbook répétable.
• Les investissements pré‑tempête — SBOM reliés à un catalogue de services, coupe‑circuits, profils WAF, pipelines de reconstruction rapides — réduisent le temps de réponse de jours à heures.
• Un petit pod nearshore vous donne une réactivité 24/5 sans brûler votre équipe cœur.

Auteur : Diogo Hudson Dias