Auditoría de Software Vibe-Coded: Qué Revisar Antes del Lanzamiento

Llegaste a un software funcional a base de prompts. Registra usuarios, muestra las pantallas correctas y funciona bien en una demo. Pero si nadie ha revisado la implementación, quedan supuestos importantes sin comprobar. Antes de que dependan de ella dinero real, datos personales o muchos usuarios, el código y su entorno operativo merecen una revisión basada en riesgos.

Esto no es un argumento contra construir con IA. Las herramientas asistidas por IA pueden acortar el camino hacia un prototipo. La preparación para producción sigue requiriendo las mismas disciplinas de desarrollo seguro que cualquier otro software. El Secure Software Development Framework de NIST las organiza en preparar la organización, proteger el software, producir software seguro y responder a vulnerabilidades.

¿Qué es una auditoría de vibe-coding?

Es una revisión estructurada y basada en riesgos de un sistema asistido por IA, más allá de sus funciones visibles. Una revisión funcional pregunta si el producto hace lo que espera el usuario. Una auditoría también pregunta quién puede leer o cambiar cada registro, qué pasa cuando falla una dependencia, dónde están las credenciales, cómo se tratan las peticiones duplicadas y qué pruebas respaldan un lanzamiento seguro.

Algunos fallos no aparecen en el happy path. Por ejemplo, una interrupción de red, el reintento de un pago o un identificador modificado para acceder a otra cuenta. Revisar código y configuración y ejecutar pruebas dirigidas ayuda a exponer esas condiciones antes del lanzamiento. El OWASP Application Security Verification Standard 5.0 ofrece una base actual para probar los controles técnicos de seguridad de aplicaciones web.

¿Qué debe cubrir la revisión?

El alcance exacto depende de la arquitectura y el perfil de riesgo. Estas son áreas habituales de revisión, no una afirmación de que todo código asistido por IA contiene los mismos defectos.

• Autenticación y autorización. Verifica que los controles del servidor impidan que un usuario lea o cambie recursos de otro. Broken Access Control sigue en primer lugar en el OWASP Top 10:2025. Eso lo convierte en una prioridad razonable, pero no demuestra que sea el hallazgo más frecuente de una auditoría concreta.
• Integridad de datos. Revisa límites transaccionales, restricciones, idempotencia y recuperación para que escrituras parciales o peticiones duplicadas no dejen un estado incoherente.
• Credenciales y configuración. Busca secretos en bundles de cliente, repositorios, logs y artefactos de build, además de permisos de ejecución demasiado amplios.
• Rutas de error y recuperación. Prueba timeouts, dependencias no disponibles, resultados vacíos, reintentos y recuperación visible para el usuario, no solo llamadas correctas.
• Rendimiento y capacidad. Inspecciona patrones de consulta y mide cargas representativas. Un patrón que funciona con datos de demo puede volverse lento o caro a mayor escala, pero el umbral debe medirse, no adivinarse.
• Dependencias y licencias. Inventaría componentes, revisa vulnerabilidades conocidas y mantenimiento, y comprueba que las obligaciones de licencia encajen con la distribución y uso previstos. NIST SP 800-204D incluye expresamente la revisión de dependencias y controles para evitar secretos en commits.
• Evidencia de tests. Evalúa tests unitarios, de integración, seguridad y aceptación. La cobertura varía según el proyecto. La meta es tener evidencia sobre el comportamiento de mayor riesgo, no un porcentaje supuesto.

"Una demo pulida demuestra que el happy path funciona. Decidir un lanzamiento también exige evidencia sobre control de acceso, manejo de fallos, integridad de datos y recuperación."

¿Qué hallazgos bloquean el lanzamiento y cuáles pueden esperar?

La severidad debe reflejar impacto, probabilidad, exposición y salvaguardas disponibles. Usamos tres categorías prácticas y documentamos la razón de cada hallazgo.

• Blocker. Una vía creíble hacia datos de clientes expuestos, movimientos de dinero no autorizados, corrupción irrecuperable o un resultado igualmente grave puede justificar retrasar el lanzamiento hasta corregirla o contenerla.
• Alto. Una debilidad relevante con exposición significativa suele requerir remedio antes de un despliegue más amplio, aunque todavía no haya causado un incidente.
• Limpieza. El trabajo de mantenibilidad o coherencia de menor riesgo suele poder programarse, siempre que no se combine con otras debilidades para formar un riesgo mayor.

La clasificación depende del contexto. El mismo defecto puede tener distinta prioridad en una herramienta interna de solo lectura y en un producto de pagos expuesto a internet.

¿Qué obtienes de la auditoría?

El statement of work acordado debe definir los entregables. Wavect suele proponer un informe que explica cada problema, su severidad, la evidencia y la acción recomendada. Cuando la remediación está incluida, el alcance también puede cubrir una rama corregida y tests de regresión específicos. No debe suponerse que todo hallazgo o refactor está incluido si la propuesta no lo dice. Explicamos la mecánica de una pasada de hardening en QA para código generado por IA.

Auditoría, QA completo o reconstrucción: ¿cuál necesitas?

Son encargos distintos. La opción adecuada depende del estado del sistema y del riesgo empresarial.

Si el producto mueve dinero, el siguiente problema es ordenar las correcciones sin perder control de las rutas de pago activas. Nuestro caso anonimizado de remediación de arquitectura fintech muestra una secuencia específica de un proyecto para fundamentos tipados, autorización, idempotencia, webhooks y puertas de lanzamiento, sin recurrir por defecto a una reescritura total.

• Auditoría. Adecuada cuando el producto funciona en términos generales y primero se necesita una evaluación de riesgo acotada antes de lanzar, crecer o procesar pagos.
• QA completo. Adecuado cuando el producto necesita un proceso continuo de tests, revisiones, controles de lanzamiento y hardening a través de cambios sucesivos.
• Reconstrucción. Conviene evaluarla cuando la evidencia muestra que las restricciones centrales, la arquitectura o los patrones repetidos vuelven una remediación puntual desproporcionadamente arriesgada o cara. La comparación debe incluir el riesgo de migración y el coste de conservar lo que ya funciona. Reconstruir no es automáticamente más barato.

¿Cuánto cuesta una auditoría de vibe-coding y cuánto tarda?

A 2 de septiembre de 2026, Wavect utiliza para este servicio un rango de planificación de unos días laborables a unas dos semanas. Es un rango propio, no un benchmark del sector ni una promesa fija. El tamaño, la arquitectura, la documentación, el acceso al despliegue y la sensibilidad de los flujos de datos y dinero pueden cambiar el alcance. Confirmamos entregables, precio y calendario en la propuesta tras una primera revisión. Esta auditoría es una entrada a nuestro servicio de QA de software.