De la vulnérabilité à la preuve : pentest continu et automatisé dans monsys

Une alerte de vulnérabilité pose toujours la même question à laquelle personne ne peut répondre vite : est-ce que ça tourne quelque part, et peut-on y accéder depuis l'extérieur ? L'inventaire de paquets dit « cette version de PHP est vulnérable ». Ce dont vous avez besoin ce jour-là, c'est la ligne d'après : lesquels de vos sites y répondent, depuis internet, maintenant.

Nous avons donc ajouté à monsys une couche de surface d'attaque : un pentest continu et automatisé qui complète l'inventaire inside-out par un regard outside-in. Le cadrage est volontairement strict : un scanner pointé vers des systèmes clients ne doit jamais sortir du périmètre, jamais rien casser, et jamais tourner sans preuve de propriété.

Ce qu'il répond

• Qu'est-ce qui est réellement joignable ? Ports ouverts, panneaux publics,

configuration TLS, en-têtes de sécurité manquants, fichiers exposés comme .git et .env.

• Une CVE est-elle exploitable ? Une détection qui confirme une

vulnérabilité de votre inventaire fait passer cette exposition de « surveiller » à exploitable confirmé : avec une alerte.

• Qu'est-ce que personne n'a enregistré comme CVE ? Chiffrements faibles,

certificats expirés par domaine, logins par défaut, listings de répertoires.

Sûr par conception

Toute la couche est bâtie autour d'un principe : le périmètre est une propriété prouvée. Un scanner ne touche qu'un actif dont vous êtes démontrablement propriétaire : un domaine qu'un agent sert sur votre propre hôte (confirmé via le certificat Let's Encrypt), une vérification DNS-TXT, ou un ajout manuel avec TOTP. Aucun champ libre ne lance de scan.

En plus :

• Opt-in. Le scan est désactivé par défaut. L'activation exige un TOTP. Les

scans tournent dans votre propre fenêtre de maintenance.

• Detect-only. Pas d'exploitation, pas de force brute, pas de tests de type

DoS, rien écrit sur une cible. Nous n'utilisons que de l'open source auto-hébergé : nmap, testssl.sh, nuclei et OWASP ZAP, aucun service cloud externe dans le chemin.

• Isolé. Chaque scanner tourne dans un conteneur Docker épinglé et durci :

lecture seule, sans capabilities, non-root, avec le nom d'hôte lié à l'IP vérifiée pour rendre le DNS rebinding impossible.

• Stoppable. Un kill-switch arrête un scan en cours en quelques secondes.

Construit comme un outil d'attaque doit l'être

Parce qu'un seul appel erroné sur un système client peut couler une entreprise, nous avons fait surveiller cette fonctionnalité par une équipe adversariale distincte qui, pendant la construction, a cherché l'évasion de périmètre, le SSRF, l'injection de commandes et un kill-switch qui ne prend pas. Cette équipe a trouvé de vrais problèmes : un kill-switch qui n'arrêtait pas un conteneur, du DNS rebinding, une preuve de propriété falsifiable, et chacun a été corrigé et revérifié avant le déploiement. Ce n'est pas un détail ; c'est la raison pour laquelle vous osez l'activer sur votre propre infrastructure.

Preuve pour votre audit

Chaque exécution de scan est signée Ed25519 et entre dans le pack d'audit mensuel : qui a scanné, quand, quel périmètre, quels résultats. NIS2 demande des politiques et procédures qui évaluent l'efficacité de vos mesures. Un rapport de scan mensuel, reproductible et signé par actif, c'est exactement cela. monsys mesure ; l'auditeur juge.

Activer

Allez dans Sécurité → Surface d'attaque, importez vos domaines depuis les agents, activez la politique avec TOTP et choisissez une fenêtre de maintenance. Le premier scan trouve en quelques minutes vos ports ouverts, l'état TLS et les mauvaises configurations, et ensuite chaque semaine, avec une comparaison par rapport à la semaine précédente.

De « il y a une CVE » à « cet hôte, ce domaine, joignable, confirmé », en une seule ligne continue.