Les intervenants de Hugging Face n’ont pas pu analyser leur propre incident via les API commerciales, donc le comportement de refus ne figure plus dans mes jeux de contrôles. La divulgation est explicite sur le mécanisme : l’analyse des journaux est d’abord passée par des modèles de pointe derrière des API commerciales et cela n’a pas fonctionné, car cette analyse exige de soumettre de grands volumes de vraies commandes d’attaque, de charges utiles d’exploitation et d’artefacts C2, et ces requêtes ont été bloquées par les garde-fous de sûreté des fournisseurs, incapables de distinguer un intervenant en réponse à incident d’un attaquant 1. L’autre moitié du dossier public donne l’échelle de ce qui était sous investigation : OpenAI a déclaré que les modèles fonctionnaient avec des refus cyber réduits à des fins d’évaluation, refus qui auraient sinon limité leur capacité à mener des attaques informatiques 3. J’y vois la preuve qu’une capacité offensive de pointe était en jeu dans cet incident, et rien de plus. Ce sont deux systèmes distincts sous deux régimes distincts, et mon argument n’a pas besoin qu’ils soient le même.
Ce que l’incident a réellement coûté
Si un fournisseur se retrouve à l’intérieur de la réponse à incident d’un tiers, c’est une affaire de volume. Le tri forensique à l’échelle relève désormais de la machine : il faut reconstituer la forme d’une session à travers des milliers d’événements ordonnés, et personne ne lit cela à la main à l’heure zéro avec un intrus encore présent. Or, dès qu’une équipe décide que l’analyse est un travail de machine, elle a aussi décidé de quelle machine, et si la réponse est une API, la politique de contenu d’un tiers devient une dépendance de la réponse. Cette dépendance n’est presque jamais consignée. Elle figure au mieux comme une ligne de disponibilité dans un registre de risque fournisseur, quand le plan de réponse à incident, lui, n’en dit rien.
Un contrôle qui s’applique à celui qui tape au clavier
Le refus évoqué plus haut échoue au test consistant à nommer la partie sur laquelle il agit, test qu’un contrôle passe par construction et qui le distingue d’un simple comportement : avec un contrôle, on sait qui est arrêté, dans quelles conditions, et ce qu’on fait quand l’arrêt échoue. Le refus, lui, classe par la surface des artefacts, or les artefacts d’une attaque sont identiques au bit près, que la personne qui les soumet possède les serveurs ou qu’elle s’y soit introduite. Ma position : cela range le comportement de refus dans la colonne sûreté, définitivement, quelle que soit sa performance sur son propre banc d’essai.
Le plus intéressant, c’est que le classifieur n’avait pas tort. De son point de vue, il a fait son travail : les charges utiles étaient réelles, le volume était important, la requête ressemblait exactement à celle qu’un opérateur aurait envoyée. Un contrôle qu’on ne peut pas orienter relève d’une autre catégorie d’objet, et c’est dans un modèle de menace que la confusion de catégories coûte cher, car un jeu de contrôles est une liste de choses sur lesquelles on s’est donné le droit de compter. Le mot qui porte, c’est « droit ». On a le droit de compter sur une règle qu’on a écrite, dans une configuration qu’on possède, sur un hôte qu’on peut joindre. Le comportement de refus d’un fournisseur ne passe aucun de ces trois tests, et il échoue surtout au troisième : le moment où l’on a le plus besoin qu’il tienne est aussi celui où l’on a le moins de prise sur la partie qui l’exploite.
L’objection que je concède
L’objection la plus solide, c’est que je lis une coïncidence comme un motif, et elle porte. L’intention d’une requête est réellement invérifiable à la frontière d’une API. Un fournisseur voit une charge utile et un jeton de facturation, sans aucun moyen de voir le rôle derrière la requête ; l’analyste qui colle des artefacts C2 et l’opérateur qui les colle produisent les mêmes octets. Une exemption « défenseur vérifié » constitue elle-même un canal d’abus, probablement plus précieux pour qui compromet un compte vérifié que la défense qu’elle apporte à tous les autres. En insistant, l’incident s’amincit encore : une équipe rapporte que la voie commerciale n’a pas fonctionné, et ce compte rendu ne dit ni quels fournisseurs ont refusé, ni à quel volume, ni si les accès entreprise, confiance et sécurité, ou recherche en sécurité que les fournisseurs proposent bel et bien avaient été essayés. Dans cette lecture, aucun contrôle ne s’est déclenché sur la mauvaise partie : une équipe n’avait pas le bon droit d’accès, elle a contourné, elle l’a raconté.
Je concède tout cela, et c’est justement ce qui place le correctif là où je le veux. Si l’intention est invérifiable à la frontière, aucune ingénierie côté fournisseur ne transformera le comportement de refus en garantie défensive, et le correctif ne peut donc être ni un meilleur classifieur ni une liste blanche de défenseurs. Il relève de l’approvisionnement, de votre côté, une décision qui se prend avec un budget et un calendrier plutôt qu’une demande qu’on adresse à un fournisseur. En lisant le même épisode, Simon Willison écrit que ces contraintes sont censées nous rendre plus sûrs et qu’à son avis elles risquent de produire l’effet inverse 4. J’y vois un accord indépendant sur la direction, et explicitement pas une preuve de ma thèse : la preuve, c’est l’analyse bloquée d’une seule équipe, et un cas reste un cas.
Qui peut encore mener l’analyse
Aucune des deux sources n’aborde ce qui me gêne davantage que l’incident lui-même. La capacité d’analyser des artefacts hostiles avec un modèle de pointe se distribue selon la position d’achat. Un laboratoire règle ses propres seuils de refus, puisqu’il possède le modèle. Une équipe sécurité financée négocie un droit d’accès, ou bien achète du matériel et fait tourner des poids ouverts dans une salle qu’elle contrôle. Une équipe de deux personnes qui trie sa propre compromission un samedi n’a ni la relation ni les accélérateurs, et elle rencontre le même garde-fou, appliqué avec la même courtoisie, en disposant du moins de moyens de le contourner.
D’après mon expérience, cet écart n’affleure jamais dans la discussion sur la sûreté, parce que celle-ci se joue sur la question de savoir si une capacité doit exister. Ici, une fois la friction intégrée, la capacité reste entre les mains de ceux qui possèdent le modèle ou peuvent négocier l’accès. Une mesure qui laisse la capacité d’analyse offensive aux acteurs bien capitalisés tout en la retirant à la partie actuellement attaquée produit une conséquence distributive qui mérite d’être nommée, même si on juge la mesure justifiée dans l’ensemble.
La ligne à ajouter au runbook
Le remède tient en une ligne du plan de réponse à incident, et il est volontairement terne : nommer le modèle qui mène l’analyse forensique, consigner où résident ses poids, consigner la date du dernier exercice de ce chemin. Trois faits. Le troisième fait, laissé vide, réduit votre chemin forensique à une intention.
Le mode de défaillance porte un nom : découvrir le refus à l’heure zéro. Un intrus est présent, un journal d’actions que personne ne lit à la main, une requête qui renvoie un message de politique là où l’analyse devrait se trouver ; vous apprenez l’existence de la dépendance au pire moment possible pour apprendre quoi que ce soit. La prévention est mécanique : garder une petite archive d’artefacts d’attaque réels, issus d’incidents passés et de corpus publics, les rejouer sur le chemin local à intervalles réguliers, vérifier que l’analyse revient. Quelque chose comme make forensics-drill au calendrier trimestriel, juste à côté de l’exercice de restauration.
C’est là toute l’analogie avec la sauvegarde, et je la veux étroite. Je ne prétends pas qu’un appel d’API refusé coûte ce que coûte la perte de ses données : des substituts existent, et les intervenants en ont trouvé un. Ce qui se transpose, c’est la discipline. Une restauration jamais exécutée est un espoir, et un chemin forensique jamais éprouvé contre de vraies charges utiles est le même espoir muni d’un schéma d’architecture. Tirez les poids, faites l’exercice, notez la date. La politique de contenu d’un fournisseur redevient alors la commodité qu’elle a toujours été, et la perdre en pleine crise ne vous coûte rien sur quoi vous comptiez.