Les fondamentaux de Proof-Driven AppSec

Pourquoi le volume d’alertes ne fait pas la sécurité

La plupart des programmes de sécurité applicative savent dire combien d’alertes ils comptent. Bien moins nombreux sont ceux qui savent dire lesquelles un attaquant peut réellement exploiter, ce que chacune affecte et si le correctif a bien été livré. Ce cours part de cet écart, car le reste de la plateforme est conçu pour le combler.

Un nombre d’alertes mesure combien d’outils vous utilisez et combien de règles ils appliquent. Il ne mesure pas le risque. Quatre problèmes expliquent cette différence.

La prolifération des outils

Les équipes ajoutent généralement leurs outils une catégorie à la fois : un analyseur statique pour le code, un contrôleur de dépendances, un scanner de secrets, un outil de contrôle de l’infrastructure as code, un scanner d’images de conteneurs. Chacun a sa propre console, sa propre échelle de sévérité et son propre format de sortie. La même dépendance vulnérable peut apparaître dans deux ou trois d’entre eux sous des noms et des sévérités différents, et personne n’est responsable de la vue consolidée. Les ingénieurs finissent par réconcilier des exports au lieu de corriger du code.

Plexicus regroupe les résultats des scanners dans un format de constat unique et les déduplique ; le constat conservé garde la sévérité la plus élevée parmi ses doublons. Vous pouvez aussi importer dans ce même workflow les résultats de scanners tiers compatibles (par exemple au format SARIF). Le module 3 couvre les moteurs, la couverture et la règle exacte de déduplication.

Le bruit

Prenons un résultat d’analyse statique intitulé « injection SQL possible dans le gestionnaire de connexion ». Il peut s’agir d’une faille réelle et exploitable dans le formulaire de connexion, où le nom d’utilisateur est injecté directement dans une chaîne de requête. Il peut aussi s’agir d’une requête construite à partir d’une constante dans un utilitaire de test, qu’aucune entrée utilisateur ne peut jamais atteindre. Les deux arrivent avec le même libellé et souvent la même sévérité.

Lorsque la plupart des alertes relèvent du second cas, les développeurs apprennent à survoler la liste, et les vraies alertes sont survolées elles aussi. Ce qui distingue les deux cas, ce sont les preuves : existe-t-il un chemin entre une entrée contrôlée par l’attaquant et le code vulnérable, ce code est-il seulement atteignable, et une seconde vérification indépendante confirme-t-elle le résultat ?

Le goulet d’étranglement de la remédiation

Détecter n’est pas corriger. Chaque constat ouvert est du travail que votre équipe doit encore fournir. Trouver un nouveau problème coûte peu. Le corriger exige un développeur qui comprend le code, une modification qui ne casse rien, une revue et une fusion. Si la file d’attente grossit plus vite que l’équipe ne la résorbe, davantage de détection alourdit le backlog sans rendre l’application plus sûre. Le véritable goulet d’étranglement, ce sont le contexte et des modifications prêtes à être relues, pas un manque d’alertes.

L’absence de visibilité sur la posture

Essayez de répondre à ces questions à partir d’une liste brute d’alertes. Quels sont les trois dépôts qui concentrent le plus de risque exploitable ? Fermez-vous les constats plus vite que vous n’en créez ? Combien de temps un constat critique reste-t-il ouvert ? Une pile d’alertes qui ne cesse de grossir ne permet de répondre à aucune de ces questions. La direction voit un chiffre qui ne fait qu’augmenter, et l’audit suivant retrouve les mêmes problèmes.

Scanner plus souvent se heurte à la même limite. Un scan nocturne qui signale pendant un mois la même injection SQL non corrigée mesure une activité, pas un progrès. La fréquence des scans indique combien de fois vous avez regardé, pas si quoi que ce soit est devenu plus sûr.

Le Dashboard de Plexicus suit la même logique : ses totaux ne comptabilisent que le travail encore ouvert (module 2). L’onglet CISO affiche un Risk Posture Score, New vs Fixed et Top Risky Repositories. L’onglet DevSecOps y ajoute l’atteignabilité, l’âge des constats et la vitesse de remédiation.

