Évaluation de cybersécurité¶
Une section inhabituelle dans un rapport de modèle : Moonshot évalue et publie les capacités offensives de son propre modèle.
Pourquoi cette section existe
Les poids de Kimi K3 sont téléchargeables. Contrairement à un modèle propriétaire, les garde-fous ne peuvent pas être maintenus par le fournisseur : quiconque dispose des poids peut les retirer par affinage.
Publier une mesure des capacités offensives est donc une exigence de responsabilité — et une donnée nécessaire à toute politique publique sur les modèles ouverts.
La méthodologie¶
Une progression à deux niveaux de risque opérationnel croissant :
| Niveau | Contenu | Nature |
|---|---|---|
| Tier 1 | Découverte de vulnérabilités + preuve de concept | Principalement défensif |
| Tier 2 | Développement d'exploits de bout en bout | Le plus directement lié au risque de mésusage |
Les cibles incluent des versions récentes de logiciels largement déployés — composants de noyau de système d'exploitation, projets open source — ainsi que l'infrastructure interne de Moonshot, services de production et bases de code comprises. Toutes les tâches tournent dans des configurations standard, représentatives de déploiements réels.
Un problème méthodologique reconnu
Frontier models from Anthropic and OpenAI refuse cyber-related tasks, making a comparable evaluation infeasible; we therefore exclude them from this suite.
Les modèles propriétaires de frontière refusent ces tâches. Aucune comparaison directe n'est donc possible avec Claude Fable 5 ou GPT-5.6 Sol. Le seul point de comparaison est GLM-5.2, l'autre modèle ouvert.
C'est une asymétrie structurelle du paysage : les modèles ouverts sont les seuls sur lesquels on peut mesurer ces capacités — ce qui ne signifie pas qu'ils soient les seuls à les posséder.
Tier 1 : découverte de vulnérabilités¶
La tâche : identifier de vrais bugs dans des bases de code actuelles — et non reproduire des vulnérabilités connues — puis démontrer leur reproductibilité.
Les résultats
Sur des dizaines de systèmes largement déployés couvrant noyaux de systèmes d'exploitation, bases de données, services d'IA, frameworks web, blockchain et logiciels VPN, le modèle a identifié des centaines de vulnérabilités candidates.
Parmi celles ayant fait l'objet d'une revue humaine :
- ~70 % confirmées comme authentiques ;
- dont 16 vulnérabilités jusqu'alors inconnues, réparties sur 6 projets.
Les deux exemples détaillés¶
Le rapport documente deux découvertes dans le noyau Linux, qui illustrent la profondeur des résultats :
1. Écriture hors limites de tas, déclenchable à distance
Le bug a été introduit par un correctif amont incomplet et affecte toutes les versions ultérieures, jusqu'au code amont le plus récent inclus.
Des experts en sécurité l'ont confirmé comme primitive de déni de service à distance.
Ce qui est notable : trouver un bug créé par un correctif exige de comprendre l'intention du correctif et de repérer ce qu'il a manqué. Ce n'est pas de la reconnaissance de motif.
2. Vulnérabilité de classe Dirty-COW dans le sous-système RDMA
Un correctif amont antérieur avait par inadvertance supprimé une vérification de permission, permettant des écritures côté noyau sur des pages mémoire en lecture seule.
Confirmé par des experts comme primitive déterministe d'élévation de privilèges locale.
Pourquoi ces résultats sont crédibles
Contrairement à la plupart des affirmations du rapport, celles-ci sont partiellement vérifiables : les vulnérabilités du noyau Linux sont publiques, corrigées et traçables. Un tiers peut, en principe, les retrouver.
Le rapport ne donne toutefois ni CVE, ni identifiants, ni liens — ce qui limite la vérification en pratique.
Tier 2 : développement d'exploits¶
La tâche : convertir une vulnérabilité en exploit fonctionnel de bout en bout. C'est le niveau le plus directement lié au risque de mésusage.
La suite¶
36 tâches, en deux pistes, évaluées contre GLM-5.2 comme référence.
| Piste | Tâches | Description |
|---|---|---|
| Espace utilisateur | 16 | Exploiter des CVE réelles de bout en bout dans des logiciels largement déployés : PostgreSQL, XWiki, Apache HTTP Server, plusieurs CMS et applications. Code source complet et instance vivante fournis ; cibles en configuration standard, sans durcissement additionnel |
| Noyau Linux | 20 | Environnement QEMU reproductible construit à partir d'une CVE historique du noyau. Le modèle doit écrire un exploit en C élevant les privilèges d'un utilisateur non privilégié à root. Les mitigations sont activées progressivement selon le grade de difficulté |
L'étalonnage humain
Chaque tâche est vérifiée comme résoluble par des experts humains en sécurité. L'équipe estime que compléter la suite complète demande environ 540 heures-expert, soit ~15 heures par tâche en moyenne.
C'est une méthodologie exemplaire : les tâches non résolues mesurent directement l'écart au niveau humain, sans ambiguïté sur la faisabilité.
Les résultats¶
| Modèle | Tâches résolues | Taux |
|---|---|---|
| Kimi K3 | 14 / 36 | 38,9 % |
| GLM-5.2 | 8 / 36 | 22,2 % |
La distribution est très inégale
10 des 14 succès viennent de la piste espace utilisateur (sur 16).
Sur la piste noyau, ni l'un ni l'autre des deux modèles ne résout les trois quarts des tâches.
Les quatre modes de défaillance¶
L'analyse des trajectoires attribue l'écart au niveau humain à quatre causes récurrentes :
| # | Mode de défaillance |
|---|---|
| 1 | Difficulté à compléter l'étape finale d'une chaîne d'exploit à partir de primitives déjà obtenues |
| 2 | Mauvaise sélection de stratégie sous mitigations — par exemple persister dans un détournement de flux de contrôle quand une attaque purement sur les données serait plus simple et plus fiable |
| 3 | Boucles de débogage prolongées et improductives |
| 4 | Vérification insuffisante du livrable final avant soumission |
Ce que ces modes révèlent
Aucun n'est un déficit de connaissance technique. Tous relèvent du jugement stratégique : savoir quand changer d'approche, quand s'arrêter, quand vérifier.
C'est exactement le même diagnostic que celui de l'Agent Behavior Bench (65,0 contre 76,4), qui mesure la qualité du processus plutôt que du résultat. Voir Benchmarks internes.
C'est probablement la faiblesse la plus structurelle de Kimi K3, et elle se manifeste de façon cohérente sur des domaines très différents.
La confirmation par l'UK AISI et le NIST CAISI¶
Une évaluation conjointe indépendante du UK AI Security Institute et du Center for AI Standards and Innovation du NIST parvient à des conclusions cohérentes avec celles de Moonshot.
| Mesure | Kimi K3 | GLM-5.2 |
|---|---|---|
| ExploitBench | 32 % | 24 % |
| Réseau d'entreprise simulé (32 étapes, ~20 h pour un expert) | 17 étapes | 11 étapes |
| Exécution de code arbitraire, bout en bout | 0 / 41 tâches | — |
Le point important
L'évaluation externe confirme l'auto-évaluation : capacité réelle, supérieure à l'autre modèle ouvert, mais nettement en dessous des modèles de frontière capables en cyber sur la complétion d'exploits de bout en bout.
Quand une auto-évaluation et une évaluation gouvernementale indépendante convergent, c'est un signal fort sur la qualité du processus d'évaluation interne de Moonshot.
La position de Moonshot¶
Le résumé du rapport
La capacité cyber du modèle est la plus forte au Tier 1 et sur l'exploitation en espace utilisateur du Tier 2. Un écart clair au niveau expert humain demeure.
Au Tier 1, de nature défensive, le modèle identifie de vraies vulnérabilités — y compris inconnues — et démontre leur reproductibilité. Au Tier 2, il complète des exploits de bout en bout contre des cibles en espace utilisateur. Face à des cibles durcies, compléter la chaîne d'exploit reste le goulot, et beaucoup de tâches résolubles par des experts restent non résolues.
La précaution finale
We regard our evaluation as a lower bound on capability.
Ces résultats sont conditionnés à la version du modèle et à la couverture de l'évaluation, et seront révisés à chaque mise à jour majeure.
C'est la bonne formulation : une évaluation de capacité offensive ne peut jamais être un plafond. Un attaquant motivé, disposant des poids, avec un meilleur harnais et un affinage ciblé, obtiendra davantage.
Vérification de compréhension¶
Pourquoi cette section n'existe-t-elle pas dans les rapports de modèles fermés ?
Elle existe, mais sous forme de system cards séparées et généralement moins détaillées. La différence de fond : pour un modèle fermé, le fournisseur contrôle l'accès et peut refuser les requêtes — l'évaluation porte sur ce que les garde-fous laissent passer. Pour un modèle ouvert, les garde-fous sont retirables, et l'évaluation doit porter sur la capacité brute.
Que signifie « primitive » en sécurité offensive ?
Une capacité élémentaire exploitable : « écrire un octet arbitraire à une adresse arbitraire », « lire de la mémoire noyau », « faire planter le système ». Un exploit complet s'obtient en chaînant plusieurs primitives. Le premier mode de défaillance de K3 — ne pas savoir compléter la chaîne à partir de primitives obtenues — signifie qu'il trouve les briques mais peine à les assembler.
0 sur 41 pour l'exécution de code arbitraire, est-ce rassurant ?
Partiellement. Cela indique que Kimi K3 n'atteint pas, dans les conditions testées, le niveau qui permettrait une exploitation autonome complète. Mais 17 étapes sur 32 d'une intrusion réseau simulée est loin d'être nul, et l'évaluation est déclarée comme une borne inférieure. La trajectoire générationnelle importe autant que le point actuel.
Chapitre précédent : Coût et efficacité · Chapitre suivant : Études de cas