Anthropic fait chuter 15 milliards de dollars d'actions de cybersécurité

8 min read

Trois découvertes sur mon SaaS e-commerce. Deux que je connaissais déjà et sur lesquelles je procrastinais. Une politique RLS Supabase complètement ouverte depuis le premier jour — le genre de bug qui fonctionne parfaitement jusqu'à ce que quelqu'un décide de taquiner votre API avec un payload bien crafté.

J'ai corrigé les trois, pushé, et je suis retourné griller mes crevettes sur ma terrasse à Cancún. Puis j'ai ouvert Twitter et j'ai regardé 15 milliards de dollars s'évaporer des actions cybersécurité. CrowdStrike en baisse de 8%. Okta -9,2%. SailPoint -9,4%. Tout l'ETF cybersécurité à son plus bas depuis novembre 2023.

À cause du truc que je venais d'utiliser. Le truc qui traîne dans tous les terminaux depuis six mois.

TL;DR : Anthropic a lancé "Claude Code Security" le 20 février et fait plonger 15 milliards d'actions cybersécurité. Mais la fonctionnalité principale — /security-review — est une commande slash gratuite dans Claude Code depuis août 2025. Wall Street a paniqué en confondant scan de code et protection d'endpoints (c'est comme virer son assurance auto parce que quelqu'un a ouvert une auto-école). Le dashboard entreprise est sympa, mais la version CLI trouve déjà de vrais bugs. Je vous montre les deux, y compris comment la personnaliser pour votre stack exacte.

Anthropic Claude Code Security review command scanning code vulnerabilities cybersecurity
Quand ton IA trouve tes bugs avant Wall Street

La Commande Slash Que Personne N'a Vue Dans le Changelog (sauf moi 🤓)

/security-review

Pas de flags, pas de config, pas d'assistant d'installation.

Vous tapez ça dans Claude Code et il épluche vos changements en cours à la recherche d'injection SQL, XSS, injection de commandes, contournements d'auth, IDOR, failles de session, secrets hardcodés, et une dizaine d'autres catégories de vulns.

J'ai commencé à l'utiliser sur mes projets SaaS en septembre. Cette première découverte RLS Supabase ? Elle était là depuis quatre mois. La politique disait "allow all" sur une table qui stockait des clés API. Pas "allow authenticated". Pas "allow where user_id matches". Juste… allow all. Et ça marchait. Tous les tests passaient. Toutes les fonctionnalités se comportaient correctement. C'est ça le truc avec les bugs de sécurité — ils sont invisibles jusqu'à ce qu'ils soient catastrophiques.

Si vous avez lu mon article sur les Prompt Contracts, vous savez que je suis obsédé par les vérifications pré-déploiement. /security-review est la vérification dont je ne savais pas que j'avais besoin jusqu'à ce qu'elle trouve quelque chose avec lequel je vivais depuis des mois.

