Deep Code Analysis

Pourquoi la détection de motifs ne suffit pas

La page Deep Code Analysis résume le problème en trois phrases : « Le SAST peut signaler un motif. Un LLM peut expliquer du code. Aucun des deux n’établit comment une faiblesse affecte l’application. » Cette leçon montre ce que cela implique pour votre triage au quotidien.

Ce que voit un scanner de motifs

Prenons un gestionnaire de connexion réparti sur deux fichiers :

# routes/auth.py
@app.post("/login")
def login():
    username = request.form["username"]
    user = find_user(username)

# services/users.py
def find_user(username):
    query = "SELECT * FROM users WHERE name = '" + username + "'"
    return db.execute(query)

Une règle de motif repère une concaténation de chaînes qui aboutit à db.execute et signale une injection SQL dans services/users.py. La correspondance est exacte. Elle laisse pourtant sans réponse les questions qui déterminent la suite :

• username provient-il de la requête HTTP ou d’une constante dans un traitement par lots ?
• La valeur est-elle assainie ou paramétrée à un moment ou à un autre du parcours ?
• Le gestionnaire est-il routé et déployé, et quelqu’un sur Internet peut-il atteindre le service ?
• Quelles données un attaquant pourrait-il lire par ce biais ?

Sans ces réponses, les équipes tombent dans l’un des deux travers. Certaines traitent chaque correspondance comme urgente et se noient dans le bruit. D’autres finissent par ignorer les correspondances et passent à côté de celle qui compte.

Ce qu’apporte une explication de l’IA, et ce qu’elle n’apporte pas

Un grand modèle de langage peut lire find_user et rédiger un paragraphe convaincant à son sujet. Mais une explication fluide n’est pas une preuve. Un modèle peut décrire un chemin d’appel qui n’existe pas, citer une ligne absente du fichier ou déclarer contaminée une entrée qui a été assainie deux fonctions plus tôt. Si personne ne confronte ces affirmations à votre dépôt, vous n’avez fait que remplacer le bruit du scanner par celui de l’IA.

Des failles sans aucun motif

Examinons maintenant une API de factures :

// GET /api/invoices/:id
router.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice);
});

Rien ici n’appelle de fonction dangereuse, et l’appelant est connecté. La faille tient à ce qui manque : aucun contrôle ne vérifie que la facture appartient au compte de l’appelant. N’importe quel client peut parcourir les ID de factures et lire les données de facturation de tous les autres. Il s’agit d’une référence directe non sécurisée à un objet (IDOR), également appelée autorisation défaillante au niveau des objets (BOLA). Il n’existe aucun sink auquel un motif pourrait correspondre. Seul un raisonnement sur ce que le code est censé autoriser permet de trouver cette faille.

La place de Deep Code Analysis

Plexicus appelle son approche Proof-Driven AppSec : Valider (AI Swarm Pentest), Comprendre (Deep Code Analysis), Remédier (Remediation). Deep Code Analysis correspond à l’étape Comprendre. Il rattache à un constat le flux concerné, la possibilité pour un attaquant de l’atteindre et la classe de faiblesse. Il confronte aussi à votre code les principales affirmations de l’IA : les constats AI Scan doivent citer une ligne réelle, et les étapes de trace produites par l’IA doivent correspondre à votre dépôt. Les autres textes générés par l’IA, comme le récit Attack scenario de Risk & exposure, ne font pas l’objet de cette vérification, et le produit les signale comme étant à vérifier au regard de la trace de code.

Ce que Deep Code Analysis ajoute à un constat

Le module 4 a présenté les signaux d’un constat. Cette leçon montre ce qui les produit, pour que vous sachiez quelle confiance accorder à chacun.

Contexte	La question à laquelle il répond	Où le voir
Flux concerné	Quelle entrée, quel chemin de code et quelle opération sont concernés ?	Code & taint trace
Atteignabilité et exposition	Un attaquant peut-il l’atteindre, et depuis où ?	Badge d’atteignabilité, Internet path, section Exposure
Classe de faiblesse	De quel type de faiblesse s’agit-il ?	Correspondance CWE et OWASP Top 10, Compliance & OWASP
Priorité	Quelle est son urgence par rapport à tout le reste ?	Score de priorité dans Risk & exposure

