Auditoría de código con IA: qué revisar y cuándo la necesitas

Dos preguntas, no una

Una auditoría responde a dos preguntas distintas, y la mayoría de las herramientas solo plantean una.

1. ¿Construimos lo que acordamos? El producto tiene requisitos, escritos en alguna parte. ¿Están todos implementados? ¿Alguno cambió sin que nadie lo dijera? ¿Se quedó algo por el camino sin que nadie decidiera eliminarlo?
2. ¿Es seguro ponerlo delante de los clientes? ¿Puede una cuenta ver los datos de otra? ¿Hay secretos en el repositorio? ¿Un reintento de pago cobra dos veces?

La segunda pregunta se lleva casi toda la atención, porque los fallos de seguridad son caros y públicos. La primera se omite más a menudo, y en un producto pequeño suele ser donde aparecen las sorpresas: la funcionalidad prometida a un cliente que nunca se construyó, o el requisito que se reformuló después de la aprobación para que lo construido «cumpla».

Qué necesita la primera pregunta

No puedes comparar lo construido con requisitos que no existen, ni con requisitos que nadie puede probar. Por eso la primera mitad de una auditoría depende de un trabajo hecho mucho antes:

• Requisitos con clave, como REQ-014, que nunca cambian, para poder vincular el trabajo con ellos.
• Criterios de aceptación para cada uno: cómo lo comprobaría alguien en el producto en funcionamiento.
• Una versión congelada de lo acordado. Si los requisitos se pueden editar después de la aprobación, auditar contra «los requisitos» es auditar contra lo que digan hoy.

Con eso en su sitio, las comprobaciones son sencillas. Cada requisito Must (imprescindible) tiene trabajo terminado asociado. Cada criterio de aceptación se cumple en el producto en producción. Los requisitos que cambiaron después de la aprobación se señalan con la redacción antigua y la nueva. Los requisitos que se descartaron quedan registrados como decisiones, no se borran.

Qué necesita la segunda pregunta

Para un producto web o móvil pequeño, una revisión práctica de seguridad y fiabilidad cubre seis áreas:

• Control de acceso. Cada ruta que toca datos privados comprueba la sesión. Las acciones de administración comprueban un rol, no solo que haya alguien con la sesión iniciada. Cambiar un ID en una URL no permite llegar a los registros de otra cuenta. La mayoría de los hallazgos graves en productos pequeños están aquí.
• Secretos. Ninguna clave ni token en el repositorio ni en su historial. Ningún secreto del servidor expuesto al navegador a través de una variable de entorno pública. Las credenciales filtradas, rotadas.
• Dependencias. Vulnerabilidades conocidas comprobadas contra una base de datos de avisos real, como npm audit u OSV, con los identificadores de cada aviso registrados.
• Gestión de entradas. Consultas parametrizadas, nada de ejecución dinámica de código con datos del usuario, salida escapada, archivos subidos validados y peticiones desde el servidor a URL proporcionadas por el usuario restringidas.
• Flujos de dinero. Los gestores de pago son idempotentes, las firmas de los webhooks se verifican, los importes se calculan en el servidor, y los créditos o reembolsos no se pueden gastar dos veces con peticiones simultáneas.
• Operaciones. Los errores llegan a un sistema de monitorización que alguien lee, existen copias de seguridad y se ha probado una restauración, y las migraciones se aplican antes que el código que las necesita.

Y una comprobación más que es fácil olvidar: que esté en producción. Una auditoría de algo a lo que nadie fuera del equipo puede acceder no está terminada.

Dónde ayuda la IA

La IA es realmente útil en una auditoría, en puntos concretos:

• Leer rápido una base de código grande y señalar dónde mirar: cada gestor de rutas, cada lugar donde se calcula un precio, cada llamada que obtiene una URL.
• Triaje. Ordenar una lista larga de hallazgos según lo que primero cuesta dinero o expone datos.
• Redactar pasos de reproducción y correcciones sugeridas para un hallazgo que ya está confirmado.
• Explicar un hallazgo a quien tiene que corregirlo, en términos de su propio código.

Dónde estorba la IA

El fallo típico es una auditoría hecha de opiniones de un modelo. Si le preguntas a un modelo «¿este código es seguro?», te devolverá una lista muy segura de sí misma: parte será correcta, parte plausible pero errónea, y todo con el mismo formato. Un hallazgo que no puedes verificar es peor que ningún hallazgo: cuesta tiempo perseguirlo y enseña al equipo a ignorar el informe.

