Disclosure tardive : 47 jours d'exploitation silencieuse

Le 15 octobre 2026, BeyondTrust a divulgué la CVE-2026-102764. L'exploitation dans la nature avait débuté le 29 août. Quarante-sept jours pendant lesquels un APT chinois opérait dans les réseaux de clients BeyondTrust — sans qu'une seule alerte publique soit émise. Ce n'est pas un bug dans la politique de divulgation de BeyondTrust. C'est la politique.

La fenêtre de 47 jours : ce que ça signifie concrètement

Quarante-sept jours, c'est 6,7 semaines. C'est le temps qu'a eu le groupe ARMORY CASTLE, nexus-Chine, anciennement UNC5221 et WARP PANDA, pour explorer les réseaux d'organisations qui n'avaient aucune raison de se méfier de leur outil de support distant. Aucun bulletin d'alerte, aucun email de BeyondTrust, aucune notification de la CISA. Rien.

Dans l'univers de la réponse aux incidents, 47 jours représentent une éternité. Selon le rapport Mandiant M-Trends 2026, le dwell time médian (temps moyen entre intrusion et détection) est de 16 jours pour les intrusions détectées en interne et de 21 jours pour celles détectées via notification externe. ARMORY CASTLE avait donc plus du double du temps médian pour s'établir, se mouvoir latéralement, comprendre l'architecture cible et exfiltrer ce qui l'intéressait.

Ce qu'un attaquant sophistiqué peut faire en 47 jours sur un réseau d'entreprise dépasse ce que la majorité des équipes de sécurité imaginent. Phase 1, jours 1 à 7 : établissement du foothold, déploiement du webshell SAWFLY, compréhension de l'environnement. Phase 2, jours 8 à 21 : énumération Active Directory, identification des ressources de haute valeur, escalade de privilèges. Phase 3, jours 22 à 40 : mouvement latéral discret, accès aux systèmes cibles, mise en place de canaux de persistance secondaires. Phase 4, jours 41 à 47 : exfiltration sélective et nettoyage des traces. Ce découpage n'est pas théorique — c'est la séquence documentée dans les rapports Mandiant sur des attaques conduites par des acteurs étatiques chinois.

Et pendant ce temps, les organisations affectées continuaient d'utiliser leur BeyondTrust normalement. Les administrateurs IT qui auraient pu détecter des anomalies ne savaient pas quoi chercher. Les SOC qui auraient pu lever des alertes n'avaient pas de signature spécifique. La fenêtre de 47 jours, c'est une fenêtre offerte aux attaquants par la décision d'un éditeur.

Pourquoi les éditeurs retardent la divulgation

La réponse courte : parce que la divulgation immédiate coûte plus qu'elle ne rapporte a l'éditeur a court terme. La réponse longue est plus nuancée, mais le résultat est le même.

L'argument de la préparation du patch est le plus souvent avancé : attendre que le correctif soit disponible avant d'alerter publiquement, pour éviter de fournir aux attaquants une roadmap sans solution. L'argument est défendable pour des vulnérabilités pas encore exploitées dans la nature. Il ne l'est plus du tout quand l'exploitation active est confirmée. Dans le cas BeyondTrust, Mandiant a documenté une première exploitation le 29 août. BeyondTrust a disposé du patch avant le 15 octobre. Il a donc existé une période où le patch était prêt mais non encore distribué a tous les clients self-hosted, pendant laquelle aucune alerte n'a été émise.

La gestion de la réputation joue un rôle majeur. Chaque divulgation de vulnérabilité critique dans un produit de sécurité est couverte par les médias spécialisés, génère des questions chez les clients existants et complexifie les cycles de vente en cours. Les équipes marketing des éditeurs de sécurité redoutent le titre "CVE critique dans un produit de sécurité exploité par des hackers". La pression interne pour retarder la divulgation jusqu'à ce que le patch soit largement distribué est réelle et documentée dans plusieurs retours d'expérience publiés par des chercheurs ayant coordonné des divulgations avec des éditeurs majeurs.

L'asymétrie d'information est structurelle. L'éditeur sait. Le client ne sait pas. Dans cette configuration, l'éditeur arbitre entre son intérêt (protéger sa réputation, préparer sa communication, distribuer discrètement le patch) et l'intérêt du client (être informé immédiatement pour prendre des décisions défensives). Sans contrainte légale forte, l'éditeur tranche systématiquement en faveur de son intérêt.

Les notifications individuelles discrètes constituent souvent la politique implicite. BeyondTrust aurait notifié un nombre limité de clients directement affectés sans émettre d'alerte générale. C'est une demi-mesure : les clients identifiés comme compromis sont avertis, les autres ne le savent pas. Cette approche protège l'éditeur d'une accusation de silence total tout en minimisant l'impact réputationnel d'une divulgation publique.

Le cadre réglementaire actuel : insuffisant

La question légitime est : existe-t-il des obligations légales de notification des clients en cas d'exploitation active d'une vulnérabilité produit ? La réponse honnête : pas vraiment, pour l'instant.

Le RGPD impose une notification sous 72 heures mais uniquement pour les violations de données personnelles. Si un attaquant exploite une faille produit sans exfiltrer de données personnelles identifiables, le RGPD ne s'applique pas. NIS2, entré en vigueur dans l'Union Européenne en octobre 2024, impose des obligations renforcées aux entités essentielles et importantes — mais ces obligations portent sur les incidents affectant l'organisation elle-même, pas sur les vulnérabilités dans ses produits commerciaux.

