Cybersécurité

Black Hat 2026 : ce qu’ont défendu les keynotes

Black Hat USA 2026 a parlé économie, pas exploits : quand l’attaque ne coûte presque rien, le seul levier est de rendre des classes entières de bugs impossibles, pas détectables.

— Nodal Studio

L’argument de Weston, formalisé

Selon Weston, le prix des contrôles de sécurité est fixé par rapport à une courbe implicite du coût de l’attaque, et cette courbe s’est déplacée. Autrement dit :

  • Soit c le coût marginal, pour l’attaquant, de trouver une vulnérabilité et de la transformer en arme, et d le coût marginal, pour le défenseur, d’en corriger une.
  • Corriger et détecter est rationnel quand c ≫ d : les attaquants trouvent peu de bugs, les défenseurs suivent le rythme.
  • La découverte agentique fait s’effondrer c. Le chiffre de Microsoft : 3,61 $ par PoC. La découverte d’Anthropic dans OpenBSD : < 20 000 $ au total. d n’a pas bougé : il faut toujours un humain pour comprendre, corriger, tester et livrer.
  • Quand c < d, corriger plus vite ne permet pas de gagner. Les seuls leviers qui changent l’équation réduisent le nombre de bugs à corriger plutôt que le temps de correction : éliminer des classes de bugs (sûreté mémoire), prouver leur absence (vérification formelle) ou faire chuter d vers c (remédiation automatisée).

Les chiffres de volume du MSRC – neuf fois celui de mars, avec un doublement toutes les six semaines – vont dans ce sens. Il en va de même des 202 correctifs pour 26 153 signalements du registre de Glasswing (voir Vingt-six mille signalements, deux cents correctifs) : le même goulot d’étranglement, observé du côté de celui qui trouve plutôt que de celui qui défend. L’image qu’emploie Weston lui-même pour décrire l’approche « corriger et détecter » dans ces conditions : écoper un bateau qui coule avec un dé à coudre.

L’argument économique en faveur de la sûreté mémoire quand le coût de découverte → 0

L’objection historique à la réécriture dans des langages sûrs en mémoire a toujours été le coût : la réécriture est chère, les bugs qu’elle évite sont rares, et les corriger revient moins cher. L’argument de Weston fait tomber la deuxième et la troisième prémisse :

  • Si les bugs de sûreté mémoire sont trouvés à un rythme industriel, « rares » ne tient plus.
  • Si chacun coûte un cycle de correction complet alors que la PoC d’un attaquant coûte 3,61 $, corriger n’est pas moins cher.
  • Le coût de la réécriture n’a pas changé ; ce qui a changé, c’est le coût de ne pas réécrire.

Deux réserves, en toute honnêteté :

  1. La sûreté mémoire n’élimine qu’une classe de bugs. La faille de validation de certificats de wolfSSL (voir Ce que Mythos a vraiment trouvé) est une erreur de logique qu’un langage sûr en mémoire n’aurait pas empêchée. La part des bugs graves liés à la sûreté mémoire est historiquement élevée (≈60–70 %) dans le logiciel système en C/C++, et bien plus faible dans le code applicatif.
  2. Les réécritures introduisent de nouveaux bugs. La période de transition se traduit par une augmentation nette de la surface d’attaque – et un agent chasseur de bugs les trouvera aussi.

La vérification formelle passe-t-elle à l’échelle hors d’un noyau ?

La vérification formelle a fait ses preuves sur des composants petits et à forte valeur : seL4, CompCert, des primitives cryptographiques vérifiées (HACL*, Fiat Crypto), des parties des plans de contrôle d’AWS et d’Azure. Leurs points communs : une spécification stable, une base de code bornée et un propriétaire prêt à financer l’ingénierie de la preuve à un coût maintes fois supérieur à celui du code.