La boucle Proof-Driven : Valider, Comprendre, Remédier

Plexicus appelle son approche Proof-Driven AppSec : savoir ce qui est réel, comprendre ce que cela affecte, corriger avec des preuves. L’approche comporte trois étapes, et chaque étape correspond à un produit.

Étape	Produit	Question à laquelle elle répond	Ce que vous obtenez
Valider	AI Swarm Pentest	Est-ce réellement exploitable dans le périmètre autorisé ?	Des constats vérifiés, avec des preuves reproductibles, une priorité et une passation documentée
Comprendre	Deep Code Analysis	Quel code, quelles données et quel flux métier sont concernés, et un attaquant peut-il les atteindre ?	Le flux concerné, son atteignabilité et son exposition, une classe de faiblesse CWE et une priorité
Remédier	Remediation	Quelle modification permet de le clore, et a-t-elle fonctionné ?	Une modification prête à relire, avec les preuves jointes, livrée via votre workflow de pull requests, ainsi que des re-tests de vérification lorsqu’ils sont configurés

Valider avec AI Swarm Pentest

AI Swarm Pentest est une mission autorisée, au périmètre défini, menée sur une application, une API, du code source ou un environnement de test. Des vérifications IA coordonnées cartographient la surface d’attaque, formulent des hypothèses et testent des chemins, puis une seconde passe confirme chaque constat de manière indépendante avant qu’il soit marqué comme vérifié. Ce n’est ni un scanner à signatures ni un chatbot de sécurité. Dans le produit, il apparaît sous le nom AI Pentest, dans la section Pentest. Le module 6 le traite en détail.

Comprendre avec Deep Code Analysis

Une règle d’analyse statique peut signaler un motif, et un modèle de langage peut expliquer du code. Ni l’un ni l’autre n’établit comment une faiblesse affecte votre application. Deep Code Analysis relie un constat au code, au flux de données et à l’impact métier. Pour chaque constat, vous obtenez le flux concerné (source, propagation et sink), la possibilité pour un attaquant de l’atteindre et depuis où (atteignabilité et exposition à Internet), ainsi qu’une classe de faiblesse mise en correspondance avec CWE et OWASP. Le module 5 y est consacré.

Remédier avec Remediation

Une fois un constat vérifié, Remediation prépare le contexte et une proposition de modification sous la forme d’un diff prêt à relire. Votre équipe l’examine et décide de le fusionner ou non. Lorsque la pull request est fusionnée, Plexicus marque le constat comme Fixed. Selon votre offre et votre configuration, un test de vérification peut contrôler le correctif avant l’ouverture de la pull request, et pour un constat de pentest, vous pouvez relancer le scan de l’évaluation pour vérifier que le chemin est bien fermé. Le module 7 présente ce workflow.

La place de XBOM et de Plexicus Automation

Deux produits fonctionnent en parallèle de la boucle plutôt qu’au sein d’une étape :

• XBOM est un inventaire unique des composants logiciels (SBOM), des actifs cryptographiques (CBOM) et des modèles d’IA (AIBOM), avec des déclarations VEX qui indiquent si une vulnérabilité connue vous affecte. Il répond à des questions comme « où livrons-nous la version vulnérable de cette bibliothèque ? » et produit des preuves pour les audits. Le module 8 le présente.
• Plexicus Automation achemine les constats vers des correctifs, des tickets, des validations et des notifications, par exemple lorsqu’un constat est créé, enrichi ou rouvert. Seuls les administrateurs peuvent activer un flux. Le module 9 le présente.

Le SAST, la SCA, les contrôles d’infrastructure as code, la détection de secrets et les résultats de scanners importés apportent une couverture complémentaire. Ils fournissent des signaux qui alimentent la boucle. Ils ne la remplacent pas.

L’exigence de preuve et ses garde-fous

La règle qui sous-tend chaque livrable Plexicus tient en une ligne : pas de preuve reproductible, pas de constat vérifié. Cette leçon explique ce qui constitue une preuve, comment un signal devient un constat vérifié, et quels sont les quatre garde-fous qui maintiennent une mission dans les limites convenues.

