Herramientas de seguridad de Cyfrin: un flujo de trabajo práctico para auditorías de contratos inteligentes

Alcance y el modelo mental detrás de una revisión al estilo Cyfrin

Los materiales públicos de Cyfrin describen una pila de seguridad construida en torno a cuatro capas: auditorías manuales de contratos inteligentes, análisis estático automatizado a través de Aderyn, una base de datos agregada de hallazgos a través de Solodit y educación para desarrolladores a través de Updraft y CodeHawks. La forma útil de pensar en esta pila es como un embudo. Las herramientas automatizadas y los hallazgos históricos eliminan el ruido de baja severidad; las auditorías competitivas y la educación desarrollan la intuición del revisor; la revisión manual dedica la costosa atención humana a la lógica, la economía y el control de acceso.

Este artículo cubre las capas automatizadas y de referencia que puede ejecutar usted mismo antes de contratar a cualquier auditor. No pretende reproducir una auditoría paga de Cyfrin, ni afirma qué redes o servicios admite Cyfrin más allá de lo que indican sus repositorios públicos y su sitio. Cuando se necesite una elección concreta de endpoint RPC, utilice la guía de endpoints RPC o pregunte a RPC Assistant para obtener una recomendación de proveedor en lugar de codificar un endpoint de esta página.

• Comportamiento documentado: Aderyn es un analizador estático de Solidity escrito en Rust y publicado bajo GPL-3.0 en la organización de GitHub de Cyfrin.
• Comportamiento documentado: Solodit agrega hallazgos de auditorías de contratos inteligentes; CodeHawks aloja auditorías competitivas; Updraft aloja cursos para desarrolladores y de seguridad.
• Recomendación: ejecute el análisis estático y la revisión de la lista de verificación antes de solicitar una cotización, porque reduce la superficie que un revisor humano debe clasificar.

Requisitos previos y supuestos

El flujo de trabajo asume un proyecto de Solidity que utiliza Hardhat o Foundry con un archivo de bloqueo comprometido, una cadena de herramientas de Node.js o Rust disponible localmente y acceso de lectura a un endpoint RPC público o privado para la red de destino. Necesita acceso de escritura al repositorio para agregar trabajos de CI y un lugar para almacenar los informes generados como artefactos de compilación.

No necesita una cuenta de Cyfrin para ejecutar Aderyn ni para leer informes de auditoría públicos. Los compromisos de auditoría pagados, las pistas de certificación y algunas funciones de la plataforma son ofertas comerciales separadas; trate su disponibilidad como algo que debe confirmar directamente con el proveedor en lugar de asumirlo a partir de este artículo.

Instalación y ejecución del análisis estático Aderyn

Aderyn se distribuye como un binario de Rust y se puede instalar a través de Cargo o un binario de lanzamiento. Ejecutarlo contra un proyecto compilado produce un informe en Markdown o JSON de los detectores activados. La primera ejecución suele ser ruidosa; el valor proviene de clasificar cada clase de detector una vez y luego codificar esa clasificación como una línea base para que las ejecuciones posteriores solo muestren nuevos hallazgos.

El siguiente comando es un punto de partida ejecutable. Reemplace la ruta del proyecto con la raíz de su repositorio y mantenga el informe fuera del árbol de fuentes para que no se confirme accidentalmente.

cargo install aderyn
cd /path/to/your-solidity-project
aderyn . --output report.md
# JSON output for CI ingestion
aderyn . --output report.json --output-format json
# Fail the build only on high-severity detectors (check --help for exact flags in your version)
aderyn . --output report.json --output-format json --fail-on high

Asignación de hallazgos a una lista de verificación de auditoría

Cyfrin publica un repositorio de listas de verificación de auditoría agregadas que agrupa las clases de vulnerabilidad comunes por categoría, como control de acceso, aritmética, llamadas externas y uso de oráculos. En lugar de leerlo de arriba a abajo, asigne cada hallazgo del detector Aderyn a una entrada de la lista de verificación y registre si el hallazgo es un verdadero positivo, un falso positivo o un riesgo aceptado con una justificación por escrito.

