À propos de BreachVex

Pourquoi 2026 change la donne

Les attaquants itèrent avec l'IA, et les défenseurs livrent plus vite avec la CI/CD. Le pentest annuel était déjà obsolète quand on l'a livré, et il ne tient plus la route : votre surface d'attaque change à chaque déploiement, alors que la revue sécurité n'a toujours lieu qu'une fois par an.

Le vide que personne n'a comblé

Pendant une décennie, rien n'existait entre un scanner bruyant et un humain coûteux. C'est ce vide que BreachVex a été conçu pour combler.

Ce que proof-based signifie vraiment

Un finding n'entre dans votre file prioritaire qu'une fois l'exploit exécuté. Chaque vulnérabilité confirmée est livrée avec un PoC rejouable : curl fonctionnel, requête capturée, screenshots. Si notre pipeline ne la reproduit pas, le finding part dans une section distincte et clairement étiquetée au lieu d'être promu, donc il ne se mélange jamais à votre file de priorités et ne disparaît jamais en silence. Chaque scan couvre l'OWASP Top 10 et au-delà.

Comment fonctionne le moteur d'attaque

Notre moteur d'attaque multi-étapes opère en 3 phases. La phase 1 est la reconnaissance passive et le probing : elle cartographie la surface d'attaque sans toucher à l'application. La phase 2 est la reconnaissance active, qui empreinte les technologies, énumère les endpoints et identifie les surfaces d'authentification. La phase 3 fait tourner un moteur d'attaque parallèle, mappé sur les catégories de l'OWASP Top 10 que l'automatisation peut vérifier de manière fiable (A01, A02, A04 partiel, A05), qui exécute des chaînes d'exploit dans un budget de temps borné par étape d'attaque. Un moteur de preuve dual-judge garde votre file prioritaire : chaque finding Critical, High et Medium est prouvé exploitable avant d'y entrer. Une vulnérabilité n'est confirmée que lorsque la chaîne d'exploit complète réussit de bout en bout. Les résultats passent une dernière passe de déduplication et un scoring CVSS v4.0 avant la génération du rapport. 4 829 tests automatisés régissent la non-régression sur l'ensemble du moteur.

Où nous en sommes aujourd'hui

Beta fermée. Notre corpus de validation compte 8 applications publiques volontairement vulnérables : applications d'entraînement OWASP, builds vulnérables communautaires et produits réels dans des versions à CVE connues, couvrant des APIs REST, des SPAs, GraphQL et des surfaces à forte composante authentification. Le batch d'avril 2026 a produit 159 findings confirmés, dont 60 avec une preuve d'extraction rejouable et 11 avec un exploit complet, avec plus de 1 300 endpoints cartographiés. Un golden dataset de 385 vulnérabilités obligatoires et 129 pièges intentionnels régit la non-régression. La couverture large de l'OWASP Top 10 vient d'un moteur d'attaque multi-étapes : une détection hybride à plusieurs étages exécute d'abord des heuristiques légères, puis n'escalade vers l'exploitation profonde que lorsque le signal le justifie, ce qui réduit le temps de scan sans sacrifier la couverture.

Ce vers quoi nous construisons

La prochaine étape est l'intégration CI/CD : un webhook qui déclenche un scan complet basé sur l'exploitation à chaque déploiement, avec retour des résultats dans votre PR comme gate sécurité, plus des webhooks sortants signés et les intégrations avec les outils de ticketing. La couverture s'élargit ensuite à l'analyse cloud et supply-chain (dépendances tierces, couches de containers, cross-référencement SBOM). Nous annonçons une date quand le travail est livré, pas avant. Vous voulez un accès anticipé ? Rejoignez la liste d'attente.