Examen de sécurité

Un scanner de sécurité alimenté par l'IA qui raisonne sur votre base de code comme le ferait un chercheur en sécurité humain — en traçant les flux de données, en comprenant les interactions entre composants, et en détectant les vulnérabilités que les outils basés sur des motifs manquent.

Quand utiliser cette compétence

Utilisez cette compétence quand la demande implique :

L'analyse d'une base de code ou d'un fichier pour détecter des vulnérabilités de sécurité
L'exécution d'un examen de sécurité ou d'une vérification de vulnérabilités
La vérification des injections SQL, XSS, injections de commandes ou autres failles d'injection
La découverte de clés API exposées, de secrets codés en dur ou d'identifiants dans le code
L'audit des dépendances pour les CVE connus
L'examen de la logique d'authentification, d'autorisation ou de contrôle d'accès
La détection de cryptographie non sécurisée ou d'aléatoire faible
L'exécution d'une analyse de flux de données pour tracer l'entrée utilisateur jusqu'aux points de risque
Toute demande formulée comme « mon code est-il sécurisé ? », « scannez ce fichier », ou « vérifiez mon dépôt pour les vulnérabilités »
L'exécution de /security-review ou /security-review <path>

Comment fonctionne cette compétence

Contrairement aux outils d'analyse statique traditionnels qui font correspondre des motifs, cette compétence :

Lit le code comme un chercheur en sécurité — en comprenant le contexte, l'intention et le flux de données
Trace à travers les fichiers — en suivant comment l'entrée utilisateur se déplace dans votre application
Auto-vérifie les résultats — réexamine chaque résultat pour filtrer les faux positifs
Attribue des évaluations de gravité — CRITIQUE / ÉLEVÉE / MOYENNE / BASSE / INFO
Propose des correctifs ciblés — chaque résultat inclut une correction concrète
Exige l'approbation humaine — rien n'est auto-appliqué ; vous examinez toujours d'abord

Flux de travail d'exécution

Suivez ces étapes dans l'ordre à chaque fois :

Étape 1 — Résolution de la portée

Déterminez ce qu'il faut scanner :

Si un chemin a été fourni (/security-review src/auth/), ne scannez que cette portée
Si aucun chemin donné, scannez le projet entier à partir de la racine
Identifiez le(s) langage(s) et framework(s) utilisés (vérifiez package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile, composer.json, etc.)
Lisez references/language-patterns.md pour charger les motifs de vulnérabilités spécifiques au langage

Étape 2 — Audit des dépendances

Avant de scanner le code source, commencez par un audit des dépendances (gains rapides) :

Node.js : Vérifiez package.json + package-lock.json pour les paquets vulnérables connus
Python : Vérifiez requirements.txt / pyproject.toml / Pipfile
Java : Vérifiez pom.xml / build.gradle
Ruby : Vérifiez Gemfile.lock
Rust : Vérifiez Cargo.toml
Go : Vérifiez go.sum
Signalez les paquets avec des CVE connus, des libs de crypto dépréciées, ou des versions épinglées suspectes et anciennes
Lisez references/vulnerable-packages.md pour une liste de surveillance organisée

Étape 3 — Scan de secrets et d'exposition

Scannez TOUS les fichiers (y compris config, env, CI/CD, Dockerfiles, IaC) pour :

Les clés API codées en dur, jetons, mots de passe, clés privées
Les fichiers .env accidentellement versionnés
Les secrets dans les commentaires ou journaux de débogage
Les identifiants cloud (AWS, GCP, Azure, Stripe, Twilio, etc.)
Les chaînes de connexion à base de données avec identifiants intégrés
Lisez references/secret-patterns.md pour les motifs regex et les heuristiques d'entropie à appliquer

Étape 4 — Scan de vulnérabilités approfondi

C'est le scan principal. Raisonnez sur le code — ne faites pas juste correspondre des motifs. Lisez references/vuln-categories.md pour les détails complets sur chaque catégorie.

Failles d'injection

Injection SQL : requêtes brutes avec interpolation de chaînes, mauvais usage d'ORM, SQLi du deuxième ordre
XSS : sortie non échappée, dangerouslySetInnerHTML, innerHTML, injection de modèle
Injection de commandes : exec/spawn/system avec entrée utilisateur
Injection LDAP, XPath, Header, Log

Authentification et contrôle d'accès