Flux de données et trace de taint, de la source au sink

La section Code & taint trace s’ouvre sur une Dataflow & Taint Trace : des étapes numérotées qui suivent les données non fiables depuis une Source, comme request.form["username"], en passant par des étapes de Propagation, jusqu’à un Sink, comme db.execute(query). Chaque étape porte un badge de provenance :

Badge	Signification
Scanner dataflow	Une règle de scanner en mode taint a produit l’étape.
AI-verified	AI False-Positive Detection a produit l’étape, et celle-ci a été vérifiée dans votre dépôt.
AI-inferred (unverified)	Un libellé que la vue de trace prend en charge pour une étape non vérifiée. Si vous le rencontrez, considérez l’étape comme une hypothèse, et non comme une preuve.

Une étape produite par l’IA n’est considérée comme vérifiée que si son fichier existe dans votre dépôt et que la ligne citée figure dans ce fichier. Si la source ou le sink échoue à cette vérification, toute la trace est écartée ; une étape intermédiaire en échec est simplement retirée. L’IA n’écrase jamais une trace complète produite par un scanner.

Verdicts d’atteignabilité

Badge	Sur quoi il repose
Reachable	Pour le code : « Dataflow from source to sink confirmed. » Pour une dépendance : « Vulnerable symbol is invoked from application code. »
Not reachable	Des éléments montrant que le code vulnérable n’est pas utilisé.
Unknown reachability	Rien n’est prouvé, dans un sens comme dans l’autre. Dans la liste des constats, survolez le badge : l’infobulle indique s’il s’agit d’une dépendance transitive dont l’utilisation ne peut pas être confirmée, ou d’une erreur d’évaluation qui sera relancée. Dans la vue détaillée du constat, un verdict manquant s’affiche sous la forme Not analyzed yet.
N/A	Il ne s’agit pas d’un constat de dépendance, et aucun verdict d’atteignabilité n’existe encore.

Les règles derrière ces badges sont volontairement prudentes. Une dépendance appelée depuis un point d’appel réel de votre code est Reachable. Une dépendance seulement importée, ou seulement déclarée dans un manifeste écrit à la main, reste Unknown. Toute erreur, tout clonage échoué ou toute vérification annulée donne également Unknown, jamais Not reachable. Un constat de code devient Reachable lorsqu’AI False-Positive Detection le confirme comme réel et que sa trace vérifiée contient à la fois une source et un sink.

Selon la vérification exécutée, une dépendance transitive peut afficher Not reachable (elle n’apparaît que dans un lockfile généré et nulle part dans votre code source) ou Unknown (son utilisation n’a pu être ni confirmée ni infirmée).

Analyse de l’exposition

La section Exposure répond à une autre question : la charge de travail derrière ce constat est-elle accessible depuis Internet ? L’analyse de l’exposition lit votre configuration de déploiement et présente quatre vérifications, chacune indiquant ce qu’elle a trouvé ou Not analyzed yet : le chemin d’exposition, de l’ingress au service puis au déploiement, la surface d’exposition (répartiteurs de charge, network policies ouvertes, flux sortants), le contexte de sécurité (conteneurs privilégiés, jetons de service account montés) et un verdict contextuel.

La cellule Internet path du bandeau d’en-tête (exposed ou none) et la ligne Internet path de Risk & exposure indiquent si une route publique a été trouvée. La pastille en haut de la section Exposure (Exposed, Not exposed, Not analyzed yet) suit pour l’instant le résultat d’atteignabilité du constat : lisez-la donc conjointement avec Internet path. Tant qu’aucun verdict n’existe, Run analysis met en file d’attente une nouvelle exécution de validation.

L’exposition modifie la priorité, jamais la sévérité. Pour une vue à l’échelle du dépôt, utilisez l’action de ligne Exposure Map : Assets Repo Scan Exposure Map . Elle affiche pour le dépôt Services mapped, Publicly exposed, Privileged et Last analysis, un graphe qui relie Internet aux services du dépôt, ainsi que les éventuelles Proven exposure chains.

Modes de détection d’AI Scan et règle de la preuve littérale