DORA (Digital Operational Resilience Act), applicable depuis janvier 2025 pour les entités financières, introduit des exigences de reporting des incidents ICT majeurs, mais pour les entités financières victimes, pas pour les éditeurs de logiciels en tant que fournisseurs tiers. Aux États-Unis, la Binding Operational Directive 22-01 de la CISA impose une remédiation sous 15 a 25 jours pour les CVE inscrites au KEV mais elle ne crée aucune obligation pour les éditeurs privés. Le seul mécanisme de pression efficace sur les éditeurs aujourd'hui est la réputation — et la réputation ne se dégrade que si la presse spécialisée couvre suffisamment longtemps l'incident.

Il n'existe pas non plus de standard de facto universellement adopté dans l'industrie logicielle. Le CVD (Coordinated Vulnerability Disclosure) recommandé par l'ENISA et ISO/IEC 29147 préconise une notification coordonnée mais ne contraint pas les délais de notification aux utilisateurs finaux lors d'exploitation active confirmée. La norme est descriptive, pas prescriptive.

Ce que ça change pour votre posture de sécurité

Si vous attendez qu'un éditeur vous avertisse d'une vulnérabilité critique exploitée activement dans son produit, vous avez déjà perdu. Ce n'est pas un jugement moral sur les éditeurs — c'est une constatation structurelle qui doit modifier votre modèle de menace.

Première implication : assumez la compromission possible de tous vos outils tiers de manière probabiliste. Si un éditeur opère dans un espace attractif comme la gestion des accès privilégiés, la sécurité réseau ou les outils de monitoring, il est une cible pour les acteurs étatiques. Son produit peut contenir une vulnérabilité actuellement exploitée sans que vous le sachiez. Construisez votre architecture de défense en partant de cette hypothèse.

Deuxième implication : instrumentalisez vos logs a partir de vos outils de sécurité eux-mêmes. Les équipes SOC logguent les événements générés par les outils de sécurité (EDR, SIEM, IAM) mais rarement les événements relatifs aux outils eux-mêmes : modifications de configuration, créations de comptes, accès aux API d'administration. Or ce sont précisément ces événements qui révèlent une compromission du type BeyondTrust. Votre SIEM doit ingérer les logs d'administration de vos outils de sécurité au même titre que les logs Windows ou les netflows.

Troisième implication : développez des sources d'intelligence sur les exploits actifs indépendantes des éditeurs. Les flux CERT-FR, CISA KEV, NVD et des plateformes de threat intelligence publient souvent des indicateurs d'exploitation active avant ou simultanément aux bulletins officiels des éditeurs. Traiter les alertes d'exploitation active comme des incidents de priorité 1, quelle que soit la position officielle de l'éditeur concerné, est une posture mature.

Quatrième implication : définissez un processus d'audit rétroactif. Quand une divulgation arrive tardivement, votre première question doit être "étions-nous exposés pendant cette période ?" et non "que faut-il patcher maintenant ?". Le patch est la moitié du travail. L'autre moitié est l'investigation forensique sur la période d'exploitation documentée. Pour BeyondTrust CVE-2026-102764, cette période court du 29 août au 15 octobre 2026, soit 47 jours a auditer.

Ce que devraient faire les éditeurs — et pourquoi ils ne le font pas

La solution technique est simple a énoncer : dès qu'une exploitation active est confirmée, notifier l'ensemble de la base clients dans les 24 heures, partager les IOC disponibles (hashes, patterns réseau, signatures comportementales), et activer un canal de communication dédié pour les questions de réponse aux incidents. Les clients auto-hébergés qui ne peuvent pas patcher immédiatement doivent recevoir des recommandations de mitigation concrètes et actionnables.

Ce modèle existe et fonctionne. Microsoft Security Response Center le pratique pour les zero-days activement exploités. Cisco suit un processus similaire via son PSIRT (Product Security Incident Response Team). Ces éditeurs ont compris que la transparence rapide, bien que coûteuse a court terme, construit une confiance durable avec leur base clients et réduit leur exposition légale.

La vraie question est de savoir si ce modèle peut devenir la norme sans contrainte réglementaire. Mon pronostic est négatif. Tant que les éditeurs n'auront pas d'obligation légale de notification client en cas d'exploitation active d'une vulnérabilité produit, avec des délais contraints et des sanctions effectives, la pression commerciale et réputationnelle l'emportera systématiquement sur la transparence. L'argument de la complexité opérationnelle est souvent avancé pour justifier les délais. Dans la majorité des cas, il masque simplement une décision de relations publiques.

Ce qui devrait exister : une obligation de notification sous 72 heures a tous les clients d'un produit affecté dès lors qu'une exploitation active est confirmée par une tierce partie (CERT, threat intelligence provider, forces de l'ordre). Cette obligation devrait être portée par la réglementation NIS2 ou par une extension de DORA aux fournisseurs tiers critiques. Les sanctions devraient être proportionnelles au délai de retard et au nombre de clients non notifiés.

Conclusion

La disclosure tardive n'est pas un problème technique. C'est un problème d'incitations. Les éditeurs ont aujourd'hui plus a perdre a divulguer rapidement qu'a retarder. Cette équation ne changera pas d'elle-même. Elle ne changera que sous la pression réglementaire ou sous la pression du marché, c'est-a-dire quand les clients commenceront a évaluer la politique de disclosure d'un éditeur comme critère d'achat au même titre que les fonctionnalités ou le prix. Nous n'en sommes pas encore la. Mais chaque incident comme BeyondTrust CVE-2026-102764 rapproche l'industrie de ce moment de bascule.