Aegis intègre un test d'intrusion continu dans le SOC : il vérifie WAN, LAN, web, VPN et DNS comme un véritable attaquant, avec Rules of Engagement, WORM ledger et retest obligatoire — chaque résultat se conclut par une preuve dans le rapport (FR / EN / SR).
La défense se prouve par l'attaque. Aegis vérifie en continu votre surface d'attaque telle que la verrait un véritable adversaire — avec une autorisation complète et l'enregistrement de chaque action.
Cartographie de la surface d'attaque — host:port, DNS et voisinage, avec une évaluation rapide du risque.
SQLi, IDOR, SSTI, LFI et upload-RCE ainsi que vérifications JWT, API, GraphQL et CORS — de véritables chaînes, pas un simple scan.
Énumération et CVE pour WordPress, Drupal et d'autres, avec vérifications de contournement d'authentification sur les systèmes ERP.
Surface externe et interne, avec l'analyse AAP du chemin d'attaque (attack-path) par où un attaquant pourrait passer.
Vérification des passerelles VPN et de l'accès distant comme points d'entrée fréquents.
Load-test contrôlé de l'application avec graphiques et auto-abort — jamais un véritable packet-flood.
Un pentest sans preuve n'est qu'une opinion. Aegis relie chaque résultat à une trace inaltérable, à une condition de clôture claire et à un rapport que même l'auditeur comprend.
Chaque engagement a des règles signées, un périmètre et un signataire avant la première action.
Un enregistrement immuable, en append-only, de chaque action et résultat pour un audit irréfutable.
Un résultat critique reste ouvert jusqu'à ce qu'un nouveau test confirme que la correction a réellement été appliquée.
L'analyse du chemin d'attaque montre par où l'adversaire passerait et quel nœud interrompre en premier.
Rapports pour l'équipe de développement et pour l'audit, en trois langues.
Analyse statique du code en complément du test dynamique de l'application.
L'exemple suivant est fictif et sert uniquement à illustrer la structure du rapport.
MITRE ATT&CK : T1190 — exploitation d'une application publique · CWE-89
Description : le paramètre de recherche est transmis à la requête SQL sans paramétrage correct, ce qui permet d'injecter des conditions et de lire des données hors de leur usage prévu.
Preuve (expurgée) : GET /trazi?q=1%27-- renvoie une réponse qui confirme l'injection ; la chaîne PoC complète est consignée dans le ledger.
Recommandation : requêtes paramétrées (prepared statements), validation des entrées et principe du moindre privilège pour la base de données.
Retest : obligatoire — le résultat reste au statut HARD-BLOCK jusqu'à ce que la correction soit confirmée par un nouveau test.
Indicateurs de production agrégés, anonymisés et arrondis à titre illustratif.
Le test d'intrusion (pentest) est une attaque autorisée et contrôlée sur vos systèmes, dont l'objectif est de trouver et de prouver les faiblesses réelles avant qu'un attaquant ne les exploite.
Les RoE sont les règles d'engagement : périmètre, méthodes autorisées, calendrier et contacts. Sans RoE signé ni consentement, pas de test — c'est ce qui distingue le pentest d'une véritable attaque.
Le scan recense les faiblesses possibles ; un pentest les prouve. C'est pourquoi il va de pair avec l'analyse de vulnérabilités continue — largeur plus profondeur. Pour les entités NIS2, un pentest est aussi la preuve que les mesures sont réellement été testées.
Convenons du périmètre et des Rules of Engagement, puis montrons un pentest avec preuves : résultats, chemin d'attaque et rapport prêt pour l'audit.