configs/ - profili di contesto opzionali

Questi file JSON sono profili di contesto opzionali, senza risposte preconfezionate. Non sono modalità di prodotto di Flounder e non vengono caricati per impostazione predefinita. Esistono per i casi in cui un operatore vuole deliberatamente dare al modello una cornice familiare per una classe di target.

Ciascuno è uno scaffold projectContext per quella classe: il tipo di asset, le capacità dell'attaccante, i trust boundary, gli invarianti e le aree di focus che uno stack noto tende ad avere. Il modello mantiene comunque il controllo della strategia di audit e il framework richiede comunque una prova di esecuzione.

Non usati per impostazione predefinita — ed è una scelta deliberata

Il framework non li carica mai da solo. Un flounder run / flounder map / flounder audit predefinito non include alcuna conoscenza preimpostata di bug: la run è cieca e basata sull'esecuzione, quindi il modello deve enumerare la superficie d'attacco dal sorgente effettivo prima che qualsiasi tentativo di audit possa trovare qualcosa. Consegnare al modello una lista pre-scritta di dove di solito vivono i bug lo orienta verso le aree elencate e lo allontana da quelle non elencate, e rischia di trasformare l'audit in un confronto con una checklist invece che in una lettura. Questo è l'opposto di come questo strumento è pensato per trovare bug nuovi, quindi i profili restano disattivati a meno che non vengano richiesti.

Esistono per i casi in cui quel compromesso vale la pena: una classe di vulnerabilità ampiamente esplorata in cui seminare la superficie comune è genuinamente utile, un budget limitato che ha bisogno di un vantaggio iniziale su focus/aree fuori ambito, o inquadrare rapidamente lo scope per uno stack familiare. I profili Solidity/EVM e ZK sono esempi comuni ad alto segnale. In quelle situazioni, attiva il profilo esplicitamente:

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

Cosa cambia realmente un profilo

--config <file> viene unito alla configurazione di esecuzione (applyConfigOverrides), poi i flag da riga di comando hanno la precedenza su di esso — quindi --target / --source / --corpus / --max-steps passati via CLI vincono sul file. Da projectContext, solo summary, focusAreas e outOfScope raggiungono attualmente il modello (intrecciati nella sua nota di scope). I campi più ricchi sotto sono oggi solo documentazione/scaffold — registrano il modello di minaccia per un autore umano ma non sono ancora iniettati nel prompt.

{
  "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
  }
}

Lascia sourcePaths / corpusPaths vuoti nel profilo e passa il target reale e gli spec/i documenti del progetto da riga di comando. Un profilo è una cornice, non un sostituto del materiale effettivo del target.

La linea che un profilo non deve superare

Un profilo è contesto, mai un verdetto. Può dire al modello dove guardare; non può dirgli cosa troverà. La conferma arriva comunque solo dall'esecuzione — un finding è reale perché un PoC è stato eseguito, mai perché corrisponde a un profilo. (Lo scenarioGuidance dei profili stessi lo dice apertamente: "Non scrivere regole statiche di bug che dichiarano finding.")

Estendere questa directory

Questa è la sede opzionale per pacchetti di contesto di dominio. Per aggiungerne uno, mantienilo generico per una classe e senza risposte preconfezionate: cattura la superficie d'attacco e gli invarianti che una classe tende ad avere, mai uno specifico bug noto in uno specifico target. Qualsiasi cosa specifica del target appartiene al --corpus di quell'audit, non qui.