Cognition lance Devin Security 2.0 et distribue des centaines de millions de dollars de crédits

Cognition a publié Devin Security 2.0, un produit qui accompagne une vulnérabilité de sa détection jusqu'à une pull request vérifiée. Il repose sur un scan piloté par Claude Mythos et d'autres modèles frontier dédiés à la cybersécurité, sur une priorisation fondée sur le modèle de menaces de chaque entreprise et sur des correctifs autonomes. Avec cette version, Cognition promet des crédits Devin de plusieurs centaines de millions de dollars : des scans gratuits pour les clients entreprise actuels et futurs, et des crédits pour les nouveaux clients afin de colmater leurs failles les plus critiques.

Pourquoi la file d'attente des vulnérabilités compte désormais plus

que les vulnérabilités elles-mêmes

L'entreprise justifie ce lancement par des événements récents. La semaine dernière, les projets PHP et Node.js ont divulgué des vulnérabilités d'exécution de code à distance. Toutes les entreprises utilisant ces stacks se sont retrouvées dans la même situation : un chemin d'exploitation public, des attaquants qui lisent le même advisory, et des correctifs à déployer dans des images de conteneurs, des paquets système, des pipelines CI et des configurations d'infrastructure répartis sur des dizaines de dépôts.

Cognition analyse par ailleurs l'exploit PHP2Shell. Les signes de l'un des problèmes sous-jacents avaient été repérés dès 2024, mais les mainteneurs n'avaient pas trouvé de chemin concret vers une RCE. Le correctif s'est enlisé entre compromis de compatibilité, manque de ressources et désaccords sur l'approche, tandis que des bugs plus évidents passaient en priorité. Selon Wiz, des modèles frontier ont aidé des chercheurs à assembler et à adapter en quelques heures des exploits fonctionnels pour plusieurs applications. La conclusion est inconfortable : les backlogs peuvent contenir de nombreux bugs mis de côté que l'IA a rendus exploitables en pratique.

En parallèle, l'IA gonfle le flux entrant. Daniel Stenberg, mainteneur de curl, l'a décrit comme un « volume élevé pour une qualité élevée ». Selon les données du projet au 22 octobre 2026, curl compte déjà 356 rapports, contre 181 sur toute l'année 2025. À titre de comparaison, il en avait reçu 86 en 2024 et 102 en 2023.

Comment fonctionne le pipeline de Devin Security

Le scan repose sur l'architecture Agentic MapReduce, indépendante du modèle. Les modèles frontier sont mobilisés pour les dépôts les plus critiques ; pour les autres, on peut choisir des modèles moins coûteux. Le processus se déroule en cinq étapes :

• Plan : l'agent confronte le dépôt au modèle de menaces et rédige des règles pour le code sensible : routes, frontières d'autorisation, accès aux données, désérialisation, appels d'API dangereux. • Shard : le code sélectionné est découpé en groupes. • Map : des agents distincts explorent les groupes en parallèle. • Reduce : les résultats sont agrégés, les doublons supprimés, et les trouvailles qui forment ensemble une chaîne d'attaque plus grave sont reliées. • Verify : les cas prioritaires sont vérifiés en sandbox sur une instance en fonctionnement de l'application.

Ensuite, on peut confier les trouvailles à Devin une par une ou par lots. Il les confronte au code actuel, regroupe celles qu'un seul correctif suffit à traiter, et lance des sessions indépendantes, chacune avec sa propre machine virtuelle. Devin y démarre les services réels, reproduit le problème, écrit un correctif ciblé, exécute le test de reproduction et les tests existants, puis ouvre une PR accompagnée des résultats de l'enquête.

La trouvaille reste ouverte tant que la PR n'est pas fusionnée et que Devin ne s'est pas assuré que le chemin d'attaque est fermé. Si le correctif définitif est encore en préparation, l'agent peut, lorsque l'accès est configuré, poser temporairement une règle WAF, modifier un security group ou fermer l'accès public à un service.

Un modèle de menaces plutôt qu'un simple score CVSS

La priorité dépend de plusieurs questions : le code vulnérable est-il atteignable depuis une entrée non fiable, via quelle frontière de confiance, faut-il une authentification ou une configuration particulière, le code est-il actif ? Il faut aussi mesurer ce que l'impact signifie pour l'entreprise : lecture des données d'autrui, escalade jusqu'au statut d'administrateur de l'organisation, utilisation du produit sans payer. Devin rassemble les réponses dans un modèle de menaces avec l'équipe : services, hôtes, politiques réseau, flux de données, frontières de confiance. Une partie se lit dans le code et les définitions d'infrastructure ; une autre, comme la région d'un service ou l'accessibilité d'un outil interne depuis Internet, ne s'y trouve pas. Le travail est donc collaboratif.

La vérification reste nécessaire, même avec des modèles puissants. Selon le bilan d'Anthropic Glasswing, sur 1752 trouvailles initialement jugées high ou critical, 90,6 % se sont révélées de vraies vulnérabilités, mais seules 62,4 % ont été confirmées comme high ou critical. Trouver un bug et en évaluer correctement la gravité sont deux tâches différentes.

Le même processus s'applique à l'existant : Devin importe les trouvailles de Snyk, de Wiz, de fichiers CSV et de rapports de bug bounty, en conservant les identifiants et les liens d'origine. Des sessions parallèles les revérifient sur le code actuel, cherchent les doublons et déterminent si le problème n'a pas déjà été corrigé. Les décisions de clôture et de réouverture sont resynchronisées avec les outils pris en charge. On peut aussi revérifier d'anciens rapports produits par des modèles d'IA plus faibles.

La conformité constitue un scénario à part. Pour FedRAMP, PCI DSS et les politiques internes, une trouvaille high ou critical déclenche le décompte du délai de correction, et le risque ne peut être abaissé qu'avec une documentation à l'appui. Pour chaque trouvaille réévaluée, Devin conserve le CVSS d'origine et rédige une justification selon six axes :

• atteignabilité : une entrée non fiable peut-elle atteindre le code ; • authentification : quels droits sont nécessaires ; • données : ce qui peut être divulgué ou modifié ; • frontières de confiance : quelle frontière il faudrait franchir ; • validation : ce qui a été tenté et ce qui a été observé, y compris les résultats peu concluants ; • source : d'où provient la trouvaille.

Un humain valide la conclusion et l'exporte vers un POA&M ou un système GRC. Devin ne réévalue pas les vulnérabilités du catalogue CISA KEV.

Par où commencer pour une équipe de sécurité

Le minimum pragmatique : rassembler en un seul endroit le backlog accumulé de Snyk, de Wiz et du bug bounty, puis le revérifier sur le code actuel sans se fier aux anciennes évaluations. Il convient en parallèle de formaliser un modèle de menaces : sans lui, toute priorisation automatique reste une conjecture. Pour les dépôts critiques, il est judicieux de lancer un scan avec un modèle puissant tant que les scans gratuits de Cognition restent disponibles, et de laisser tous les correctifs à la relecture humaine.

Cognition s'attend à ce que le « premier kilomètre » de la réponse aux incidents se passe bientôt sans humain. Alex Stamos, responsable de la sécurité de l'entreprise, doit présenter l'état des menaces lors d'une rencontre le 26 octobre à 10:30, heure du Pacifique.