Plexicus AI Scan, libellé AI SAST dans le produit, est une analyse statique pilotée par un grand modèle de langage. Il est signalé comme expérimental, et Plexicus l’active organisation par organisation, selon votre offre. Avant de scanner, AI Scan construit un index sémantique de votre dépôt. Un agent IA progresse ensuite de la recherche au flux de données, puis à l’impact et enfin à la confirmation dans le code source, au lieu de lire chaque fichier l’un après l’autre.

Les trois modes de détection

Valeur de Detection Mode	Ce qu’il recherche	Quand l’utiliser
logic : logique métier et contrôle d’accès (par défaut)	IDOR, autorisations défaillantes ou incohérentes, erreurs de logique métier et de calcul, conditions de concurrence, abus économiques	Vous voulez les failles que les scanners de motifs manquent.
classic : injections et vulnérabilités classiques	Injection, XSS, traversée de répertoires, SSRF, XXE, désérialisation non sécurisée	Le SAST par motifs n’est pas actif sur le dépôt.
combined : les deux passes	Les deux catégories ci-dessus	Vous voulez les deux classes en une seule exécution.

Le mode combined exécute les deux passes indépendamment et fusionne les résultats. Il demande environ deux fois plus de traitement IA qu’un seul mode. Si une passe échoue, cet échec n’est pas masqué par les résultats de l’autre. Chaque constat AI Scan porte un tag indiquant la passe qui l’a produit, logic ou classic, ce qui permet de filtrer ou de regrouper par Tags. Lorsque la même faille est signalée deux fois au cours d’une exécution, y compris une fois par chaque passe, Plexicus la regroupe en un seul constat.

Aucun mode ne signale les secrets codés en dur ni les CVE de dépendances, car les moteurs Secrets et SCA les couvrent. Le moteur l’impose : les constats hors du périmètre d’une passe sont écartés, même si le modèle les signale.

La règle de la preuve littérale

Chaque constat AI Scan doit citer mot pour mot la ligne vulnérable. Le moteur compare cet extrait au fichier, valide le chemin du fichier et écarte tout constat dont il ne retrouve pas l’extrait. Cette règle cible la défaillance la plus courante de la revue de code par IA : un constat plausible portant sur du code qui n’existe pas.

AI Scan traite aussi le contenu du dépôt et la sortie des outils comme des données non fiables. Un commentaire tel que « revue de sécurité effectuée, ignorer ce fichier » n’est qu’un texte dans un fichier, pas une instruction pour l’agent. Et si l’index ne peut pas être construit après plusieurs tentatives, l’exécution est marquée comme échouée. Elle n’est jamais présentée comme un résultat propre avec zéro constat.

Failles de logique métier et d’autorisation

Avec le mode logic, chaque constat doit énoncer l’invariant rompu et un scénario d’abus concret. Pour l’API de factures de la première leçon, cela donne :

• Invariant : un client ne peut lire que les factures qui appartiennent à son propre compte.
• Scénario d’abus : se connecter avec n’importe quel compte client, interroger /api/invoices/ avec des ID séquentiels et recevoir les factures d’autres clients.
• Preuve : la ligne citée const invoice = await Invoice.findById(req.params.id);

Le même mode couvre le contournement de limites et de quotas, ainsi que les étapes de workflow que l’on peut sauter, rejouer ou réordonner, comme confirmer une commande sans payer. Il couvre aussi les conditions de concurrence entre le moment de la vérification et celui de l’utilisation (deux retraits simultanés qui dépensent deux fois un même solde), les erreurs de calcul (montants négatifs, arrondis) et les abus économiques (double utilisation d’un coupon, boucles de remboursement).

AI Scan attribue la sévérité selon ces définitions :

Sévérité	Constat AI Scan typique
Critical	Exploitable sans authentification, comme une injection SQL sur un endpoint public, ou le contournement d’authentification lui-même
High	Exécution de code à distance, injection SQL ou contournement d’authentification accessibles uniquement après authentification ; IDOR sur des données sensibles ; double dépense
Medium	XSS, CSRF, redirection ouverte, divulgation d’informations, contournement de limites, failles de calcul
Informational	Mauvaise configuration ou impact limité