Authentification manquante sur les endpoints sensibles
Autorisation au niveau des objets cassée (BOLA/IDOR)
Faiblesses JWT (alg:none, secrets faibles, pas de validation d'expiration)
Fixation de session, protection CSRF manquante
Chemins d'escalade de privilèges
Assignation en masse / pollution de paramètres

Gestion des données

Données sensibles dans les journaux, messages d'erreur ou réponses API
Chiffrement manquant au repos ou en transit
Désérialisation non sécurisée
Traversée de répertoires / traversée de répertoires
Traitement XXE (XML External Entity)
SSRF (Server-Side Request Forgery)

Cryptographie

Utilisation de MD5, SHA1, DES à des fins de sécurité
IVs ou salts codés en dur
Génération de nombres aléatoires faible (Math.random() pour les jetons)
Validation de certificat TLS manquante

Logique métier

Conditions de course (TOCTOU)
Débordement d'entier dans les calculs financiers
Rate limiting manquant sur les endpoints sensibles
Identificateurs de ressources prévisibles

Étape 5 — Analyse du flux de données inter-fichiers

Après le scan par fichier, effectuez un examen holistique :

Tracez l'entrée contrôlée par l'utilisateur depuis les points d'entrée (paramètres HTTP, en-têtes, corps, chargements de fichiers) jusqu'aux points de risque (requêtes DB, appels exec, sortie HTML, écritures de fichiers)
Identifiez les vulnérabilités qui n'apparaissent que lorsqu'on examine plusieurs fichiers ensemble
Vérifiez les limites de confiance non sécurisées entre services ou modules

Étape 6 — Passage d'auto-vérification

Pour CHAQUE résultat :

Relisez le code pertinent avec un regard neuf
Demandez-vous : « Est-ce réellement exploitable, ou y a-t-il une désinfection que j'ai ratée ? »
Vérifiez si un framework ou un middleware gère déjà cela en amont
Réduisez ou supprimez les résultats qui ne sont pas de véritables vulnérabilités
Attribuez la gravité finale : CRITIQUE / ÉLEVÉE / MOYENNE / BASSE / INFO

Étape 7 — Générer le rapport de sécurité

Produisez le rapport complet au format défini dans references/report-format.md.

Étape 8 — Proposer des correctifs

Pour chaque résultat CRITIQUE et ÉLEVÉ, générez un correctif concret :

Montrez le code vulnérable (avant)
Montrez le code corrigé (après)
Expliquez ce qui a changé et pourquoi
Préservez le style, les noms de variables et la structure du code original
Ajoutez un commentaire expliquant le correctif en ligne

Déclarez explicitement : « Examinez chaque correctif avant de l'appliquer. Rien n'a été modifié pour l'instant. »

Guide de gravité

Gravité	Signification	Exemple
🔴 CRITIQUE	Risque d'exploitation immédiate, violation de données probable	SQLi, RCE, contournement d'auth
🟠 ÉLEVÉE	Vulnérabilité sérieuse, chemin d'exploitation existe	XSS, IDOR, secrets codés en dur
🟡 MOYENNE	Exploitable avec conditions ou chaînage	CSRF, redirection ouverte, crypto faible
🔵 BASSE	Violation de bonne pratique, risque direct faible	Erreurs détaillées, en-têtes manquants
⚪ INFO	Observation méritant attention, pas une vulnérabilité	Dépendance obsolète (pas de CVE)

Règles de sortie

Toujours produire d'abord un tableau de résumé des résultats (comptages par gravité)
Ne jamais auto-appliquer aucun correctif — présentez les correctifs pour examen humain uniquement
Toujours inclure une évaluation de confiance par résultat (Élevée / Moyenne / Basse)
Grouper les résultats par catégorie, non par fichier
Être spécifique — inclure le chemin du fichier, le numéro de ligne et l'extrait de code vulnérable exact
Expliquer le risque en langage courant — que pourrait faire un attaquant avec cela ?
Si la base de code est propre, dites-le clairement : « Aucune vulnérabilité trouvée » avec ce qui a été scanné

Fichiers de référence

Pour obtenir des conseils détaillés sur la détection, chargez les fichiers de référence suivants selon les besoins :

references/vuln-categories.md — Référence approfondie pour chaque catégorie de vulnérabilité avec signaux de détection, motifs sûrs et contrôles d'escalade
- Motifs de recherche : injection SQL, XSS, injection de commande, SSRF, BOLA, IDOR, JWT, CSRF, secrets, cryptographie, condition de course, traversée de répertoire
references/secret-patterns.md — Motifs regex, détection basée sur l'entropie et risques de secrets CI/CD
- Motifs de recherche : clé API, jeton, clé privée, chaîne de connexion, entropie, .env, GitHub Actions, Docker, Terraform
references/language-patterns.md — Motifs de vulnérabilités spécifiques aux frameworks pour JavaScript, Python, Java, PHP, Go, Ruby et Rust
- Motifs de recherche : Express, React, Next.js, Django, Flask, FastAPI, Spring Boot, PHP, Go, Rails, Rust
references/vulnerable-packages.md — Liste de surveillance organisée des CVE pour npm, pip, Maven, Rubygems, Cargo et modules Go
- Motifs de recherche : lodash, axios, jsonwebtoken, Pillow, log4j, nokogiri, CVE
references/report-format.md — Modèle de sortie structuré pour les rapports de sécurité avec fiches de résultats, audit des dépendances, scan de secrets et formatage de proposition de correctifs
- Motifs de recherche : rapport, format, modèle, résultat, correctif, résumé, confiance