Este paso de asignación es donde se crea la mayor parte del valor. Convierte un informe de herramienta sin procesar en un documento listo para auditoría que un revisor humano puede hojear. Almacene la asignación en el repositorio, por ejemplo como security/triage.md, para que sobreviva a los cambios de equipo.

• Verdadero positivo: corrija el código y agregue una prueba de regresión que falle antes de la corrección.
• Falso positivo: documente la invariante que hace que el detector no sea aplicable.
• Riesgo aceptado: registre el propietario, la justificación y la fecha de vencimiento de la aceptación.

Referencia cruzada de hallazgos históricos con Solodit

Solodit agrega hallazgos de muchos informes de auditoría públicos, lo que lo hace útil para responder una pregunta concreta: ¿este patrón exacto ha sido explotado o señalado antes, y cómo se remedió? Busque por tipo de protocolo y por la forma específica de la función en lugar de solo por palabra clave, porque los términos genéricos devuelven demasiado ruido.

Trate los resultados de Solodit como arte previo, no como prueba de que su código es seguro. Un hallazgo que aparece en el informe de otro protocolo puede no ser aplicable a su arquitectura, y la ausencia de un hallazgo coincidente no dice nada sobre su código. El resultado correcto de este paso es una lista corta de posibles problemas a verificar manualmente, cada uno vinculado a su informe de origen.

Verificación del comportamiento desplegado contra una cadena en vivo

El análisis estático no puede ver el estado desplegado. Antes de una auditoría, confirme que el bytecode que analizó coincide con lo que está desplegado y que los roles privilegiados están configurados como se documenta. Un pequeño script que lee las asignaciones de roles y los parámetros clave a través de un endpoint RPC detecta la deriva de configuración que ninguna herramienta a nivel de código fuente encontrará.

El siguiente ejemplo usa ethers.js y lee una constante de rol y una dirección de propietario. Reemplace RPC_URL, CONTRACT_ADDRESS y el ABI con los valores de su despliegue. Para la selección de proveedores entre redes, consulte endpoints RPC multicadena y la descripción general del servicio API.

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const address = process.env.CONTRACT_ADDRESS;
const abi = [
  "function owner() view returns (address)",
  "function hasRole(bytes32 role, address account) view returns (bool)",
  "function DEFAULT_ADMIN_ROLE() view returns (bytes32)"
];

const contract = new ethers.Contract(address, abi, provider);
const [owner, adminRole] = await Promise.all([
  contract.owner(),
  contract.DEFAULT_ADMIN_ROLE()
]);
const ownerIsAdmin = await contract.hasRole(adminRole, owner);

console.log({ address, owner, ownerIsAdmin });
if (!ownerIsAdmin) {
  console.warn("Owner does not hold DEFAULT_ADMIN_ROLE; confirm this is intentional.");
}

Resultados de verificación esperados y cómo registrarlos

Una pasada de preauditoría exitosa produce cuatro artefactos: un informe de Aderyn, un documento de clasificación con cada clase de detector resuelta, una lista de referencias cruzadas de Solodit con enlaces y una instantánea del estado de despliegue del script RPC. Registre el hash de confirmación, las versiones de las herramientas y el número de bloque junto a cada artefacto para que los resultados sean reproducibles.

Utilice una tabla de resultados como la siguiente en su repositorio. No copie números de otro proyecto; complete cada celda con su propia ejecución. La tabla es una plantilla, no un punto de referencia.

• | Artefacto | Comando o fuente | Confirmación / bloque | Revisor | Estado |
• | Informe de Aderyn | aderyn . --output report.json | <commit> | <name> | <open/closed> |
• | Documento de clasificación | security/triage.md | <commit> | <name> | <open/closed> |
• | Referencias cruzadas de Solodit | registro de búsqueda manual | n/a | <name> | <open/closed> |
• | Instantánea de despliegue | salida del script RPC | <block> | <name> | <open/closed> |

