Ravage

Ravage ist ein evidenzbasiertes CLI zur Bewertung einer laufenden Webanwendung, die dir gehört oder für die du ausdrücklich zur Durchführung von Tests autorisiert bist. Es kombiniert deterministische Aufklärung und Validierung mit einer optionalen modellgesteuerten Angriffsschleife und hält dabei Umfang, Authentifizierung, Traffic-Abrechnung und Beweise in code-eigenen Grenzen.

Ravage ist eine Forschungs-Alpha vor Version 1.0. Verwende Wegwerf-Umgebungen und eine schriftliche Rules of Engagement. Sicherheitstests können den Zustand der Anwendung verändern; Ravage behebt keine Befunde und stellt keine Fixes bereit.

Quickstart · Authentifizierung · Ergebnisse · Funktionen · Dokumentation

Anforderungen

• Python 3.12
• Git
• macOS, Linux oder WSL
• Docker nur für containerisierte Tools, XBEN und Integrationstests
• Ein Provider-API-Schlüssel nur für modellgesteuerte Befehle

Der normale erste Scan benötigt keinen Modellschlüssel, Browser, Docker-Daemon oder externen Scanner.

Installation aus dem Quellcode

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

Das Bootstrap erstellt .venv und installiert den Workspace. Verwende scripts/bootstrap.sh --dev für Entwicklungsabhängigkeiten, --browser für Browserunterstützung oder --install-browser, um zusätzlich Chromium zu installieren.

Fünf-Minuten lokaler Quickstart

Starte zuerst deine Anwendung. Dieses Beispiel geht davon aus, dass sie auf http://127.0.0.1:3000 lauscht.

1. Erstelle einen abgegrenzten Engagement-Brief und eine private Umgebungsdatei:

   root@kitploit:~

   ravage init http://127.0.0.1:3000 \
     --brief ravage-brief.yaml \
     --env-file .env.ravage \
     --description "Autorisierte Bewertung meiner lokalen Entwicklungs-App."
   

2. Überprüfe ravage-brief.yaml. Prüfe das Ziel, die In-Scope-Routen, Ausschlüsse, das Anfragebudget, die Ratenbegrenzung, die Ziele und die Erfolgskriterien.

3. Führe einen Oberflächenscan ohne Modell durch:

   root@kitploit:~

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

Der Befehl gibt das Ausführungsverzeichnis aus. Kopiere diesen Pfad und verwende ihn als RUN_DIR in den untenstehenden Inspektionsbefehlen.

Den modellgesteuerten Agenten ausführen

Füge einen unterstützten Provider-Schlüssel, z. B. OPENAI_API_KEY, zu .env.ravage hinzu. Ravage liest diese Datei direkt; verwende sie nicht als Shell-Source.

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

--allow-paid-models ist eine ausdrückliche Bestätigung, dass der Lauf Providerkosten verursachen kann. Modellauswahl, lokale Provider und reproduzierbare Profile sind in Modell-Provider dokumentiert.

Authentifiziertes Testen

Füge dem Brief eine dedizierte Testidentität hinzu:

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

Fülle die generierten Geheimnisreferenzen aus, verifiziere die Sitzung und greife dann mit der ausgewählten Identität an:

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

Formular-Login, Bearer-Tokens und feste statische Header werden unterstützt. Verwaltete Anmeldedaten bleiben innerhalb des authentifizierten HTTP-Owners; Prozess-, Python- und Befehls-Lanes werden blockiert, wenn eine Identität ausgewählt ist. Siehe Authentifizierung für Einrichtung und Einschränkungen.

Autorisierte Remote-Ziele

Remote-Ausführung ist fail-closed und erfordert ein explizites Flag. Beginne mit einem risikoarmen Oberflächenscan:

ravage init https://staging.example.test \
  --brief ravage-brief.yaml \
  --env-file .env.ravage \
  --description "Autorisierte Bewertung meiner Staging-Anwendung."

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

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

Für einen modellgesteuerten Remote-Lauf:

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

Autorisierte Remote-Angriffe verwenden standardmäßig die Low-Noise-Richtlinie für den gesamten Lauf: natives gemessenes HTTP, Pacing unter 1 RPS, eine Obergrenze für physische Anfragen, konservatives GET/HEAD-Caching und Deduplizierung, adaptives Backoff, begrenzte Wiederholungen und Circuit Breaking. Das dauerhafte Ledger übersteht Fortsetzungen. Details finden sich in Architektur.

Ergebnisse verstehen

Ravage unterscheidet Beobachtungen, Kandidatenbefunde und bestätigte Schwachstellen. Eine CTF-Flagge ist ein möglicher Beweis, keine Anforderung. Bei einer gewöhnlichen Anwendung kann ein Lauf nützlich und erfolgreich sein, ohne eine Flagge zu finden; bestätigte Schwachstellen werden trotzdem in den Bericht geschrieben.

Sobald ein Angriffslauf startet, ist sein kanonisches privates maschinenlesbares Artefakt RUN_DIR/report.json, einschließlich unvollständiger Läufe. --report schreibt außerdem RUN_DIR/report.md.

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

Für strukturiertes HTTP, das vom Agentengraphen erfasst wurde:

ravage traffic list RUN_DIR
ravage traffic show RUN_DIR REQUEST_ID

Der Bericht enthält Beweisreferenzen, Qualität der Anfrageabrechnung, Abschlussstatus und den Grund, warum ein unvollständiger Lauf gestoppt wurde. Behandle niemals eine unvalidierte Modellbehauptung als bestätigten Befund.

Funktionen

Wissens-Skills können die Priorisierung leiten, aber keine Tools hinzufügen, den Umfang erweitern oder Befunde bestätigen. Beginne mit:

ravage skills list builtin
ravage skills validate builtin

Das Improvement Lab nimmt bereinigte Strukturen früherer Läufe auf, bewertet Kandidaten-Patches in unabhängigen Workspaces, archiviert akzeptierte und abgelehnte Versionen und erfordert übereinstimmende No-Regression-Beweise vor der Promotion. Es ist ein Sidecar: Es verändert weder den Quellcode-Checkout noch promotet es sich selbst stillschweigend.

Passive Orbital- und Paketartefakte können separat inspiziert werden:

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

SATCOM-Unterstützung ist passives Parsen und Analysieren, kein Funksender oder Raumfahrzeug-Steuerungssystem.

Entwicklung

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

Docker-gestützte Integrationstests und eingefrorene XBEN-Vergleiche sind separate Release-Gates. Lies Benchmarking, bevor du Fallergebnisse interpretierst; eine glückliche Flagge ist kein Beweis für eine zuverlässige Verbesserung.

Dokumentation

• So verwendest du Ravage
• Einrichtung und Fehlerbehebung
• Authentifizierung
• Architektur
• Skills
• Passives SATCOM
• Improvement Lab
• Benchmarking
• Sicherheitsrichtlinie
• Mitwirken

Verwende ravage --help und ravage COMMAND --help für die genauen Optionen in deinem Checkout.

Lizenz

Apache License 2.0. Siehe LICENSE, DISCLAIMER und SECURITY.md.