
Auditor de seguridad de sombrero blanco autónomo para revisión de código impulsada por IA, investigación de bug bounty, construcción de exploits y verificación basada en ejecución.
configs/ - perfiles de contexto opcionalesEstos archivos JSON son perfiles de contexto opcionales y sin respuestas predefinidas. No son modos del producto Flounder y no se cargan por defecto. Existen para casos en los que un operador desea deliberadamente proporcionar al modelo un marco familiar para una clase de objetivo.
| Archivo | Contexto opcional |
|---|---|
vulnerability-audit.default.json | contexto genérico de auditoría de seguridad (independiente del dominio) |
zk-constraint-audit.default.json | circuitos de conocimiento cero / sistemas de restricciones |
solidity-contract-audit.default.json | contratos inteligentes Solidity / EVM |
thegraph-contracts.default.json | contratos del protocolo The Graph |
cairo-starknet-audit.default.json | contratos Cairo y componentes relacionados con Starknet |
Cada uno es un andamio projectContext para esa clase: el tipo de activos, capacidades del atacante, límites de confianza, invariantes y áreas de enfoque que una pila conocida tiende a tener. El modelo sigue siendo dueño de la estrategia de auditoría y el marco aún requiere prueba de ejecución.
El marco nunca carga estos archivos por sí solo. Una ejecución por defecto de flounder run / flounder map / flounder audit lleva ningún conocimiento preestablecido de errores: la ejecución es ciega y está basada en la ejecución, por lo que el modelo debe enumerar la superficie de ataque a partir de la fuente real antes de que cualquier prueba de auditoría pueda encontrar algo. Entregar al modelo una lista preescrita de dónde suelen vivir los errores lo sesga hacia las áreas listadas y lo aleja de las no listadas, y corre el riesgo de convertir la auditoría en una verificación de lista en lugar de lectura. Eso es lo opuesto a cómo esta herramienta está destinada a encontrar errores novedosos, por lo que los perfiles permanecen desactivados a menos que los solicites.
Existen para los casos en los que esa compensación vale la pena: una clase de vulnerabilidad muy transitada donde sembrar la superficie común es genuinamente útil, un presupuesto limitado que necesita una ventaja en el enfoque/fuera de alcance, o enmarcar rápidamente el alcance para una pila familiar. Los perfiles de Solidity/EVM y ZK son ejemplos comunes de alta señal. En esas situaciones, opta por participar:
flounder run --config ./configs/solidity-contract-audit.default.json \
--target my-protocol --source ./contracts --corpus ./docs
--config <archivo> se fusiona en la configuración de ejecución (applyConfigOverrides), luego las banderas de línea de comandos lo anulan — por lo que --target / --source / --corpus / --max-steps que pases en la CLI ganan sobre el archivo. De projectContext, solo summary, focusAreas y outOfScope llegan actualmente al modelo (integrados en su nota de alcance). Los campos más ricos a continuación son documentación/andamio hoy — registran el modelo de amenazas para un autor humano pero aún no se inyectan en el 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
}
}
Deja sourcePaths / corpusPaths vacíos en el perfil y pasa el objetivo real y las especificaciones/documentos propios del proyecto en la línea de comandos. Un perfil es un marco, no un sustituto del material real del objetivo.
Un perfil es contexto, nunca un veredicto. Puede decirle al modelo dónde mirar; no puede decirle al modelo lo que encontrará. La confirmación aún proviene solo de la ejecución — un hallazgo es real porque se ejecutó una PoC, nunca porque coincidió con un perfil. (El propio scenarioGuidance de los perfiles lo dice explícitamente: "No escribas reglas estáticas de errores que reclamen hallazgos.")
Este es el hogar de participación voluntaria para paquetes de contexto de dominio. Para agregar uno, mantenlo genérico para una clase y sin respuestas: captura la superficie de ataque y los invariantes que una clase tiende a tener, nunca un error conocido específico en un objetivo específico. Cualquier cosa específica del objetivo pertenece al --corpus de esa auditoría, no aquí.