Tests de invariantes y fuzzing
Dejamos por escrito las propiedades que debe cumplir tu sistema y las probamos con baterías de invariantes stateful y fuzzing en Foundry.
Preparación de smart contracts antes de la auditoría
Las auditorías son caras y tienen el tiempo acotado. Cada hora que un auditor dedica a un test que falta, a un valor de retorno sin comprobar o a un error de redondeo que habría detectado un fuzzer es una hora menos para los problemas que solo un experto puede encontrar. El pre-audit hardening despeja ese terreno antes.
No es una auditoría de seguridad ni la sustituye. Prepara tu código para que la auditoría pueda centrarse en los problemas más profundos.
01 / PARA QUIÉN ES
Para quién es
- Equipos con una auditoría reservada para las próximas semanas
- Bases de código que han crecido rápido y tienen una cobertura de tests escasa o desigual
- Equipos que quieren que el informe de auditoría trate de los problemas difíciles, no de lo básico
02 / QUÉ HACEMOS
Qué hacemos
Análisis estático
Slither y Aderyn, con cada resultado clasificado como problema real, falso positivo o decisión de diseño asumida.
Revisión de huecos en los tests
Cobertura de líneas y ramas, más mutation testing en las rutas críticas para encontrar tests que no pueden fallar.
Correcciones
Los problemas que encontramos se corrigen con cambios mínimos y tests de regresión, o se documentan para que tu equipo decida.
Documentación para los auditores
Notas de arquitectura, riesgos conocidos y la lista de invariantes, para que los auditores empiecen con contexto en lugar de adivinar.
03 / CÓMO FUNCIONA
Cómo funciona
- 01AlcanceAcceso al repositorio, un commit congelado y un presupuesto cerrado.
- 02HardeningDe dos a cuatro semanas de tests, análisis y correcciones, según el tamaño del código.
- 03InformeLos hallazgos, la clasificación del análisis estático y los riesgos que quedan, por escrito.
- 04EntregaTodo integrado en tu repositorio y listo para enviar a la firma auditora.
04 / QUÉ RECIBES
Qué recibes
| ENTREGABLE | FORMATO |
|---|---|
| Nuevos tests de invariantes, de fuzzing y de regresión en tu repositorio | Repositorio |
| Correcciones de los problemas encontrados, cada una en su propio commit | Repositorio |
| Un informe con los hallazgos, la clasificación del análisis estático y los riesgos que quedan | Documento |
| Documentación para los auditores | Documento |
05 / TRABAJOS RELACIONADOS
- Money market (open source), con una ronda de mutation testing sobre cada punto de redondeo
- Every rounding direction is a solvency decision
06 / FAQ
Preguntas sobre el pre-audit hardening
¿Es una auditoría de seguridad?
No. Es la preparación para una. Si tus contratos van a custodiar fondos de usuarios, deberías hacer igualmente una auditoría independiente.
¿Reducirá el coste de mi auditoría?
El presupuesto inicial suele depender del tamaño y la complejidad del código, así que rara vez baja. Un código bien preparado sí ayuda a evitar los costes extra: revisiones de correcciones más largas, rondas adicionales o una segunda auditoría cuando la primera encuentra demasiado.
¿El código tiene que estar terminado?
Funciona mejor cuando el código ya tiene todas sus funcionalidades y está cerca de congelarse para la auditoría. Antes de ese punto, suele encajar mejor una revisión de diseño (Protocol Design Review).
¿Podéis ayudar también después de la auditoría?
Sí. Nuestro soporte de auditorías (Audit Support & Remediation) cubre el triaje de los hallazgos, su corrección y el apoyo a los auditores en la revisión de las correcciones.