Adición del flujo de trabajo a CI

El modo de falla más común es un análisis único que nunca se vuelve a ejecutar. Integre Aderyn en CI para que cada solicitud de extracción produzca un informe nuevo y compárelo con la línea base de la rama predeterminada. Un enfoque simple es cargar el informe JSON como artefacto y ejecutar un pequeño script que compare los recuentos de detectores por severidad.

Mantenga el trabajo de CI sin bloqueo al principio, luego promueva detectores específicos a bloqueantes una vez que el equipo los haya clasificado. Bloquear con el conjunto completo de detectores el primer día suele hacer que los desarrolladores omitan la verificación por completo.

# .github/workflows/security.yml (excerpt)
name: security
on: [pull_request]
jobs:
  aderyn:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - run: cargo install aderyn
      - run: aderyn . --output report.json --output-format json
      - uses: actions/upload-artifact@v4
        with:
          name: aderyn-report
          path: report.json

Solución de problemas comunes

Los analizadores estáticos fallan de manera predecible. La mayoría de los falsos negativos provienen de una compilación incompleta, y la mayoría de los falsos positivos provienen de detectores que no pueden ver invariantes entre contratos. Aborde primero la compilación, porque un proyecto que no se compila limpiamente producirá un informe engañosamente pequeño.

Los scripts RPC fallan por un conjunto diferente de razones: límites de velocidad, ID de cadena incorrectos y desajustes de ABI después de una actualización. Registre el ID de cadena devuelto por el proveedor y compárelo con el valor esperado antes de confiar en cualquier resultado de lectura.

• Informe de Aderyn vacío o muy pequeño: confirme que el proyecto compila y que el argumento de ruta apunta a la raíz de origen, no a la raíz del repositorio.
• Activaciones de detectores en código generado o de terceros: excluya esas rutas explícitamente en lugar de ignorar todo el detector.
• El script RPC devuelve null: verifique que el ABI coincida con la implementación desplegada, especialmente detrás de proxies.
• Tiempos de espera intermitentes de RPC: pase a un endpoint dedicado; consulte nodos dedicados y precios de RPC.

Limitaciones y compensaciones

Las herramientas automatizadas cubren una minoría de las clases de explotación reales. Los errores de lógica, la manipulación económica, los fallos de diseño de oráculos y los ataques de gobernanza generalmente requieren revisión humana y, a menudo, simulación específica del protocolo. Aderyn y analizadores similares se entienden mejor como un filtro que protege la atención del auditor, no como un sustituto de ella.

También hay un costo de mantenimiento. Las líneas base de los detectores se desvían a medida que las herramientas se actualizan, las listas de verificación quedan obsoletas y los trabajos de CI acumulan excepciones. Reserve tiempo cada trimestre para volver a clasificar la línea base y eliminar las supresiones que ya no se aplican. Si su equipo no puede mantener esa cadencia, un flujo de trabajo más estrecho que realmente se ejecute es mejor que uno integral que se abandona.

Próximos pasos hacia un compromiso de auditoría

Una vez que existan los cuatro artefactos y CI esté en verde, tendrá un punto de partida defendible para una revisión paga o una auditoría competitiva en CodeHawks. Prepare una breve nota de arquitectura que cubra los supuestos de confianza, los roles privilegiados, las rutas de actualización y las dependencias externas, porque esas son las áreas donde la revisión manual pasa más tiempo.

Para los equipos que también operan infraestructura, verifique que la capa RPC utilizada para el despliegue y el monitoreo sea estable antes de la ventana de auditoría; un endpoint poco confiable durante una revisión en vivo desperdicia el tiempo del revisor. Compare opciones a través de redes de OnFinality y la guía de endpoints RPC, y use RPC Assistant cuando necesite una recomendación directa de proveedor para una cadena específica.