Scan fondé sur la preuve
Scan fondé sur la preuve : des failles vérifiées, pas supposées
La plupart des scanners vous noient sous les constats « possibles ». SecuProbe rejoue chacun d'eux et lance une requête témoin avant de le compter — votre rapport ne montre que des failles réellement reproduites, avec beaucoup moins de faux positifs.
Pourquoi les scanners automatiques noient sous le bruit
Le vrai reproche fait au scan automatisé n'est pas qu'il rate des choses : c'est qu'il crie au loup. Un seul scan peut remonter cent constats « élevés » dont la moitié s'évaporent dès qu'on les vérifie à la main. L'équipe apprend à se méfier de l'outil, le rapport finit ignoré, et la vraie faille se cache dans le bruit.
La cause : beaucoup de scanners signalent un signal — un en-tête, un message d'erreur, un code de statut — sans prouver qu'il vient d'une faiblesse réelle. Un site qui répond 200 à tout, un pare-feu qui renvoie 403, un message d'erreur générique : chacun peut ressembler à une faille sans en être une.
Ce que « fondé sur la preuve » veut dire chez SecuProbe
SecuProbe traite un constat comme une affirmation à prouver avant de la compter. Pour chaque test actif, le scanner conserve la requête exacte qui a déclenché le résultat, puis fait deux choses. Il rejoue cette requête : le comportement vulnérable doit réapparaître, pour qu'un incident réseau passager ne devienne jamais une faille. Puis il envoie une requête témoin — la même requête sans la charge utile, un paramètre mis à une valeur neutre, ou un chemin voisin censé ne pas exister. Si le témoin produit le même signal, le résultat ne vient pas de la charge utile, et le constat est écarté.
Seul un constat qui réapparaît au rejeu et se tait sur le témoin est confirmé. Quand un module obtient une confirmation hors bande — un rappel que lui seul pouvait déclencher — le constat est confirmé d'emblée.
Trois niveaux de confiance, et ce qui compte
Chaque constat porte l'un de trois états. Confirmé : le rejeu a réussi et le témoin est resté propre. Probable : constats de configuration ou d'information observés directement, ou faille active dont la preuve n'a pas pu être rejouée sur cette cible. Non confirmé : le signal n'a pas pu être reproduit, ou apparaissait même sans la charge utile.
C'est décisif pour la note : les constats non confirmés sont listés à part et ne comptent pas dans le SecuScore. Le chiffre que vous présentez à un client ou à un comité repose sur des preuves, pas sur des suppositions.
La preuve attachée à chaque constat
Un constat confirmé n'est utile que si l'on voit pourquoi. SecuProbe enregistre, pour chacun, la requête envoyée et un extrait de la réponse pour les tests actifs, la valeur observée pour les constats de configuration, des étapes de reproduction numérotées, une commande curl prête à copier, un score CVSS 3.1 et une référence CWE. Les cookies, jetons et identifiants sont retirés avant l'enregistrement, et la preuve est chiffrée au repos.
Vous pouvez rejouer la requête de preuve d'un constat en moins de 30 secondes, sans consommer de scan de votre quota — pratique pour confirmer un correctif.
Honnête par conception : ce que la preuve ne promet pas
Le scan fondé sur la preuve réduit fortement les faux positifs ; il ne prétend pas tous les supprimer. La validation réseau est bornée dans le temps pour qu'un scan rapide le reste, et sur certaines cibles une preuve ne peut réellement pas être rejouée — ces constats retombent sur la confiance propre du module plutôt que d'être gonflés.
Si un constat vous semble malgré tout faux, un clic le marque comme faux positif : il reste visible mais cesse de compter dans la note, et ce signal nous aide à affiner la détection.
Une preuve qui circule : rapports, CI/CD, tickets
Comme chaque constat porte sa propre preuve, celle-ci le suit partout. Le rapport PDF et le lien de partage en lecture seule la montrent au client comme preuve de vos contrôles. En CI/CD, les constats que vous avez acceptés ou marqués faux positifs — et ceux qui n'ont pas pu être confirmés — ne font jamais échouer le build.
Quand vous ouvrez un ticket Jira ou Linear depuis un constat, il emporte la preuve expurgée et la remédiation, pour que le développeur n'ait jamais à le reproduire de zéro.