Ce qui plaide pour un changement :

  • La même capacité agentique qui trouve des bugs peut, en principe, écrire des preuves ; plusieurs laboratoires ont montré des modèles produisant des preuves Lean ou Coq vérifiées par machine pour des propriétés non triviales. Si le coût de la preuve baisse au même rythme que celui de la découverte, l’équation économique change.
  • La vérification par propriétés et la vérification bornée (model checking, exécution symbolique bornée) se situent entre le test et la preuve complète, et s’appliquent plus largement.

Ce qui plaide contre :

  • La plupart des logiciels n’ont pas de spécification, stable ou non. Vérifier une application web par rapport à une spécification qui change chaque semaine relève d’un problème de spécification, pas de preuve.
  • Un composant vérifié ne vaut que ce que valent le code non vérifié qui l’appelle et les hypothèses que la preuve fait sur l’environnement. Les agents de l’affaire Hugging Face n’ont cassé aucun composant vérifié : ils ont utilisé Artifactory exactement comme prévu.

Périmètre réaliste à court terme : noyaux, hyperviseurs, cryptographie et parseurs d’entrées hostiles vérifiés et, dernier venu, le code du harness qui fait l’intermédiaire entre un agent et ses outils (voir Votre framework d’agents est la surface d’attaque). Pour tout le reste : sûreté mémoire et confinement.

L’apport de Shoshitaishvili

Moins citable que Weston, sans doute plus utile pour les praticiens :

  • Le déplacement des compétences. La compétence humaine rare n’est plus de « savoir trouver le bug », mais de « savoir concevoir le pipeline qui trouve, valide et hiérarchise les bugs sans générer de bruit ». Les trois facteurs qu’il a cités pour distinguer les agents qui augmentent l’impact de ceux qui augmentent le volume : la compréhension du modèle de menace, le jugement sur les jeux de données et la conception de l’évaluation.
  • Des flux de travail qui connaissent les propriétés des vulnérabilités. L’exemple du noyau : apprendre au processus ce qui fait d’une découverte une élévation locale de privilèges (et pas seulement un plantage) l’a fait passer de centaines de candidats à bien plus d’un millier de LPE exploitables, soit un bond d’un ordre de grandeur. Indicatif, pas contrôlé ; il l’a dit explicitement.
  • Le traitement responsable comme facteur limitant. Le même constat que dans Vingt-six mille signalements, deux cents correctifs, vu du côté de la découverte : c’est la capacité du système à absorber les signalements, et non à les produire, qui fixe le rythme utile.

Le compte rendu de WhoisXML API résume bien l’ensemble : d’une keynote à l’autre, « la vitesse revenait sans cesse comme un problème, et le jugement, sans cesse, comme un élément de réponse ».

Chiffres et contexte de la conférence

  • 121 présentations ; 35 directement liées à la sécurité de l’IA, au red teaming ou à l’offensive assistée par LLM.
  • Session d’ouverture (mardi 4 août), « Cyber Power in the Age of AI » : Sean Cairncross (directeur national de la cybersécurité), Nick Andersen (CISA, par intérim), Brett Leatherman (division cyber du FBI), Katherine Sutton (département de la Guerre). Voir quatre hauts responsables américains sur la scène d’ouverture en dit long, en soi, sur l’endroit où se fixent les priorités.
  • Également au programme, et traités dans cette série : le retour d’expérience d’OpenAI sur Hugging Face (voir Ce qui s’est passé chez Hugging Face, et pourquoi OpenAI a parlé de coup de semonce) ; la divulgation de Novee sur les agents de programmation et la présentation sur les frameworks d’agents (voir Votre framework d’agents est la surface d’attaque) ; l’intervention du programme CVE sur l’automatisation (voir Vingt-six mille signalements, deux cents correctifs) ; un résultat Rowhammer contre des GPU NVIDIA ; une session de Forrester sur la réglementation de l’IA (le sujet de notre article du 20 octobre).

Sources

Revenir à la lecture rapide (3 min).

À lire aussi