Comment j'ai développé Sanca, mon scanner de vulnérabilités

Si vous voulez juste accéder à la démo (où le listing des CVE est désactivé), c’est sur sanca.io .
Si vous cherchez le code source, il est sur Github .

Capture d’écran de sanca.io

Les grandes entreprises utilisent souvent des plateformes EASM (External Attack Surface Management) pour surveiller leurs serveurs et sites Web à la recherche de vulnérabilités.

Le scénario rêvé est le suivant :

Chaque vulnérabilité identifiée par la plateforme est réelle, unique et expliquée clairement.
L’EASM publie automatiquement les vulnérabilités dans le système de tickets de l’entreprise.
Grâce à un inventaire exhaustif et à jour des assets de l’entreprises, chaque ticket est assigné à la bonne personne, qui pourra gérer et documenter les étapes de sa correction.

Passons maintenant à la réalité.

Faux positifs, absence de preuve et doublons

Quand on travaille sur les résultats de scans fournis par un EASM, on se rend vite compte que les résultats ne sont pas exploitables et qu’il faut passer derrière chaque supposée vulnérabilité pour vérifier si elle est réelle, mais également si elle n’a pas été reportée plusieurs fois.

Parmi les cas qui reviennent souvent on peut retrouver :

Une vulnérabilité Windows identifiée sur un serveur Linux.
Une version d’Apache httpd vulnérable reportée plusieurs fois (version < 2.4.60, version < 2.4.58, version 2.4.57, parce qu’il est installé en version 2.4.54).
Une version non maintenue de jQuery détectée au milieu d’un fichier JavaScript minifié, sans la moindre information sur comment ça a été identifié.

Avec de tels résultats, impossible de publier directement les vulnérabilités dans le système de tickets, on surchargerait les responsables avec des faux positifs et des vulnérabilités déjà traitées.
Il faut donc des analystes pour refaire le travail de l’EASM : identifier les vulnérabilités réelles, supprimer les doublons, et créer des tickets avec des descriptions claires et des conseils de remédiation.

Quel temps perdu à refaire le travail d’un outil pour lequel on paye.

Ma décision : développer ma solution

J’en ai eu assez de perdre mon temps, je voulais avoir des outils fiables pour me concentrer sur les tâches sur lesquelles j’apportais de la valeur.
Passer 10 minutes à éplucher un fichier JavaScript minifié de 900 lignes pour identifier une possible version de jQuery ne devrait pas être mon rôle.

J’ai fini par poser des congés, deux semaines au mois d’août pour concevoir un programme qui permet d’identifier aussi bien OpenSSH que jQuery, que WordPress ou PHP. J’avais quelques critères importants que je tenais à respecter :

Chaque découverte devait être accompagnée d’une preuve.
Je voulais passer plus de temps à l’utiliser qu’à le déboguer.
Il fallait quelque chose de léger et rapide.

J’ai choisi de développer Sanca en Rust.

Pourquoi Rust

Je voulais quelque chose de léger, donc pas de Chromium / Puppeteer qui consomme 2 Go de RAM.

Il fallait que ce soit fiable et facile à maintenir, il était donc exclu de développer un programme en JavaScript ou en Python.

Le langage Rust a l’avantage d’être rigoureux, il permet de détecter beaucoup de bugs pendant le développement plutôt qu’à l’exécution, d’être relativement sûr que ça fonctionne. C’était le candidat idéal, c’est lui que j’ai choisi.

Aujourd’hui j’ai 15 000 lignes de code Rust, incluant les tests unitaires, et une architecture solide qui me permet de faire évoluer le programme facilement.

Comment fonctionne Sanca

Sanca supporte deux types de scans, TCP et HTTP. Le scan TCP permet d’identifier des technologies comme OpenSSH et MySQL, alors que le scan HTTP permet d’identifier des serveurs Web, des CMS, mais également des technologies JavaScript. Cette dernière catégorie est la plus chronophage à identifier manuellement.
Les deux scans fonctionnent avec des expressions régulières.