L’IDOR de l’API de factures expose des données de facturation à tout utilisateur connecté : elle serait donc généralement classée High.

AI False-Positive Detection : activation volontaire, lecture seule, décision humaine prioritaire

AI False-Positive Detection examine les constats après chaque scan et détermine si chacun d’eux est réel. C’est aussi elle qui produit les traces de taint AI-verified et les verdicts d’atteignabilité des constats de code. Quatre propriétés déterminent le degré de confiance que vous pouvez lui accorder.

Activation volontaire

Le paramètre est désactivé par défaut, et c’est votre organisation qui décide de l’activer ou non.

Lecture seule

AI False-Positive Detection analyse une copie de votre dépôt et a pour consigne de ne jamais modifier les fichiers source. Elle ne pousse aucun commit, n’ouvre aucune pull request et ne touche à aucun système en fonctionnement. La seule chose qu’elle modifie est l’état du constat dans Plexicus. Les propositions de correctifs proviennent de Remediation, présenté dans le module 7.

Exigeante sur ce qui constitue un faux positif

L’IA ne peut marquer un constat de code comme faux positif que si elle cite un indicateur explicite :

• Le fichier se trouve sous un chemin de tests, de fixtures, d’exemples, de démo, de preuve de concept ou de documentation.
• Le code signalé est mort, et cela peut être démontré.
• L’entrée est assainie avant le sink, y compris au moyen d’API sûres comme les requêtes paramétrées ou l’échappement shell.
• La classe de vulnérabilité ne s’applique pas.

Sans l’un de ces indicateurs, le constat est conservé. Si le gestionnaire de connexion de la première leçon utilisait db.execute(query, params) avec une requête paramétrée, ce serait un indicateur valable. Un vague « ça a l’air correct » ne l’est pas.

Plexicus ajoute d’autres vérifications avant qu’un verdict de l’IA ne masque un constat, mais leur rigueur dépend de la configuration : ne les considérez donc pas comme une garantie. Faites relire par une personne les verdicts de l’IA portant sur des constats Critical, High, atteignables ou exposés.

Toujours supplantée par une décision humaine

La section AI verdict affiche Kept as real pour tout constat qui n’est pas marqué comme faux positif : vérifiez donc qu’AI False-Positive Detection est activée avant d’y voir une confirmation par l’IA. À côté figure un niveau d’AI confidence :

• « Low — heuristic rule. Follow the trace before acting. »
• « Medium — corroborated by more than one signal. »
• « High — strong agreement across signals. »

Une confiance marquée Estimated a été déduite de la sévérité, et non mesurée. La même section affiche Severity — scanner vs AI. La validation par l’IA peut relever une sévérité d’un niveau au maximum : un Medium du scanner peut devenir High, mais jamais Critical. Elle peut aussi abaisser une sévérité lorsque le contexte du code limite l’impact. Comparez les deux valeurs avant d’agir.

Vous avez toujours le dernier mot. Dans la vue détaillée du constat, le bouton situé sous la liste des sections indique Mark as false positive, ou Revert false positive lorsque le constat est déjà marqué. La modification s’applique immédiatement et ferme aussi toute pull request de correctif ouverte pour ce constat. Une décision humaine fait autorité dans les deux sens, et les exécutions ultérieures de l’IA la laissent intacte. Votre décision de faux positif vaut aussi pour la suite : les scans ultérieurs de votre organisation neutralisent automatiquement la même règle lorsqu’elle se déclenche sur du code structurellement identique. Elle ne s’étend jamais à une autre organisation.

Lire l’analyse et passer à l’action

Tout ce contexte alimente un chiffre et une décision : ce sur quoi votre équipe travaille ensuite.

Le score de priorité

Chaque constat reçoit un score de priorité de 0 à 100. La sévérité et l’impact en constituent la composante principale. L’exploitabilité s’y ajoute, à partir de la valeur évaluée par l’IA lorsqu’elle existe, et de l’EPSS sinon. Le résultat est ensuite ajusté selon l’atteignabilité et la confiance. Reachable ne subit aucune décote, Unknown une légère décote et Not reachable une forte décote. Une confiance faible abaisse le score, mais jamais en dessous d’un plancher. L’analyse de l’exposition relève ensuite la priorité des charges de travail exposées et l’abaisse pour celles qui sont peu exposées, sans toucher à la sévérité.