Une preuve reproductible

Chaque constat d’un livrable AI Swarm Pentest s’accompagne de preuves qu’un tiers peut reproduire : la requête, la réponse, les étapes et l’impact démontré. « Le scanner l’a dit » n’est pas une preuve. Dans le produit, les constats de pentest peuvent inclure une preuve de concept rejouable, comme une commande cURL, un script shell ou une capture HAR. Elle s’affiche exactement telle qu’elle a été enregistrée et n’est pas réexécutée depuis votre navigateur.

Une vérification indépendante

Un signal ne devient pas un constat vérifié parce qu’une seule vérification l’affirme. Une seconde passe doit confirmer de manière indépendante le comportement observé.

Étape	Ce que cela signifie	Ce qui se passe ensuite
Constat candidat	Une hypothèse a produit un signal assorti d’un contexte technique	Il passe en vérification indépendante
Constat vérifié	Une seconde passe a reproduit le résultat	Il entre dans le livrable avec son impact et sa priorité
Non confirmé	La seconde passe n’a pas pu le reproduire	Il est marqué comme non vérifié ou écarté, et jamais présenté comme vérifié

Appliquez la même rigueur lorsque vous triez des résultats de scanners. La vue détaillée d’un constat affiche la sévérité du scanner à côté de la sévérité validée par l’IA (« Severity — scanner vs AI »). Elle indique aussi l’origine de chaque étape d’une trace de flux de données, par exemple Scanner dataflow ou AI-verified. Considérez toute étape marquée AI-inferred (unverified) comme une piste à vérifier, et non comme une preuve (le module 5 explique comment les traces sont vérifiées).

Les quatre garde-fous

Lors d’une mission AI Swarm Pentest, l’exigence de preuve s’appuie sur quatre garde-fous. Ce sont les quatre mêmes que ceux présentés sur la page publique AI Swarm Pentest, et le module 6 les applique en détail.

Garde-fou	Ce que cela signifie pour vous
Périmètre convenu par écrit	La cible (une application, une API, du code source ou un environnement de test), les accès de test et les règles d’engagement sont confirmés avant le début des travaux. Plexicus n’agit pas en dehors de ce périmètre.
Preuves traçables	Les preuves restent rattachées au constat qu’elles étayent.
Limites de mission	Le temps, les ressources et les accès sont bornés, de sorte que chaque exécution reste maîtrisée.
Décision humaine	Votre équipe conserve l’approbation finale et le contrôle de chaque modification. Plexicus n’effectue aucune modification automatique en production.

Comment le produit fait respecter le périmètre

Vous ne pouvez pas lancer un AI Pentest tant que vous n’avez pas prouvé que vous êtes propriétaire de la cible. Pour une application, la preuve passe par un jeton placé dans une balise meta HTML ou dans un fichier sous /.well-known/. Pour un domaine entier, elle passe par un enregistrement DNS TXT. L’acceptation de conditions d’utilisation ne vaut pas preuve. Dans une nouvelle évaluation, « Destructive actions » est présélectionné comme hors périmètre, et l’assistant recommande de tester la préproduction plutôt que la production.

Décision humaine et maîtrise de la fusion

L’IA automatise le travail répétitif d’exploration, de corrélation et de reproduction. Votre équipe garde le contexte, la supervision et la décision finale. Dans le produit, la décision « Mark as false positive » prise par une personne fait autorité, et les passes ultérieures de l’IA ne la remettent pas en cause. Les correctifs préparés par l’IA sont accompagnés d’une note qui invite le relecteur à valider la modification.

Plexicus ne modifie jamais la production. Il ne livre que des propositions à relire, sous forme de pull requests ou de fichiers de patch distincts. L’agent de correction IA modifie un clone isolé de votre dépôt. Plexicus pousse la modification uniquement vers une nouvelle branche et ouvre une pull request vers votre branche de base, sans jamais la fusionner. La fusion reste toujours la décision de votre équipe, dans votre propre outil de gestion de code source.

Vue d’ensemble de la plateforme et de ses utilisateurs