Le scan TCP est simple, il récupère la bannière d’un programme et l’analyse pour identifier de quoi il s’agit.

Le scan HTTP est un peu plus élaboré, il télécharge l’URL qu’on lui donne et peut éventuellement extraire les URLs des fichiers JavaScript contenues dans le HTML pour les télécharger aussi. Selon les technologies qu’on cherche à identifier il peut également rajouter des URLs spécifiques, par exemple pour Tomcat ou phpMyAdmin. Les téléchargements se font en parallèle pour gagner du temps. Ensuite il regarde dans chaque fichier à la recherche des technologies qu’on cherche à identifier.

Quel que soit le type de scan, il peut utiliser les programmes et versions identifiés pour appeler l’API du NVD (NIST) et récupérer les CVEs correspondantes. Les CVEs sont stockées en cache afin d’éviter d’appeler l’API à chaque fois.

Voici un exemple :

./sanca --vuln-source nvd --vuln-cache files -s http -u https://www.my.website
Sanca software v1.6.1 - https://www.sanca.io

----------https://www.my.website----------

[Tomcat/9.0.117] Tomcat 9.0.117 has been identified by looking at its signature "Apache Tomcat/9.0.117" at this page: https://www.my.website/..;/..;/ | CVE: CVE-2026-41284, CVE-2026-41293, CVE-2026-42498, CVE-2026-43512, CVE-2026-43513, CVE-2026-43514, CVE-2026-43515, CVE-2026-50229, CVE-2026-53404, CVE-2026-53434, CVE-2026-55276, CVE-2026-55955, CVE-2026-55956, CVE-2026-59083, CVE-2026-59084, CVE-2026-66299

[Bootstrap/4.3.1] Bootstrap 4.3.1 has been identified because we found "Bootstrap v4.3.1" at this url: https://www.my.website/typo3temp/assets/compressed/merged-94ed12fb452ac918e98829275c23e618-8239108882700156f9f4733844759929.js

[jQuery/3.7.1] jQuery 3.7.1 has been identified because we found "jQuery v3.7.1" at this url: https://www.my.website/typo3temp/assets/compressed/merged-8cdece27f7e9695aabf1c8da17ed0932-3c08673a12d49a49782ee3191cd951f8.js

[phpMyAdmin/5.2.3] phpMyAdmin 5.2.3 has been identified because we found "5.2.3 (2025-10-07)" at this url: https://www.my.website/phpmyadmin/ChangeLog

[Highcharts/11.4.8] Highcharts 11.4.8 has been identified because we found "Highcharts[...]",n.version="11.4.8"" at this url: https://www.my.website/main-LCYC8A7P.js

On voit que Sanca a rajouté l’URL https://www.my.website/..;/..;/ , et y a detecté Tomcat.

Le scan ne prend que quelques secondes à s’exécuter, et on obtient une liste des technologies détectées. Pour chacune d’elle on peut vérifier en un coup d’œil où et comment elle a été identifiée. On peut se concentrer sur le reste du travail.

La faiblesse est que la base de données des CVE n’est pas toujours propre, mais il serait très simple d’implémenter une autre source.

Ce que Sanca détecte

Sanca détecte 80 technologies différentes. Je ne vais pas en faire une liste exhaustive, mais on peut en lister différents types :

Des technologies TCP, comme OpenSSH, MySQL ou ProFTPD.
Des technologies HTTP, comme Tomcat, Nginx et PHP.
Et des technologies JavaScript, comme Highcharts, jQuery et Bootstrap.

Je n’ai pas implémenté de scan pour les technologies UDP comme bind9, mais grâce à une architecture propre ça ne serait pas très compliqué à rajouter. Ça viendra peut-être le jour où j’en aurai besoin.

Intégration en production

L’exemple ci-dessus montre la sortie en texte, pratique pour une utilisation manuelle, mais il est possible de passer au niveau supérieur en exportant en JSON ou en CSV.
Cela permet d’utiliser un autre programme pour faire le pont entre les résultats des scans et le système de tickets.