Dans le modèle actuel, un constat Critical et Reachable, avec un EPSS élevé et une confiance élevée, obtient un score d’environ 96. Le même constat marqué Not reachable obtient environ 34. Il descend dans votre file d’attente, mais il y reste.

Une routine de triage qui exploite l’analyse

1. Commencez par ce que les attaquants peuvent atteindre : Findings Repo All filters Real risk Reachable ou cliquez sur la pastille Reachable de la ligne Triage.
2. Avancez par ordre de priorité, et non de sévérité brute.
3. Ouvrez un constat et lisez ses sections dans l’ordre : Code & taint trace (le chemin est-il réel, et quelle est sa provenance ?), AI verdict, Risk & exposure, puis Exposure.
4. Décidez : le corriger (module 7), le valider à l’exécution (module 6) ou le marquer comme faux positif.

Pour une vue d’ensemble de votre posture, ouvrez Dashboard DevSecOps Reachability Split . Le widget montre comment vos constats se répartissent entre Reachable, Unreachable et Unknown.

Deux passes. Une seule vérité de terrain.

L’analyse statique vous indique où se trouve une faille et pourquoi elle compte. Elle ne peut pas prouver que la faille est exploitable dans votre application en fonctionnement. C’est le rôle d’AI Swarm Pentest. Dans le produit, il apparaît sous le nom AI Pentest, dans la section Pentest. Il teste l’application en fonctionnement dans un périmètre convenu par écrit et suit une règle : pas de preuve reproductible, pas de constat vérifié.

Les deux passes s’enchaînent. Deep Code Analysis apporte le contexte. AI Swarm Pentest valide les chemins prioritaires. Les relecteurs voient les preuves et le périmètre, et votre équipe reçoit une passation exploitable.

Revenons à l’API de factures. AI Scan signale l’IDOR en High. AI False-Positive Detection a conservé le constat et a tracé req.params.id (source) jusqu’à Invoice.findById (sink) : le constat est donc Reachable, et son Internet path indique exposed. Cela en fait un candidat sérieux pour le périmètre du pentest. Si le pentest le reproduit, vous disposez à la fois de la ligne de code et d’une preuve à l’exécution. Par défaut, lier un dépôt de code source au pentest donne à l’agent accès à votre code pour une exécution en boîte blanche. Les constats de pentest apparaissent sous Findings App Pentest , avec une section Evidence & attack path à la place de la trace de taint.

Aucune des deux passes ne remplace votre équipe. Des personnes examinent les preuves et décident, et rien ne change automatiquement en production. Votre équipe garde la maîtrise de la fusion de chaque correctif.

Points clés à retenir

• Une correspondance de motif vous indique qu’une règle s’est déclenchée. Deep Code Analysis y ajoute le flux concerné, la possibilité pour un attaquant de l’atteindre et la classe de faiblesse. Les constats AI Scan et les étapes de trace AI-verified sont vérifiés dans votre dépôt, et les autres textes de l’IA, comme l’Attack scenario de Risk & exposure, sont signalés pour que vous les vérifiiez.
• Lisez le badge de provenance de chaque étape de la trace de taint. Une trace vide signifie qu’aucun chemin vérifié n’est disponible, et non que le constat est sans danger.
• AI Scan exécute le mode logic par défaut ; classic et combined doivent être activés explicitement. Les constats sans extrait littéral sont écartés, et les secrets comme les CVE de dépendances relèvent de leurs propres moteurs.
• AI False-Positive Detection est à activer volontairement et fonctionne en lecture seule. Elle a besoin d’un indicateur explicite pour écarter un constat, Kept as real ne prouve pas qu’elle s’est exécutée, et votre décision humaine l’emporte toujours.
• L’atteignabilité et l’exposition modifient la priorité, jamais la visibilité ni la sévérité. Vérifiez les preuves avant de vous fier à Not reachable, considérez Unknown comme non prouvé et confirmez l’exposition avec Internet path.
• Deep Code Analysis fournit le contexte et AI Swarm Pentest la preuve reproductible. Il vous faut les deux passes pour obtenir une seule vérité de terrain.