configs/ - optionale Kontextprofile

Diese JSON-Dateien sind optionale, antwortfreie Kontextprofile. Sie sind keine Flounder-Produktmodi und werden standardmäßig nicht geladen. Sie existieren für Fälle, in denen ein Operator dem Modell bewusst einen vertrauten Rahmen für eine Zielklasse geben möchte.

Jede ist ein projectContext-Gerüst für diese Klasse: die Art von Assets, Angreiferfähigkeiten, Vertrauensgrenzen, Invarianten und Fokusbereichen, die ein bekannter Stack typischerweise hat. Die Audit-Strategie liegt weiterhin beim Modell, und das Framework verlangt weiterhin einen Ausführungsnachweis.

Nicht standardmäßig verwendet — und das ist beabsichtigt

Das Framework lädt diese niemals von selbst. Ein standardmäßiger flounder run / flounder map / flounder audit enthält kein voreingestelltes Bug-Wissen: Der Lauf ist blind und ausführungsbasiert, sodass das Modell die Angriffsfläche aus der tatsächlichen Quelle aufzählen muss, bevor irgendein Audit-Versuch etwas finden kann. Übergibt man dem Modell eine vorgefertigte Liste, wo Bugs üblicherweise leben, wird es dadurch in Richtung der gelisteten Bereiche und weg von den nicht gelisteten gelenkt, und es besteht die Gefahr, dass das Audit zu Checklisten-Abgleich statt zu wirklichem Lesen wird. Das ist das Gegenteil dessen, wie dieses Tool neuartige Bugs finden soll, daher bleiben die Profile deaktiviert, sofern man nicht ausdrücklich darum bittet.

Sie existieren für die Fälle, in denen sich dieser Kompromiss lohnt: eine etablierte Schwachstellenklasse, bei der das Vorbelegen der üblichen Angriffsfläche wirklich nützlich ist, ein begrenztes Budget, das einen Vorsprung bei Fokus/Out-of-Scope braucht, oder das schnelle Abstecken des Umfangs für einen vertrauten Stack. Die Solidity/EVM- und ZK-Profile sind häufige Beispiele mit hoher Signalwirkung. In diesen Situationen aktivieren Sie sie:

flounder run --config ./configs/solidity-contract-audit.default.json \
        --target my-protocol --source ./contracts --corpus ./docs

Was ein Profil tatsächlich ändert

--config <file> wird in die Laufkonfiguration eingefügt (applyConfigOverrides), danach haben Kommandozeilen-Flags Vorrang – die --target / --source / --corpus / --max-steps, die Sie in der CLI übergeben, gewinnen gegenüber der Datei. Aus projectContext erreichen aktuell nur summary, focusAreas und outOfScope das Modell (eingewoben in seine Umfangsnotiz). Die umfangreicheren Felder unten sind derzeit nur Dokumentation/Gerüst – sie dokumentieren das Bedrohungsmodell für einen menschlichen Autor, werden aber noch nicht in den Prompt eingespielt.

{
  "targetName": "…",
  "sourcePaths": [],          // usually left empty; pass the real target via --source
  "corpusPaths": [],          // usually left empty; pass the project's own docs via --corpus
  "thinkingLevel": "xhigh",
  "projectContext": {
    "summary": "…",            // ── injected into the model's scope note
    "focusAreas": ["…"],       // ── injected
    "outOfScope": ["…"],       // ── injected
    "criticalAssets": ["…"],         // scaffold only (declared, not yet prompted)
    "attackerCapabilities": ["…"],   // scaffold only
    "trustBoundaries": ["…"],        // scaffold only
    "securityInvariants": ["…"],     // scaffold only
    "scenarioGuidance": ["…"]        // scaffold only
  }
}

Lassen Sie sourcePaths / corpusPaths im Profil leer und übergeben Sie auf der Kommandozeile das echte Ziel sowie die eigenen Spezifikationen/Dokumente des Projekts. Ein Profil ist ein Rahmen, kein Ersatz für das tatsächliche Material des Ziels.

Die Grenze, die ein Profil nicht überschreiten darf

Ein Profil ist Kontext, niemals ein Urteil. Es darf dem Modell sagen, wo es suchen soll; es darf dem Modell nicht sagen, was es finden wird. Eine Bestätigung kommt weiterhin nur aus der Ausführung – ein Befund ist real, weil ein PoC lief, niemals weil er zu einem Profil passte. (Das scenarioGuidance der Profile sagt es unmissverständlich: „Schreiben Sie keine statischen Bug-Regeln, die Befunde behaupten.")

Dieses Verzeichnis erweitern

Dies ist die optionale Heimat für Domänen-Kontextpakete. Um eines hinzuzufügen, halten Sie es generisch für eine Klasse und antwortfrei: Erfassen Sie die Angriffsfläche und Invarianten, die eine Klasse tendenziell hat, niemals einen spezifischen bekannten Bug in einem spezifischen Ziel. Alles Zielspezifische gehört in das --corpus des betreffenden Audits, nicht hierher.