Ganancias:
- Capacidad para comprender que la inteligencia artificial amplía el alcance del auditor, pero no lo reemplaza, y es útil para escanear categorías y encontrar borradores.
- Ser capaz de reconocer que la inteligencia artificial ha pasado por alto la vulnerabilidad original y el error de lógica empresarial, y que una declaración fluida y "segura" no es una garantía.
- Capacidad para clasificar los hallazgos según su nivel de gravedad y comprender que la aprobación final y la responsabilidad profesional recae en el auditor competente.
La auditoría de seguridad (examen sistemático de un contrato inteligente en busca de vulnerabilidades) es el trabajo de mayor responsabilidad de Web3. Una sola línea omitida por un auditor puede generar pérdidas de millones de dólares. En esta unidad aprenderá a utilizar la IA como asistente de auditoría; Aprenderemos desde generar pistas hasta escribir un resumen de los hallazgos. Pero la frase más crítica es ésta: la IA no controla; Es un asistente que agudiza la vista del auditor. La aprobación final corresponde al auditor competente que asume la responsabilidad profesional.
Por qué la auditoría es crítica para la seguridad
Un informe de auditoría asegura al proyecto y a los inversores que "este código ha sido revisado". Si esta garantía es falsa, las consecuencias son desastrosas: protocolo explotado, pérdida de financiación, proyecto colapsado. Por tanto, el uso de la IA en la inspección es la parte más cuidada de este módulo. La IA amplía el alcance del auditor (recuerda más patrones, lee más rápido) pero no reemplaza al auditor.
¿Por qué no pasa? Porque:
- La IA no puede ver la vulnerabilidad única/nueva que no está en los datos de entrenamiento.
- La IA a menudo pasa por alto el defecto en la lógica empresarial del protocolo: que el código es técnicamente correcto pero económicamente explotable.
- La IA puede dar una falsa tranquilidad al decir “seguro” en un lenguaje fluido; Este es el resultado más peligroso.
Capas de uso de IA en control
1. Escaneo inicial y recordatorio de patrón. La IA pasa por patrones de vulnerabilidad conocidos como una lista de verificación: reentrada, control de acceso, manipulación de Oracle, ejecución anticipada. Esto garantiza que el auditor no omita ninguna categoría.
2. Explicación del código. Explicar una función compleja a la IA en un lenguaje sencillo permite al auditor comprender rápidamente la lógica; pero la descripción siempre se compara con el código.
3. Redactar un borrador de hallazgos. Cuando el auditor encuentra una vulnerabilidad, la IA ahorra tiempo en la redacción del borrador del informe (descripción, impacto, solución propuesta).
4. Generar contrahipótesis. Pregúntele a la IA "¿cómo se puede abusar de esta función?" Preguntar "nos recuerda la perspectiva agresiva.
Atención: El hecho de que la IA diga "No encontré ninguna vulnerabilidad en este código" NO significa "este código es seguro". La prueba de ausencia no es ausencia de prueba. El hecho de que la IA no pueda encontrar algo no hace innecesario que el auditor examine esa zona.
Encontrar niveles de gravedad
Los hallazgos de la auditoría se clasifican según su nivel de gravedad. La IA debería utilizar este marco al generar borradores:
Nivel
Significado
ejemplo
crítico
Pérdida/bloqueo de fondos directamente posible
Retirar fondos con reentrada
alto
Impacto grave en determinadas condiciones.
Impresión no autorizada (perfecta)
medio
Impacto limitado o condición difícil
Pequeña pérdida con desviación de Oracle.
bajo
Riesgo menor, incumplimiento de buenas prácticas
Transmisión del evento faltante
Información
No seguridad, legibilidad
Falta de NatSpec
Aviso débil / Aviso fuerte
Aviso débil:
¿Es seguro este contrato?
Esta pregunta obliga a la IA a emitir un juicio absoluto e injustificado como "sí/no", exactamente lo que no queremos.
Potente mensaje:
Su función: asistente del auditor senior de contratos inteligentes. Escanee el siguiente contrato por seguridad. Revise las siguientes categorías una por una: reentrada, control de acceso, operaciones con números enteros, validación de entrada, datos de Oracle/externos, ejecución frontal, límite de gas. Para cada HALLAZGO: (1) línea de código relevante, (2) causa de riesgo, (3) gravedad estimada (Crítica/Alta/Media/Baja), (4) propuesta de solución. Estas son HIPÓTESIS POR CONFIRMAR; No dé un veredicto "seguro". Marque las áreas de las que no esté seguro y diga claramente "deje que el auditor confirme".
Cuatro plantillas copiables
1) Navegación basada en categorías:
Escanee este contrato para ver las siguientes categorías: reentrada, control de acceso, desbordamiento de enteros, validación de entradas, dependencia de Oracle, ejecución frontal, DoS/gas. Para cada categoría, diga "no hay/no hay riesgo/No estoy seguro" y conecte su justificación con la línea del código. No hagas un juicio final.
2) Contrahipótesis desde la perspectiva del atacante:
Piensa como un atacante: ¿cuáles son las formas de abusar de esta función? Escriba cada escenario paso a paso e indique qué condiciones se requieren. Estos escenarios son las hipótesis a probar; NO genere código de explotación real, solo describa el riesgo.
3) Borrador del informe de conclusiones:
Informe el siguiente hallazgo verificado en lenguaje de auditoría formal: título, gravedad, descripción, impacto, código afectado, pasos a reproducir, solución propuesta. Utilice un lenguaje mesurado y técnico; exageración. Suponga que el auditor confirma el hallazgo, no invente un nuevo hallazgo.
4) Arreglar la verificación:
A continuación se muestra una vulnerabilidad y la solución aplicada por el desarrollador. Examine si la solución realmente cierra la vulnerabilidad; marque si crea un nuevo efecto secundario o vulnerabilidad. No digas "cerrado" con seguridad; Termine con "debe confirmarse mediante pruebas".
Tres mini estuches (en números)
Caso 1: La IA evitó el salto de categoría. Un auditor estaba a punto de centrarse en un contrato de 400 líneas y saltarse la categoría de oráculo. El escaneo de categorías de AI advirtió que "los datos de precios provienen de una sola fuente, abiertos a manipulación". El auditor lo examinó y concluyó que efectivamente se trataba de un riesgo medio. Lección: La IA mantiene la disciplina de cobertura.
Caso 2: Falsa garantía de “seguridad”. Otro equipo preguntó a la IA “¿es esto seguro?” preguntó; "No parece haber un problema significativo", dijo AI. La inspección de la tripulación fue ligera. Luego, el auditor independiente encontró un error en la lógica empresarial: un cálculo que era técnicamente correcto pero cuyos incentivos eran explotables. Lección: La IA no detecta errores de lógica empresarial; No se puede confiar en que diga "seguro".
Caso 3: La redacción del informe ahorró 3 horas. El auditor pasó la mitad del día informando manualmente 8 hallazgos. Una vez que le entregué los hallazgos verificados a la IA e imprimí el borrador oficial, el tiempo se redujo en ~3 horas; El auditor dedicó tiempo a profundizar. Lección: La IA es segura y eficiente a la hora de informar porque los hallazgos ya han sido verificados humanamente.
Vulnerabilidad de la lógica empresarial: el punto ciego de la IA
Las vulnerabilidades más costosas a menudo no provienen de un error técnico en el código, sino de la explotabilidad de la lógica empresarial: explotación de redondeo de una cuenta de recompensa, secuestro de un voto por préstamo rápido, manipulación instantánea de un precio. Estos son casos en los que el código funciona "correctamente" pero el protocolo se puede engañar de forma económica. Es probable que la IA pase por alto esos errores, especialmente los específicos del protocolo. Por lo tanto, la revisión de la lógica empresarial es el área del auditor que requiere más recursos humanos y la que menos depende de la IA.
Pista: Pregúntele a la IA “¿cómo se pueden explotar los incentivos económicos de este protocolo?” y utilice los escenarios que surjan como punto de partida, pero recuerde que usted y su equipo deben realizar el análisis real.
Errores comunes
- Pregúntale a la IA "¿es seguro?" Pidiendo y confiando en tu sí. No se requiere juicio absoluto.
- Detener la revisión cuando la IA dice "No pude encontrarlo". La ausencia no es evidencia.
- Delegar la revisión de la lógica empresarial a la IA. Es su mayor punto ciego.
- No utilizar herramientas independientes (Slither, etc.). La IA por sí sola no es suficiente.
- Introducir en el informe el hallazgo elaborado por la IA sin verificarlo. Riesgo de alucinaciones.
- Tratando de asignar la responsabilidad del control a la IA. La responsabilidad es del experto.
En resumen
- La auditoría es crítica para la seguridad; La IA amplía el alcance del auditor pero no lo reemplaza.
- La IA pasa por alto la vulnerabilidad original y el error de lógica empresarial; Decir "seguro" no es seguridad.
- Los hallazgos se clasifican según el nivel de gravedad; La IA es útil para generar borradores.
- Las contrahipótesis y la selección de categorías preservan la disciplina de la inclusión.
- La aprobación final y la responsabilidad profesional siempre recae en el auditor competente.
Tarea de aplicación
Encuentre un contrato de muestra que contenga una vulnerabilidad conocida (con fines educativos, hay ejemplos de "contratos vulnerables" disponibles en código abierto). Aplique el mensaje "escaneo basado en categorías" a la IA. Tenga en cuenta si la IA: (1) encontró la vulnerabilidad real, (2) produjo hallazgos inventados/falsos, (3) hizo juicios absolutos como "seguro". Luego compárelo con una herramienta de análisis estático.
lista de verificación
- [] Pregúntale a la IA "¿es seguro?" En lugar de eso, hice un escaneo basado en categorías.
- [] Traté cada hallazgo como una hipótesis.
- [] Yo mismo/equipo realicé la revisión de la lógica empresarial.
- [] Lo validé de forma cruzada con una herramienta de análisis estático independiente.
- [] He confirmado que la IA no fabrica hallazgos.
- [ ] Clasifiqué los hallazgos según el nivel de gravedad.
- [ ] Acepté que la aprobación final recaiga en el auditor competente.