Tests de cybersécurité web autonomes axés sur la preuve pour des cibles contrôlées et autorisées. Avec des laboratoires reproductibles, des pistes d'audit, des rapports et un benchmarking XBEN.
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
Le premier scan normal ne nécessite ni clé de modèle, ni navigateur, ni démon Docker, ni scanner externe.
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émarrez d'abord votre application. Cet exemple suppose qu'elle écoute sur
http://127.0.0.1:3000.
Créez un brief d'engagement limité et un fichier d'environnement privé :
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."
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.
Lancez un scan de surface sans modèle :
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.
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.
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.
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.
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é.
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.
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.
Utilisez ravage --help et ravage COMMAND --help pour les
options exactes dans votre copie.
Licence Apache 2.0. Voir LICENSE, DISCLAIMER et SECURITY.md.
| Capacité | Point d'entrée | Notes |
|---|
| Reconnaissance et sondes déterministes | ravage scan | Aucun modèle requis |
| Évaluation pilotée par modèle | ravage attack | Limitée par les preuves et le périmètre |
| Authentification gérée | ravage auth | Formulaire, bearer, en-tête statique |
| Inspection et relecture du trafic | ravage traffic | Artefacts limités au périmètre |
| Compétences de connaissances | ravage skills, ravage code-bug | Consultatif |
| Inspection SATCOM passive | ravage satcom inspect | Aucune émission |
| Évaluation XBEN | ravage xben | Harness de recherche basé sur Docker |
| Laboratoire d'amélioration | scripts/improvement_lab.py | Archive isolée |