Shannon : l’IA open source qui fait un pentest complet de votre app et qui ne dort jamais

Une IA qui pentest votre code pendant que vous buvez un café

On a tous déjà lancé un scan de sécurité en espérant très fort qu’il nous sorte une liste propre, courte et actionnable… et on a tous déjà reçu l’inverse : 184 alertes, 173 faux positifs, et une vuln “potentielle” qui ressemble à un horoscope.

Shannon, lui, débarque avec une promesse assez osée : faire un pentest autonome de votre application, en comprenant votre code, puis en testant réellement l’app en conditions dynamiques. Pas juste un scan à l’aveugle. Un agent IA qui lit le dépôt, repère comment l’appli fonctionne, puis tente des attaques ciblées comme le ferait un pentester.

Le tout est open source, tourne via Docker, s’appuie sur Claude (Anthropic) et produit un rapport exploitable avec sévérités CVSS, preuves d’exploitation, payloads et recommandations de correction. Bref, une machine qui essaie de vous “hacker” proprement… pour votre bien.

Shannon, c’est quoi exactement ?

Shannon est un framework open source conçu pour automatiser une démarche de pentest de bout en bout :

Analyse statique du code source (routes, middlewares, accès DB, contrôleurs, logique d’auth)
Tests dynamiques sur l’application qui tourne (attaques réelles, envoi de requêtes, exploitation)
Orchestration multi agents : plusieurs sous-agents spécialisés bossent en parallèle
Rapport final structuré (JSON), avec scoring, preuves et fixes

Là où ça devient intéressant, c’est que Shannon ne fait pas “juste” un crawling puis un fuzzing générique. Il essaie d’adapter ses tests à ce qu’il lit dans le code : endpoints, paramètres, conditions, cookies, logique d’accès, requêtes SQL ou NoSQL, etc.

Ce qui change par rapport aux scanners classiques

Les scanners traditionnels ont une limite : ils voient souvent une application comme une boîte noire. Même quand ils sont très bons, ils font essentiellement du test dynamique, parfois enrichi avec des heuristiques.

Shannon, lui, part du principe que le code source est une carte au trésor.

Concrètement, il peut :

comprendre qu’un paramètre finit dans une requête SQL, et tester des payloads plus pertinents
repérer qu’un endpoint interne existe mais n’est pas documenté, et quand même aller le tester
détecter des scénarios plus subtils comme un bypass d’auth via cookie, ou une injection NoSQL cachée dans un coin discret

Résultat : moins de tirs dans le vide, et plus d’attaques “intelligentes”. Dit autrement, Shannon essaie d’être le collègue qui lit le code avant de casser la prod.

Une armée de sous agents spécialisés, orchestrée en parallèle

Shannon s’appuie sur une approche multi agents : au lieu d’un unique process qui fait tout en série, il déploie plusieurs agents spécialisés, chacun avec sa mission.

On retrouve typiquement :

un agent Recon (cartographie, endpoints, surfaces d’attaque)
un agent SQL injection
un agent XSS
un agent SSRF
un agent Auth et AuthZ (authentification et autorisations)

Ces agents tournent en parallèle via Temporal, un moteur de workflow qui permet de suivre la timeline des tâches. C’est assez satisfaisant à observer : on a l’impression de regarder une petite équipe de pentesters bosser sur un tableau Kanban… sauf qu’ils sont tous dans votre machine.

Oui, Shannon attaque vraiment (donc non, pas en prod)

Point crucial : Shannon ne se contente pas de signaler une vuln théorique. Il peut aller jusqu’à exploiter réellement une faille pour prouver qu’elle est exploitable.

Ça implique deux choses :

C’est beaucoup plus utile qu’un rapport plein de “peut être”, parce que vous obtenez une preuve et un chemin d’exploitation.
C’est dangereux si vous le lancez n’importe où.

La règle d’or :

lancez Shannon sur un environnement local, staging ou test
avec des données de test
et une cible que vous contrôlez

Lancer ça en production, c’est un peu comme tester vos freins en descente sur autoroute. Techniquement, vous aurez un résultat, mais vous risquez de le regretter.

Installation : Docker, une clé API et c’est parti

Le projet est pensé pour être facile à déployer :

Docker et Docker Compose
un fichier .env
une variable ANTHROPIC_API_KEY pour utiliser l’API Claude

Ensuite, vous lancez la stack et vous suivez le workflow. Dans l’article source, le temps de run observé tourne autour de 1 h à 1 h 30, selon la taille du projet, mais ça peut évidemment varier.

Temporal fournit une interface web pour suivre ce qui se passe (sur une URL locale). Vous voyez les agents démarrer, tester, échouer, recommencer, et remonter leurs résultats.

