Ravage

Ravage est un outil CLI axé sur les preuves, conçu pour évaluer une application web en cours d'exécution que vous possédez ou pour laquelle vous êtes explicitement autorisé à effectuer des tests. Il combine une reconnaissance et une validation déterministes avec une boucle d'attaque optionnelle pilotée par modèle, tout en maintenant le périmètre, l'authentification, la comptabilité du trafic et les preuves dans des limites contrôlées par le code.

Ravage est une alpha de recherche pré-1.0. Utilisez des environnements jetables et des règles d'engagement écrites. Les tests de sécurité peuvent modifier l'état de l'application ; Ravage ne corrige pas les résultats ni ne déploie de correctifs.

Démarrage rapide · Authentification · Résultats · Capacités · Documentation

Prérequis

• Python 3.12
• Git
• macOS, Linux ou WSL
• Docker uniquement pour les outils conteneurisés, XBEN et les tests d'intégration
• Une clé API de fournisseur uniquement pour les commandes pilotées par modèle

Le premier scan normal ne nécessite ni clé de modèle, ni navigateur, ni démon Docker, ni scanner externe.

Installation depuis les sources

git clone https://github.com/duriantaco/ravage.git
cd ravage
scripts/bootstrap.sh
source .venv/bin/activate
ravage doctor

Le bootstrap crée .venv et installe l'espace de travail. Utilisez scripts/bootstrap.sh --dev pour les dépendances de développement, --browser pour la prise en charge du navigateur, ou --install-browser pour installer également Chromium.

Démarrage rapide local en cinq minutes

Démarrez d'abord votre application. Cet exemple suppose qu'elle écoute sur http://127.0.0.1:3000.

1. Créez un brief d'engagement limité et un fichier d'environnement privé :

   root@kitploit:~

   ravage init http://127.0.0.1:3000 \
     --brief ravage-brief.yaml \
     --env-file .env.ravage \
     --description "Évaluation autorisée de mon application de développement locale."
   

2. Examinez ravage-brief.yaml. Vérifiez la cible, les routes dans le périmètre, les exclusions, le budget de requêtes, la limite de débit, les objectifs et les critères de réussite.

3. Lancez un scan de surface sans modèle :

   root@kitploit:~

   ravage doctor --workflow scan --brief ravage-brief.yaml
   ravage scan ravage-brief.yaml --probe surface_map --report
   

La commande affiche le répertoire d'exécution. Copiez ce chemin et utilisez-le comme RUN_DIR dans les commandes d'inspection ci-dessous.

Exécuter l'agent piloté par modèle

Ajoutez une clé de fournisseur prise en charge, telle que OPENAI_API_KEY, à .env.ravage. Ravage lit ce fichier directement ; ne l'utilisez pas comme source dans le shell.

ravage doctor --workflow attack --brief ravage-brief.yaml
ravage attack ravage-brief.yaml --allow-paid-models --report

--allow-paid-models est une reconnaissance explicite que l'exécution peut entraîner des frais de fournisseur. La sélection des modèles, les fournisseurs locaux et les profils reproductibles sont documentés dans Fournisseurs de modèles.

Tests authentifiés

Ajoutez une identité de test dédiée au brief :

ravage auth add ravage-brief.yaml \
  --identity user \
  --type form \
  --login /login \
  --health /account \
  --marker Logout \
  --env-file .env.ravage

Renseignez les références secrètes générées, vérifiez la session, puis attaquez avec l'identité sélectionnée :

ravage auth check ravage-brief.yaml --identity user
ravage attack ravage-brief.yaml \
  --identity user \
  --allow-paid-models \
  --report

La connexion par formulaire, les jetons bearer et les en-têtes statiques fixes sont pris en charge. Les identifiants gérés restent dans le propriétaire HTTP authentifié ; les canaux de processus, Python et de commande sont bloqués lorsqu'une identité est sélectionnée. Voir Authentification pour la configuration et les limites.

Cibles distantes autorisées