Pourquoi Je Me Soucie de la Sécurité (La Plupart des Devs S'en Foutent)

Tous les développeurs avec qui j'ai bossé pensent en fonctionnalités. Le bouton marche ? Le formulaire s'envoie ? Cool, on ship.

J'ai toujours été le relou qui pense en systèmes — qu'est-ce qui se passe quand quelqu'un envoie un JWT malformé, et si le cron job se déclenche deux fois, et si quelqu'un curl votre endpoint avec un payload que vous n'aviez pas anticipé.

Ça ne vient pas d'un diplôme d'informatique ou d'une certification sécurité. Ça vient de TryHackMe.

Je me souviens de la room exacte — c'était un CTF niveau débutant, un truc sur une app web vulnérable avec une fonctionnalité d'upload de fichiers. Le walkthrough montrait comment un path traversal dans le handler d'upload permettait d'écrire à des endroits arbitraires sur le serveur. Le dev avait validé l'extension du fichier mais pas le chemin. Erreur classique. L'attaquant a uploadé un shell PHP vers /var/www/html/ et avait un RCE complet en 40 secondes.

J'ai fermé l'onglet, ouvert mon propre projet, et trouvé exactement le même pattern dans mon handler d'upload. Pas le même code, mais la même catégorie d'erreur — valider ce qu'on attend tout en ignorant ce qu'on n'attend pas. J'ai passé la nuit à réécrire tout ce module jusqu'à ce que les crevettes refroidissent.

C'est ça le truc avec les writeups CTF. Ils ne vous apprennent pas la théorie de la sécurité. Ils vous apprennent la paranoïa. Et une fois que vous avez vu quelqu'un pop un shell via un bug que vous avez aussi, vous ne shippez plus jamais pareil.

La plupart des devs n'ont pas cette paranoïa. Ils ne devraient pas en avoir besoin. /security-review c'est la paranoïa-as-a-service.

Personnaliser le Scan pour VOTRE Stack

Le scan par défaut attrape les plus gros hits OWASP. Suffisant pour la plupart des gens. Mais si vous copiez le fichier security-review.md du repo GitHub d'Anthropic dans le répertoire .claude/commands/ de votre projet, vous débloquez quelque chose de mieux.

# .claude/commands/security-review.md
---
allowed-tools: Bash, Read, Write
description: Revue sécurité personnalisée pour PropulseCom
model: claude-opus-4-6
---
Analyser la codebase actuelle pour :
- Lacunes dans les politiques RLS Supabase (vérifier chaque table)
- Vérification signature webhook Clerk
- Routes API sans middleware d'auth
- Clés API hardcodées dans les fichiers .env.example
- Validation d'input des fonctions Convex

Ce frontmatter suffit.

Maintenant quand je lance /security-review, il ne vérifie pas juste les trucs OWASP génériques — il connaît ma stack. Clerk pour l'auth, Convex pour le backend, Supabase pour la couche base de données. Il cherche les bugs qui apparaissent dans mon architecture.

La version GitHub Action fait pareil sur chaque PR. Vous droppez anthropics/claude-code-security-review@main dans votre YAML de workflow, vous lui donnez une clé API Claude comme secret, et chaque pull request reçoit une revue sécurité avant qu'un humain la regarde. Anthropic a attrapé un RCE DNS rebinding dans leur propre codebase avec exactement cette action. Aussi attrapé un SSRF dans leur proxy de credentials interne. Les deux avant merge.

Les bugs qui empêchent les CISO de dormir, attrapés par un fichier YAML dans votre répertoire .github/workflows/.

La sécurité n'est pas une fonctionnalité qu'on shippe. C'est une surface qu'on maintient.

Cybersecurity stocks falling market crash CrowdStrike Okta SailPoint decline charts
15 milliards évaporés, mais mes crevettes étaient parfaites

Le Dashboard Entreprise (a.k.a. Pourquoi Wall Street a Paniqué)

Le 20 février, Anthropic a lancé "Claude Code Security" — la version entreprise. Dashboard, ratings de sévérité, scores de confiance, vérification multi-étapes, approbation de patch en un clic.

La grosse amélioration par rapport au CLI : il scanne votre codebase entière, pas juste les changements en cours. Et il lance une boucle d'auto-critique où le modèle essaie de réfuter ses propres découvertes avant de vous déranger. Moins de faux positifs, scores de confiance plus élevés.

Security vulnerability code review SQL injection XSS authentication bypass detection
Allow all : les deux mots qui terrorisent les CISO

La stat qui a fait s'étrangler tous les vendeurs SAST avec leur café : la red team d'Anthropic a utilisé Opus 4.6 pour trouver plus de 500 vulnérabilités haute sévérité inconnues dans des codebases open-source en production. Des bugs qui avaient survécu des années — des décennies, dans certains cas — de revue humaine et de scan traditionnel. La divulgation responsable est toujours en cours.

Cinq cents bugs. Vieux de décennies. Trouvés par un modèle qui raisonne sur le code au lieu de matcher des patterns regex.

Mais — et je veux être honnête ici — le dashboard est essentiellement une version productisée de ce que le CLI fait déjà. Si vous êtes un dev solo ou une petite équipe, la commande slash vous amène à 80% du chemin. La version entreprise ajoute la boucle de vérification et le dashboard. Ça vaut le coup si vous gérez une équipe de 50 devs. Overkill si vous shippez depuis votre appart sur un VPS Hostinger comme je l'ai décrit dans mon article Anthropic Killed My Setup.

Wall Street a Perdu 15 Milliards à Cause d'une Erreur de Catégorie

Ok c'est la partie qui m'a vraiment fait exploser de rire. Décortiquons ce qui s'est passé.

  • CrowdStrike a chuté de 8%. CrowdStrike fait de la détection et réponse d'endpoints — EDR. Ils monitent vos serveurs en cours d'exécution pour des menaces actives en temps réel. Claude Code Security scanne votre code source pour des bugs avant que vous déployiez. Ces deux trucs n'ont littéralement rien à voir l'un avec l'autre.
  • Okta a chuté de 9,2%. Okta gère l'identity management — SSO, MFA, cycle de vie utilisateur. Claude Code Security ne touche pas à l'infrastructure d'authentification. Pas même un peu.
  • Cloudflare a chuté de 8,1%. Cloudflare fait tourner des WAF, mitigation DDoS, CDN. Ils protègent votre app après qu'elle soit live. Claude revoit votre code avant qu'il shippe.
  • SailPoint a chuté de 9,4%. Identity governance. Zscaler a chuté de 5,5%. Zero-trust networking.

Aucune de ces boîtes ne fait ce que Claude Code Security fait.

TryHackMe CTF hacking challenge file upload vulnerability path traversal exploit
TryHackMe : où j'ai appris que tout peut exploser

Barclays a qualifié la vente d'"illogique". Un post sur X l'a bien résumé : les investisseurs n'arrivaient pas à différencier AppSec et sécurité d'endpoints, alors ils ont tout vendu avec "cyber" dans la description. C'est comme vendre les actions de votre plombier parce que quelqu'un a inventé un meilleur extincteur. Même maison, problème complètement différent.

Wall Street a vendu les mauvaises boîtes.

Les boîtes qui devraient vraiment suer sont les vendeurs SAST pure-play — Snyk, SonarQube, Semgrep, Checkmarx, CodeQL. Ceux qui font du scan de code basé sur des patterns. C'est ça le vrai chevauchement concurrentiel.

Mais — et c'est un gros mais — Claude ne les remplace pas aujourd'hui. L'approche basée sur le raisonnement excelle sur les failles de logique métier, contournements d'auth, et chaînes de vulnérabilités multi-fichiers que les pattern matchers ne peuvent littéralement pas voir. Mais pour les vulns chiantes et bien documentées comme l'injection SQL standard, Semgrep les attrape encore plus vite et plus fiablement.

Le vrai jeu n'est pas "Claude remplace Snyk". C'est faire tourner les deux. Pattern matching pour les bugs connus. Raisonnement IA pour les bugs que seul un humain attraperait — sauf que maintenant vous n'avez plus besoin de l'humain.

La meilleure serrure sur votre porte ne sert à rien s'il y a une fenêtre que vous avez oubliée.

Ce Que Ça Signifie Si Vous Shippez du Code Depuis Votre Appart

Vous n'avez pas d'équipe sécurité. Vous n'avez pas de CISO. Vous avez un MacBook, Claude Code, et un VPS à 5€. Bienvenue au club.

Voici toute votre stack sécurité en 2026 :

Avant chaque déploiement : tapez /security-review dans Claude Code. Prend 30 secondes. Attrape les trucs que vous êtes trop dans le mode fonctionnalité pour remarquer.

Sur chaque PR : ajoutez la GitHub Action. Coûte quelques centimes en appels API. Revoit chaque pull request avant merge.

Une fois : copiez security-review.md vers .claude/commands/ et personnalisez-le pour votre stack. Cinq minutes de setup, amélioration permanente.

C'est tout. C'est ça le budget sécurité pour un fondateur SaaS solo. Et honnêtement — mais je digresse, ça va sonner comme un flex — c'est plus que ce que la moitié des équipes "entreprise" que j'ai conseillées avaient en place il y a trois ans. Elles avaient des tickets Jira étiquetés "security review" que personne n'ouvrait jamais. Vous avez un modèle qui lit vraiment le code.

Si vous êtes le genre de dev qui n'a jamais pensé à la sécurité — sans jugement, vraiment — c'est le point d'entrée le moins effort qui existe. Vous n'avez pas besoin de comprendre OWASP. Vous n'avez pas besoin de savoir ce que IDOR veut dire. Vous tapez six mots et Claude vous dit ce qui est cassé.


La sécurité a toujours été la taxe que les devs refusent de payer. Anthropic vient de rendre le taux de taxe proche de zéro. La question n'est pas de savoir si vous allez l'utiliser. C'est combien de temps vous allez attendre avant que votre premier scan trouve quelque chose qui traîne là depuis des mois. Comme le mien l'a fait.

Si vous shippez du code avec Claude Code et que vous n'avez pas encore lancé /security-review — ce soir. Pas demain.

J'écris sur les outils et workflows que j'utilise vraiment pour shipper du SaaS depuis un serveur pas cher — les trucs que je teste en prod, pas les trucs que je lis sur Hacker News. Si votre stack sécurité aujourd'hui c'est "j'espère que personne ne trouve mes endpoints", abonnez-vous. La semaine prochaine je démonte autre chose dont personne ne parle.


Chaque semaine, je partage les leçons concrètes de construction de SaaS sécurisés — des incidents réels aux stratégies de déploiement robustes.

Rejoindre la newsletter