La barre latérale principale donne accès à Dashboard, Assets, Pentest, Findings, XBOM, la page Automations et Settings. Docs et Support se trouvent en bas. Appuyez sur ⌘K (Ctrl+K sous Windows et Linux) pour ouvrir une palette de commandes et accéder directement à n’importe quelle section.

Zone	Ce que vous y faites	Principaux utilisateurs
Dashboard	Suivre la posture à travers les onglets CISO, DevSecOps, Compliance, Developer et Custom, filtrés par période et par dépôt	Responsables sécurité, ingénieurs sécurité, développeurs
Assets	Gérer les dépôts connectés dans l’onglet Repo Scan : ajouter des dépôts, suivre les scans, relancer un scan. Les onglets Registry Audit et Cloud Assessment sont disponibles selon votre offre	Ingénieurs sécurité, responsables de la plateforme
Pentest	Créer des évaluations AI Pentest, vérifier la propriété de la cible, suivre les exécutions et ouvrir leurs résultats	Ingénieurs sécurité
Findings	Trier les constats dans les onglets Repo, SCM, Cloud, Registry et App Pentest. Ouvrir un constat pour examiner les preuves, créer un ticket ou lancer la remédiation	Ingénieurs sécurité, développeurs
XBOM	Parcourir les inventaires Software (SBOM), Cryptography (CBOM) et AI Models (AIBOM), définir des déclarations VEX et exporter	Ingénieurs sécurité, équipes conformité, responsables de la plateforme
Automations	Créer des flux qui acheminent les constats vers des correctifs, des tickets et des validations	Les administrateurs créent et activent les flux
Settings	Organization (équipe, rôles, vérification de propriété), Configuration (intégrations, options de la plateforme, facturation) et My Account (informations du compte, authentification, jetons)	Administrateurs et responsables de la plateforme, ainsi que chaque utilisateur pour son propre compte

Trois types d’utilisateurs

• Les ingénieurs sécurité (AppSec et DevSecOps) trient les constats, configurent les scans, lancent des évaluations AI Pentest et transmettent le travail vérifié aux développeurs.
• Les développeurs traitent les constats qui leur sont attribués, relisent les correctifs préparés par l’IA et ouvrent des pull requests. Beaucoup préfèrent le faire depuis l’IDE ou le terminal, ce que couvre le module 9.
• Les responsables de la plateforme déploient et exploitent Plexicus, connectent la gestion de code source et les fournisseurs d’identité, et gèrent les paramètres de l’organisation.

Les rôles intégrés en bref

Rôle	À quoi il sert
Admin	Administration complète de l’organisation : équipe, rôles, paramètres, intégrations, facturation et journal d’audit. Les administrateurs peuvent aussi générer des remédiations et ouvrir des pull requests.
Cyberoper	Le rôle d’opérateur sécurité. Il trie les constats, marque les faux positifs, génère des remédiations et utilise Send to Dev Team pour attribuer le travail. Par défaut, il n’ouvre pas de pull requests.
Developer	Traite les constats qui lui sont attribués et ouvre des pull requests pour les correctifs à l’état Ready to Fix.

Cette répartition est délibérée. Avec les rôles par défaut, la personne qui prépare un correctif et celle qui le propose dans la base de code peuvent être différentes. Un Cyberoper génère et relit la modification, et un Developer ouvre la pull request. Selon votre offre, les administrateurs peuvent aussi créer des rôles personnalisés dans Settings Roles . Les rôles intégrés ne peuvent être ni renommés ni supprimés. Le module 10 traite en détail des rôles, du SSO et du journal d’audit.

Les bases du déploiement et de la confiance

Plexicus fonctionne en SaaS UE ou en auto-hébergé, le mode air-gapped étant une variante de l’auto-hébergé. Le produit est le même dans chaque cas : seuls l’hébergement et les frontières réseau changent.

