Checklist de seguridad antes de publicar una aplicación hecha con vibe coding

Antes de publicar una aplicación hecha con vibe coding, identifica el commit exacto del lanzamiento, escanéalo y prueba sus límites de acceso, su manejo de secretos y sus caminos de fallo en un entorno controlado. Usa los hallazgos de vetkit como evidencia que revisar junto con tus tests y tu configuración de despliegue. Un escaneo superado no demuestra que la aplicación en ejecución sea segura ni que esté lista para publicarse.

Esta checklist es para la decisión de lanzamiento, después de la revisión de código. Para revisar línea a línea los cambios de un asistente, empieza por la checklist de revisión de código generado por IA. Guarda la evidencia que se describe a continuación junto con el lanzamiento, para que otra persona pueda saber qué se comprobó.

1. Vincula la evidencia al lanzamiento

• Anota el SHA del commit y el artefacto de build que tienes previsto desplegar.
• Verifica que el informe de auditoría indica ese mismo commit. Un informe de una punta de rama anterior no cubre las correcciones posteriores ni los archivos generados.
• Haz el build y ejecuta los tests del proyecto a partir de esa versión, con una configuración controlada y datos sintéticos. Conserva los resultados reales de los comandos, incluidos los fallos y los tests omitidos.

2. Comprueba qué se ejecutó realmente

El Security Quick Scan incluye posture, detección de secretos con gitleaks y comprobación de dependencias con OSV. Las auditorías más amplias pueden incluir checks adicionales cuando tu cuenta y el alcance seleccionado lo permiten. La plantilla de lanzamiento de vetkit selecciona checks para áreas como el análisis estático de seguridad, la infraestructura, los workflows y la operabilidad, pero no incluye todos los analizadores disponibles. Por ejemplo, secrets-history y llm-app quedan fuera de la selección de esa plantilla.

Un informe parcial significa que uno o más analizadores no terminaron y que las categorías afectadas pueden estar infrarrepresentadas. Resuelve las lagunas de cobertura relevantes o documenta la verificación alternativa antes de fiarte del resultado.

3. Pon a prueba los límites de acceso

En un entorno de pruebas, crea dos cuentas normales y una cuenta con privilegios elevados. Intenta leer y modificar los registros de una cuenta desde la otra, y llama a los endpoints protegidos sin haber iniciado sesión. Comprueba que el servidor rechaza las operaciones no autorizadas aunque la interfaz del navegador oculte el botón. Incluye las descargas de archivos, las exportaciones y las operaciones en segundo plano que usan los mismos datos.

En una aplicación que use Supabase como backend, revisa con registros sintéticos las políticas de seguridad a nivel de fila y de almacenamiento desplegadas. Las reglas vibe-stack de vetkit pueden señalar patrones compatibles en el código fuente, como políticas de seguridad a nivel de fila ausentes o demasiado permisivas y buckets de almacenamiento públicos. La inspección del código fuente no establece la configuración actual de tu base de datos alojada ni demuestra el aislamiento entre tenants.

4. Revisa los secretos y los assets del navegador

Revisa los hallazgos de secretos, los prefijos públicos de las variables de entorno y los assets generados para el navegador. Mantén las credenciales de proveedores y de service role en el servidor. Una auditoría de repositorio no puede ver un secreto de despliegue que no esté en los archivos escaneados, y no inspecciona automáticamente el bundle desplegado en el navegador. Si se expuso una credencial, revócala o rótala; eliminar la línea del código fuente no basta. La guía sobre secretos filtrados explica las comprobaciones independientes del repositorio, del historial y del navegador.

5. Revisa las dependencias y las funciones de IA

Usa el lockfile previsto para el lanzamiento y revisa los hallazgos de dependencias. Una consulta de vulnerabilidades conocidas no puede establecer que un paquete desconocido sea de fiar. Revisa los nombres de los paquetes recién introducidos y su procedencia; consulta la guía sobre paquetes alucinados.

Si tu aplicación llama a un LLM, prueba qué ocurre con entradas demasiado grandes, errores del proveedor y salidas que solicitan una operación privilegiada. Establece límites de uso en el servidor y exige autorización en las herramientas que modifican datos. Las reglas llm-app de vetkit identifican patrones compatibles, como la salida del modelo ejecutada como comandos o SQL y las llamadas iniciadas por el usuario sin límite de tokens de salida. No demuestran que vaya a fallar cualquier intento de prompt injection ni miden tus controles de gasto en producción.

6. Prueba los caminos de fallo y la recuperación

• Simula un timeout de una dependencia y una escritura fallida. Verifica que el usuario recibe un estado de error útil y que reintentar no duplica la operación en silencio.
• Revisa el comando de arranque de producción, los health checks y el reporte de errores. Usa fallos sintéticos para confirmar que la persona responsable de la operación puede darse cuenta de un lanzamiento roto sin que se registren credenciales en los logs.
• Ensaya el procedimiento de rollback o de recuperación en un entorno de pruebas. Si el lanzamiento modifica datos almacenados, verifica el camino de recuperación por separado; revertir el código de la aplicación puede no restaurar esos datos.

vetkit incluye reglas estáticas para patrones como llamadas salientes sin timeouts, servidores de desarrollo en los comandos de arranque de producción y sincronizaciones de esquema potencialmente destructivas. Estos hallazgos pueden orientar tu revisión, pero la auditoría no ejecuta este ensayo de fallos ni restaura una copia de seguridad por ti.

7. Deja constancia de la decisión de lanzamiento

Guarda juntos el commit, el identificador del build, el alcance de la auditoría, los resultados de los tests y las comprobaciones del despliegue. Resuelve las credenciales expuestas y los accesos no autorizados demostrados antes de publicar. Para los hallazgos restantes, anota la evidencia, el impacto, el responsable de la decisión y la fecha de seguimiento. Si un analizador relevante falló o un comportamiento crítico nunca se probó, haz explícita esa laguna en lugar de tratar el silencio como una aprobación.

Fuentes y límites

Revisado el 1 de noviembre de 2026 con la configuración del Quick Scan de vetkit, las plantillas de auditoría, el formateador de informes y las reglas vibe-stack, llm-app, resilience, data-access y operability. El catálogo público de checks describe las reglas propias y los lenguajes que admiten; la documentación describe la configuración de las auditorías. La disponibilidad de los analizadores, los patrones admitidos, los límites del escaneo y el alcance seleccionado afectan a la cobertura.

Las comprobaciones manuales descritas aquí son trabajo de tu equipo, no afirmaciones de que vetkit realice pruebas de penetración en vivo, ejecute la suite de tests de tu aplicación o certifique un lanzamiento. Una auditoría del código fuente no puede verificar todos los permisos de producción, los ajustes de despliegue ni los requisitos de negocio. Mantén esas comprobaciones en tu proceso de lanzamiento aunque el informe no tenga hallazgos.