À propos de BreachVex

Pourquoi 2026 change la donne

Les attaquants itèrent maintenant avec l'IA. Les défenseurs ont accéléré leur CI/CD. Le pentest annuel — déjà obsolète avant d'être livré — est devenu indéfendable. La surface d'attaque change à chaque déploiement. La revue sécurité, elle, n'a lieu qu'une fois par an.

Le vide que personne n'a comblé

Pendant une décennie, rien n'existait entre « scanner bruyant » et « 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é. Un PoC — curl fonctionnel, requête capturée, screenshots — accompagne chaque vulnérabilité confirmée. Si notre pipeline ne la reproduit pas, le finding est isolé dans une section distincte et clairement étiquetée plutôt que promu — jamais mélangé à votre file de priorités, et jamais perdu 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. Phase 1 — reconnaissance passive et probing — cartographie la surface d'attaque sans toucher à l'application. Phase 2 — reconnaissance active — empreinte les technologies, énumère les endpoints, identifie les surfaces d'authentification. Phase 3 — 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), exécute des chaînes d'exploit avec 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. Batch d'avril 2026 : 159 findings confirmés — 60 d'entre eux portent une preuve d'extraction rejouable, 11 un exploit complet — et plus de 1 300 endpoints cartographiés. La non-régression est régie par un golden dataset de 385 vulnérabilités obligatoires et 129 pièges intentionnels. Couverture large des vulnérabilités sur l'OWASP Top 10 via 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 — réduisant 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é, ainsi que 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.