Option	Où il s’exécute	Quand le choisir
SaaS UE (par défaut)	Hébergé par Plexicus sur app.plexicus.ai, exploité dans le cadre d’un engagement de résidence des données dans l’UE (voir trust.plexicus.ai)	La plupart des équipes. Aucune infrastructure à gérer, et les mises à jour sont automatiques
Auto-hébergé	Votre propre cluster Kubernetes, sur site ou dans un compte cloud que vous contrôlez, installé avec le chart Helm officiel	Exigences strictes de résidence des données, de conformité ou d’isolation réseau
Air-gapped (variante auto-hébergée)	L’installation Helm auto-hébergée, avec les images répliquées dans un registre interne et votre propre émetteur de certificats interne	Clusters sans accès public à Internet ou soumis à un contrôle strict des flux sortants

Ce que signifie « auto-hébergé »

Auto-hébergé et sur site désignent le même produit, le même chart et la même licence, et un déploiement auto-hébergé n’envoie ni télémétrie, ni données analytiques, ni données de feedback hors de votre cluster. Les fonctionnalités qui dépendent des services commerciaux de Plexicus, comme la facturation, sont désactivées, et seules les intégrations que vous configurez vous-même, comme votre gestion de code source et votre fournisseur d’IA, communiquent avec des systèmes externes. Le module 10 couvre Helm, les installations air-gapped et les sauvegardes.

Votre code et l’IA

• Le code des clients n’est pas utilisé pour entraîner des modèles d’IA.
• Le SaaS Plexicus est exploité dans le cadre d’un engagement de résidence des données dans l’UE (voir trust.plexicus.ai). L’entité juridique, PLEXICUS, S.L., est basée à Bilbao, en Espagne, et relève de la juridiction de l’UE.
• Les fonctionnalités d’IA envoient le contexte de code pertinent à l’endpoint du modèle configuré. Il s’agit par défaut de modèles gérés par Plexicus ou, selon votre offre, de l’endpoint de votre propre fournisseur d’IA, configuré dans Settings BYOAI .

Confiance et preuves

Plexicus détient la certification SOC 2 Type II. Un cabinet indépendant soumet chaque année la plateforme à un test d’intrusion. Le rapport SOC 2, un modèle de DPA, la synthèse du test d’intrusion et les réponses aux questionnaires de sécurité sont accessibles en libre-service sur le portail de confiance, trust.plexicus.ai. Signalez toute vulnérabilité touchant Plexicus lui-même à info@plexicus.ai.

Soyez précis lorsque vous parlez de conformité. Plexicus ne rend pas votre organisation conforme à NIS2, à l’article 28 de DORA, au CRA ou à l’EU AI Act. Il met en correspondance les constats avec les référentiels que vous sélectionnez, comme NIS2, DORA et le CRA, dans l’onglet Compliance du Dashboard, et les attestations XBOM peuvent être évaluées au regard de profils tels que l’EU CRA et l’EU AI Act. Vos auditeurs évaluent ensuite ces preuves. Le module 8 traite ce sujet en détail.

Points clés à retenir

• Le volume d’alertes mesure la production des outils, pas le risque. La prolifération des outils, le bruit, le goulet d’étranglement de la remédiation et l’absence de visibilité sur la posture occupent les équipes sans les rendre plus sûres.
• Proof-Driven AppSec est une boucle : Valider avec AI Swarm Pentest, Comprendre avec Deep Code Analysis et Remédier avec Remediation. XBOM et Plexicus Automation fonctionnent à ses côtés.
• Pas de preuve reproductible, pas de constat vérifié. Un résultat qu’une seconde passe ne parvient pas à reproduire est marqué comme non vérifié ou écarté.
• Lors d’une mission AI Swarm Pentest, quatre garde-fous s’appliquent : périmètre convenu par écrit, preuves traçables, limites de mission et décision humaine. Plexicus n’effectue aucune modification automatique en production, et votre équipe garde toujours la maîtrise de la fusion.
• La barre latérale donne accès à Dashboard, Assets, Pentest, Findings, XBOM, la page Automations et Settings. Les trois rôles intégrés, Admin, Cyberoper et Developer, se répartissent les responsabilités.
• Le SaaS UE est l’option par défaut, et les installations auto-hébergées via Helm comme les installations air-gapped exécutent le même produit. Le code des clients n’est pas utilisé pour l’entraînement de l’IA, et Plexicus détient la certification SOC 2 Type II tout en produisant pour vos référentiels des preuves, et non une conformité.