L'exécution à distance est fermée par défaut en cas d'échec et nécessite un indicateur explicite. Commencez par un scan de surface à faible impact :

ravage init https://staging.example.test \
  --brief ravage-brief.yaml \
  --env-file .env.ravage \
  --description "Évaluation autorisée de mon application de préproduction."

ravage doctor --workflow scan \
  --brief ravage-brief.yaml \
  --authorized-remote-target

ravage scan ravage-brief.yaml \
  --probe surface_map \
  --authorized-remote-target \
  --report

Pour une exécution distante pilotée par modèle :

ravage attack ravage-brief.yaml \
  --authorized-remote-target \
  --allow-paid-models \
  --report

Les attaques distantes autorisées utilisent par défaut la politique de faible bruit sur toute l'exécution : HTTP natif mesuré uniquement, cadence inférieure à 1 RPS, plafond de requêtes physiques, mise en cache et déduplication conservatrices GET/HEAD, backoff adaptatif, nouvelles tentatives limitées et rupture de circuit. Le registre durable survit à la reprise. Les détails sont dans Architecture.

Comprendre les résultats

Ravage distingue les observations, les résultats candidats et les vulnérabilités confirmées. Un drapeau CTF est une preuve possible, pas une exigence. Sur une application ordinaire, une exécution peut être utile et réussie sans trouver de drapeau ; les vulnérabilités confirmées sont toujours écrites dans le rapport.

Une fois qu'une exécution d'attaque démarre, son artefact machine lisible canonique privé est RUN_DIR/report.json, y compris pour les exécutions incomplètes. --report écrit également RUN_DIR/report.md.

ravage observe RUN_DIR
ravage audit verify RUN_DIR
ravage report RUN_DIR --brief ravage-brief.yaml

Pour le HTTP structuré capturé par le graphe de l'agent :

ravage traffic list RUN_DIR
ravage traffic show RUN_DIR REQUEST_ID

Le rapport inclut les références de preuves, la qualité de la comptabilité des requêtes, le statut d'achèvement et la raison pour laquelle une exécution incomplète s'est arrêtée. Ne traitez jamais une assertion de modèle non validée comme un résultat confirmé.

Capacités

Les compétences de connaissances peuvent guider la priorisation, mais ne peuvent pas ajouter d'outils, étendre le périmètre ou confirmer des résultats. Commencez par :

ravage skills list builtin
ravage skills validate builtin

Le Laboratoire d'amélioration ingère la structure d'exécutions antérieures anonymisées, évalue les correctifs candidats dans des espaces de travail indépendants, archive les versions acceptées et rejetées, et exige des preuves de non-régression appariées avant la promotion. C'est un composant auxiliaire : il ne modifie pas la copie source ni ne se promeut silencieusement.

Les artefacts orbitaux et de paquets passifs peuvent être inspectés séparément :

ravage satcom inspect orbit.tle --format tle --output orbit-report.json
ravage satcom inspect capture.bin \
  --format ccsds-space-packets \
  --direction auto \
  --output packet-report.json

La prise en charge SATCOM est une analyse et un parsing passifs, pas un émetteur radio ni un système de contrôle de vaisseau spatial.

Développement

scripts/bootstrap.sh --dev
source .venv/bin/activate
python -m pytest -m "not integration" -q
python -m ruff check --select E9,F .
python scripts/qa/check_docs.py
python scripts/qa/check_release.py

Les tests d'intégration basés sur Docker et les comparaisons XBEN figées sont des portes de publication distinctes. Lisez Benchmarking avant d'interpréter les résultats de cas ; un drapeau chanceux n'est pas une preuve d'amélioration fiable.

Documentation

• Comment utiliser Ravage
• Configuration et dépannage
• Authentification
• Architecture
• Compétences
• SATCOM passif
• Laboratoire d'amélioration
• Benchmarking
• Politique de sécurité
• Contribution

Utilisez ravage --help et ravage COMMAND --help pour les options exactes dans votre copie.

Licence

Licence Apache 2.0. Voir LICENSE, DISCLAIMER et SECURITY.md.