Exemple de scan HTTP

Voici un résultat de scan HTTP exporté en JSON.

{
  "findings": [
    {
      "evidence": "Apache Tomcat/9.0.117",
      "evidence_text": "Tomcat 9.0.117 has been identified by looking at its signature \"Apache Tomcat/9.0.117\" at this page: https://www.my.website/..;/..;/",
      "technology": "Tomcat",
      "url_of_finding": "https://www.my.website/..;/..;/",
      "version": "9.0.117",
      "vulnerabilities": [
        {
          "base_score": 7.5,
          "cve_id": "CVE-2026-41284",
          "cvss_version": "3.1"
        }
      ]
    }
  ],
  "ip_hostname": "www.my.website",
  "port": 443,
  "url": "https://www.my.website/auth/login"
}

Toutes les informations importantes sont là, pour chaque technologie identifiée on trouve :

La preuve brute.
La preuve texte, plus claire pour les humains.
Le nom de la technologie identifiée et sa version.
La liste des CVE associées à cette version, avec le CVSS score.
Le FQDN et le port qui ont été scannés.
L’URL utilisée par Sanca pour faire son scan.

Exemple de scan TCP

Et voici un résultat de scan TCP.

{
  "findings": [
    {
      "evidence": "SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18",
      "evidence_text": "The operating system Ubuntu 24.04 has been identified using the banner presented by OpenSSH: SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18",
      "technology": "Ubuntu",
      "url_of_finding": null,
      "version": "24.04",
      "vulnerabilities": []
    },
    {
      "evidence": "SSH-2.0-OpenSSH_9.6p[...] Ubuntu-3ubuntu13.18",
      "evidence_text": "OpenSSH 9.6p1 has been identified because we found \"SSH-2.0-OpenSSH_9.6p[...] Ubuntu-3ubuntu13.18\" in its banner",
      "technology": "OpenSSH",
      "url_of_finding": null,
      "version": "9.6p1",
      "vulnerabilities": [
        {
          "base_score": 9.3,
          "cve_id": "CVE-2008-3844",
          "cvss_version": "2"
        }
      ]
    }
  ],
  "ip_hostname": "www.my.website",
  "port": 22,
  "url": ""
}

Cette fois Sanca a scanné le port 22, sur lequel écoute OpenSSH. Deux points importants ici :

La structure du JSON est la même quel que soit le type de scan, ce qui facilite le traitement par un autre programme.
En analysant la bannière d’OpenSSH, Sanca en a déduit le système d’exploitation installé et sa version.

Avec ce simple scanner et un script Python qui communique avec l’API du système de tickets, gérer les vulnérabilités de son entreprise devient plus simple et plus rapide.

Ce que j’ai appris

Cette aventure a été assez technique : cybersécurité, connaissance des technologies, développement Rust, tests unitaires, architecture propre.

Pourtant j’ai pris conscience que ma valeur auprès de ce client ne venait pas de mes compétences techniques, même si elles étaient importantes. Ma vraie valeur venait de ma capacité à apporter des solutions aux problèmes que je rencontrais, à travailler mieux et plus vite.
D’autres aussi compétents que moi auraient pu continuer de traiter les résultats de la plateforme EASM, sans se plaindre. Moi j’ai amélioré le process, je l’ai rendu plus fiable et bien plus rapide.
Cette année là on a atteint 150% de nos objectifs sur les vulnérabilités EASM, ce n’est probablement pas une coïncidence.

Vos équipes perdent du temps sur des tâches répétitives de sécurité ? Découvez mes services d’automatisation et d’audit .

Faux positifs, absence de preuve et doublons#

Ma décision : développer ma solution#

Pourquoi Rust#

Comment fonctionne Sanca#

Ce que Sanca détecte#

Intégration en production#

Exemple de scan HTTP#

Exemple de scan TCP#

Ce que j’ai appris#