danoszz/penthera

Penthera Security Scanner

Scanner de sécurité léger pour les URL, les dépôts locaux et les audits de machine (macOS). Exécutez toujours la porte d'autorisation avant toute analyse.

Critique : Porte d'autorisation

N'exécutez pas Penthera tant que l'autorisation n'est pas confirmée.

Avant la première analyse d'une session, demandez à l'utilisateur de confirmer UNE des conditions suivantes :

1. Il possède la cible (application, serveur, projet).
2. Il dispose d'une autorisation écrite du propriétaire du système.
3. La cible est localhost ou un laboratoire privé qu'il contrôle.

Si l'utilisateur demande l'analyse d'un domaine tiers (ex. google.com, example.com) sans revendiquer la propriété ou l'autorisation, arrêtez-vous et refusez. En cas de doute, n'analysez pas.

Pour la politique complète, voir references/authorization.md.

Pré-vérification

Exécutez avant la première analyse :

bash skills/penthera/scripts/preflight.sh [URL]

Depuis la racine du dépôt. Passez l'URL cible pour avertir sur les cibles non localhost. Corrigez les erreurs avant de continuer.

Résoudre la commande CLI

Utilisez celle qui est disponible :

penthera --version          # après npm link
node bin/penthera.js --version   # depuis la racine du dépôt

Tous les exemples ci-dessous utilisent penthera ; remplacez par node bin/penthera.js si nécessaire.

Arbre de décision

Intention de l'utilisateur	Modèle de commande
Première fois / incertain	penthera (assistant interactif — TTY) ou penthera-scan
Analyser une URL en direct	penthera <url> --profile standard -o reports/scan.json
Analyser seulement le dépôt (secrets, routes)	penthera --repo . -o reports/repo-scan.json
Combinaison URL + source	penthera <url> --repo . -o reports/scan.json --sarif reports/scan.sarif
Comparer à une analyse précédente	penthera <url> -o reports/scan.json --baseline reports/previous.json
Points d'accès authentifiés	Ajouter --auth-cookie ou --auth-bearer / les variables d'env PENTHERA_*
Audit de machine macOS	penthera --machine

Comportement sûr par défaut

• Utilisez toujours --profile standard sauf si l'utilisateur demande explicitement des tests plus approfondis.
• Écrivez les rapports dans reports/ (ignoré par git), jamais dans skills/penthera/.
• Après l'analyse, lisez le rapport .md associé et résumez les résultats par gravité avec des recommandations de correction.

Porte du mode destructif

Ces indicateurs envoient des charges utiles d'attaque. Nécessitent une confirmation explicite de l'utilisateur avant utilisation :

• --deep — sondes SQLi, SSTI, SSRF, XSS, CMDi
• --fuzz — fuzzing d'API basé sur les propriétés
• --all — active recon + deep + fuzz
• --profile deep — couverture maximale

Si l'utilisateur demande un "test d'intrusion complet" ou "analyse approfondie", confirmez qu'il possède la cible et accepte les tests basés sur des charges utiles.

Workflow 1 : Audit pré-lancement

Déclencheurs : "analyse mon app de staging", "audit de sécurité avant déploiement", "vérifie mon application pour les vulnérabilités"

1. Confirmez l'autorisation (voir la porte ci-dessus).
2. Exécutez la pré-vérification.
3. Lancez :

mkdir -p reports
penthera https://staging.example.com --profile standard -o reports/scan.json

4. Lisez reports/scan.md — résumez les constats critiques/élevés/moyens.
5. Recommandez des correctifs concrets par constat.
6. Notez le code de sortie : 0 = aucun constat critique/élevé ; 1 = constats critiques/élevés trouvés ; 2 = analyse échouée.

Workflow 2 : Dépôt + analyse combinée en direct

Déclencheurs : "analyse mon app Next.js et mon staging", "analyse boîte noire et boîte blanche"

1. Confirmez l'autorisation pour l'URL.
2. Exécutez la pré-vérification avec l'URL.
3. Lancez :

mkdir -p reports
penthera https://staging.example.com --repo . --profile standard \
  -o reports/scan.json --sarif reports/scan.sarif

4. Résumez les constats de l'URL (en-têtes, TLS, CORS, auth) et du dépôt (secrets, routes API, limites de confiance).
5. Proposez de téléverser le rapport SARIF via GitHub Actions (voir references/output-and-ci.md).

Workflow 3 : CI / régression comparative

Déclencheurs : "comparer à la dernière analyse", "seulement les nouveaux constats", "vérification de régression"

1. Confirmez l'autorisation et que reports/previous.json existe (ou demandez à l'utilisateur le chemin de référence).
2. Lancez :

mkdir -p reports
penthera https://staging.example.com --profile standard \
  -o reports/scan.json --baseline reports/previous.json

3. Rapportez : nombre de nouveaux constats, résolus, inchangés (imprimé sur stderr pendant l'analyse).
4. Concentrez le résumé sur les nouveaux constats uniquement.

Analyses authentifiées

Seulement après avoir passé la porte d'autorisation :

# Jeton Bearer
PENTHERA_BEARER=eyJ... penthera https://myapp.com --profile standard -o reports/scan.json

# Cookie de session
penthera https://myapp.com --auth-cookie "session=abc123" -o reports/scan.json

# Indicateurs explicites
penthera https://myapp.com --auth-bearer "eyJ..." -o reports/scan.json

Variables d'environnement : PENTHERA_BEARER, PENTHERA_COOKIE.

Analyse de secrets dans un dépôt uniquement

Déclencheurs : "trouve les secrets codés en dur", "analyse ce dépôt pour les clés"

Aucune autorisation d'URL nécessaire pour l'analyse de dépôt local :

penthera --repo . -o reports/repo-scan.json

Résumez les constats de secrets ; rappelez à l'utilisateur de faire pivoter les identifiants exposés.

Exemples

Exemple 1 : Vérification rapide sur localhost

Utilisateur : "Analyse mon app localhost sur le port 3000"

Actions :

1. Confirmez localhost — autorisation satisfaite.
2. bash skills/penthera/scripts/preflight.sh http://localhost:3000
3. penthera http://localhost:3000 --profile quick -o reports/scan.json
4. Résumez reports/scan.md.

Exemple 2 : Staging avant déploiement

Utilisateur : "Audite staging.myapp.com avant le lancement"

Actions :

1. Demandez : "Possédez-vous ou avez-vous une autorisation écrite pour staging.myapp.com ?"
2. Après confirmation, lancez une analyse de profil standard avec sortie JSON + markdown.
3. Listez d'abord les éléments critiques/élevés avec des étapes de correction.

Exemple 3 : Cible non autorisée (doit refuser)

Utilisateur : "Analyse google.com pour les vulnérabilités"

Actions :

1. N'exécutez pas Penthera.
2. Expliquez que l'analyse de systèmes tiers sans autorisation n'est pas autorisée.
3. Proposez d'analyser leur propre application ou localhost à la place.

N'utilisez pas cette compétence pour

• L'aide générale à la programmation, la météo, ou des tâches non liées
• Analyser des systèmes que l'utilisateur ne possède pas ou n'a pas la permission de tester
• L'exploitation malveillante ou l'exfiltration de données

Ressources supplémentaires

• Profils et indicateurs : references/profiles-and-flags.md
• Formats de sortie et CI : references/output-and-ci.md
• Dépannage : references/troubleshooting.md
• Politique d'autorisation : references/authorization.md