Combien ça coûte ? Beaucoup moins qu’un audit… mais pas zéro

Côté budget, Shannon est open source, mais l’IA ne travaille pas gratuitement : chaque agent consomme des tokens, et la facture grimpe avec la taille du code et la complexité.

Dans le retour d’expérience présenté :

environ 50 dollars par run en tokens Anthropic
un ordre de grandeur annoncé comme 60 fois moins cher qu’un audit humain classique

Quand on sait qu’un test d’intrusion peut coûter de 3 000 euros à plusieurs dizaines de milliers selon périmètre et contraintes, ça place Shannon comme une option très séduisante pour :

un pré audit avant de faire intervenir un pentester
une vérification régulière sur un projet qui évolue vite
un contrôle sur des endpoints API qui se multiplient (vous savez, ceux ajoutés “vite fait”)

Exemple concret : quand Shannon trouve des failles que vous n’aviez pas “vues”

Sur une app Node.js/Express de test avec 27 endpoints, Shannon a produit un run assez parlant :

pas d’injection SQL exploitable (et traçage des paramètres jusqu’aux requêtes, ce qui est précieux)
détection de plusieurs failles SSRF liées à des contournements IPv6
découverte de XSS stockées via innerHTML sans échappement côté front
et surtout, un grand classique qui fait mal : aucune authentification sur les endpoints

Le dernier point est presque comique, parce que c’est exactement le genre de chose qu’on oublie sur un proto local… puis qu’on expose un jour “temporairement”, puis qu’on oublie à nouveau. Shannon, lui, n’oublie pas.

Le rapport : CVSS, preuves d’exploitation et recommandations de fix

Le vrai juge de paix, ce n’est pas “est-ce que l’outil trouve des failles”, c’est “est-ce que je peux corriger vite et bien”.

Shannon sort un rapport qui, d’après la description, inclut :

la sévérité avec score ou niveau CVSS
le vecteur d’attaque
une preuve d’exploitation (payloads, étapes)
des recommandations de correction
et même la ligne ou la zone de code concernée, avec explication du pourquoi

C’est exactement ce qu’on attend d’un outil moderne : pas juste une alerte, mais un chemin clair vers le correctif.

Les limites à connaître (sinon vous allez lui en vouloir pour rien)

Aucun outil n’est magique, et Shannon ne fait pas exception. Il y a des cas où ça peut coincer :

code très exotique, framework peu commun, conventions maison
logique obfusquée ou comportements très dynamiques difficiles à analyser statiquement
surfaces d’attaque dépendantes d’infra ou de contexte (SSO, WAF, règles réseau)

Et surtout : Shannon ne remplace pas l’intuition humaine sur des scénarios vraiment tordus, les enchaînements multi étapes, les escalades logiques propres à votre métier.

En revanche, pour un premier niveau d’audit intelligent, et pour attraper rapidement des classes de vulnérabilités (SQLi, XSS, SSRF, auth), c’est une approche qui mérite clairement un test.

Où Shannon s’intègre dans une stratégie sécurité réaliste

Le meilleur usage de Shannon, ce n’est pas “on lance ça et on est conforme”. C’est plutôt :

Avant un audit externe : vous nettoyez les évidences, vous économisez du temps humain
À chaque grosse release : vous relancez un run sur staging
Dans un pipeline sécurité : pas forcément à chaque commit, mais sur des branches de release
Pour apprendre : voir une IA expliquer une faille avec le code sous les yeux, c’est un bon accélérateur pour l’équipe

L’idée, c’est de traiter Shannon comme un coéquipier infatigable : rapide, méthodique, parfois un peu cher en tokens, mais très utile pour éviter les boulettes classiques.

Bonnes pratiques avant de lancer Shannon sur votre projet

Pour éviter les sueurs froides et maximiser la valeur :

isolez un environnement de test avec des données factices
fixez un périmètre clair : URL cible, endpoints, scope
surveillez les logs et mettez des limites de débit si besoin
prévoyez un budget tokens et mesurez un premier run sur un petit périmètre
traitez les résultats comme des tickets : reproductibilité, priorité, patch, retest

Et si vous avez un endpoint “temporaire” non protégé, c’est le moment de le supprimer. Shannon le trouvera. Les IA adorent les trucs temporaires, comme les chats adorent les claviers.

Ressources et projet

Le projet est disponible en open source ici : https://github.com/KeygraphHQ/shannon

Si vous cherchez une approche différente des scanners traditionnels, plus proche d’un pentest guidé par compréhension du code, Shannon est clairement un outil à mettre sur votre radar.

Source : Shannon : l’IA open source qui fait un pentest complet de votre app (et qui ne dort jamais)