Así que las reglas de una auditoría asistida por IA son sencillas:

• Sin pruebas, no hay hallazgo. Cada hallazgo tiene una ubicación (archivo y línea, o una ruta), pruebas que muestran el problema y pasos para reproducirlo. Sin pruebas, no hay hallazgo.
• Los hallazgos salen de comprobaciones, no de impresiones. Los avisos de dependencias salen de una base de datos de avisos, no de la memoria. Los hallazgos de control de acceso salen de cambiar de verdad un ID y ver qué pasa.
• Identidad estable. Dale a cada hallazgo una huella para que, al repetir la auditoría, sepas qué se corrigió, en lugar de obtener otro muro de texto.
• Un veredicto, no una sensación. La auditoría se aprueba cuando no quedan hallazgos críticos ni altos abiertos y el producto está en producción. Si no, es otra iteración.

Cuándo la necesitas

Un equipo pequeño no necesita un programa de auditoría continua. Necesita una auditoría en los momentos en que la respuesta importa:

• Antes de un lanzamiento público o del envío a una tienda de aplicaciones. El último momento barato para encontrar un agujero en el control de acceso.
• Cuando vuelve un trabajo externo. Un freelance, un estudio o un agente de programación ha construido algo a partir de tus requisitos. Es justo cuando hay que responder a «¿recibimos lo que acordamos?».
• Antes de una due diligence, o cuando heredas la base de código de otra persona.
• Después de cambios grandes en la autenticación, los pagos o el acceso a datos.

Entre esos momentos basta con un hábito más ligero: mantén los requisitos con clave, cita las claves en los commits y pull requests, y vuelve a revisar los flujos de dinero cada vez que cambien.

Dónde encaja Atrix AI y dónde no

Para dejar claro el alcance: Atrix AI no escanea ni analiza tu código. Las comprobaciones de seguridad y fiabilidad anteriores te corresponden a ti, a mano, con las herramientas mencionadas o con un revisor de confianza. Lo que hace Atrix AI es la parte de la auditoría que un espacio de trabajo puede responder con honestidad, y el registro de todo lo demás.

La primera pregunta: ¿construimos lo que acordamos? En Atrix AI aceptas tus requisitos y los congelas como una línea base numerada, que conserva la redacción exacta de cada requisito, además del PRD y los documentos de origen, tal como estaban. La auditoría de requisitos muestra entonces, para cada requisito de la línea base, si existe trabajo, si está en curso o si está terminado, y señala los requisitos cuya redacción cambió o que se descartaron después de congelarlos, así como los documentos congelados que se han editado desde entonces. Un requisito de una línea base no se puede borrar, solo marcar como Won't (no se hará), así que nada desaparece en silencio. Cada estado se calcula a partir de tus registros, no de la opinión de un modelo.

Trazabilidad. Los requisitos llevan claves permanentes. Cuando pasas el desarrollo a un agente de programación, el paquete de traspaso del modo Develop incluye los documentos y las claves, y pide que las claves aparezcan en los commits y pull requests, para que un auditor pueda vincular cada trabajo con su propósito. El agente de IA redacta los requisitos y planifica el trabajo; las personas deciden qué se acuerda.

Seguimiento de hallazgos. Cada hallazgo de tu auditoría se puede registrar como una tarea con prioridad, en el mismo proyecto que los requisitos a los que afecta, y los requisitos aceptados que no tienen trabajo asociado se pueden dividir en tareas. La segunda mitad de la auditoría ocurre fuera de Atrix; sus resultados no tienen por qué vivir en una hoja de cálculo.

Para las comprobaciones en sí, usa la lista de comprobación gratuita para auditorías de código. Incluye un registro de hallazgos con gravedad, ubicación, pruebas, reproducción y una corrección sugerida para cada fila.

En resumen

Una auditoría de código útil compara lo construido con requisitos acordados y verificables, y después comprueba que es seguro y que está en producción. La IA acelera la lectura, la priorización y la explicación. Nunca debería ser, por sí sola, el origen de un hallazgo. Empieza con requisitos que se puedan verificar y el resto de la auditoría será mucho más fácil.