Vibe coding: ¿y si la IA está programando también tus vulnerabilidades?
Más velocidad y menos tiempo de desarrollo. ¿Estamos revisando también la seguridad del código que genera la IA?
Solutions ITS ·
Cada vez es más habitual desarrollar aplicaciones utilizando inteligencia artificial: describimos lo que queremos en lenguaje natural y la IA genera gran parte del código. Cuando el desarrollo se guía principalmente por esas instrucciones y por comprobar que el resultado funciona, suele hablarse de vibe coding.
Podemos construir un prototipo en menos tiempo, automatizar tareas y acercar el desarrollo a personas sin experiencia en programación. Pero hay una pregunta que no debemos dejar para el final: ¿qué ocurre con la seguridad?
Que una aplicación funcione no significa que sea segura. Un formulario puede guardar datos correctamente y permitir una inyección SQL. Un usuario puede iniciar sesión y, aun así, acceder a documentos de otra empresa cambiando un identificador.
Cuatro áreas que revisar antes de pasar a producción
1. Autenticación y sesiones
Hay que comprobar cómo se identifica a cada usuario, cómo se almacenan las contraseñas y cómo se recupera el acceso. La revisión debe incluir la caducidad e invalidación de sesiones, las cookies de sesión, la protección frente a intentos repetidos y la autenticación multifactor cuando corresponda.
Una pantalla de acceso no demuestra que estos controles estén bien implementados. También debemos probar qué ocurre después de cerrar sesión, cambiar una contraseña o retirar el acceso a un empleado.
2. Autorización y control de acceso
Estar identificado no da permiso para acceder a cualquier información. Cada operación debe comprobar en el servidor qué puede hacer ese usuario y sobre qué datos. Ocultar un botón en la pantalla no es un control de seguridad suficiente.
Una prueba sencilla consiste en utilizar dos cuentas con distintos permisos y verificar que ninguna puede consultar o modificar los registros de la otra. En aplicaciones con varias empresas, hay que comprobar especialmente la separación de sus datos.
3. APIs y exposición de información
Las APIs necesitan validación de entradas, controles de acceso y respuestas que solo incluyan los datos necesarios. Conviene revisar también los límites de uso, los mensajes de error, las subidas de archivos y la información que queda en los registros.
Las claves privadas y los tokens de servicios no deben terminar en el navegador ni incorporarse al repositorio. Si un secreto ya se ha expuesto, eliminarlo del código no basta: hay que revocarlo o rotarlo.
4. Código y dependencias
La revisión debe abarcar tanto el código generado como las bibliotecas que utiliza. Comprobar el origen de los paquetes, sus versiones, su mantenimiento y sus vulnerabilidades conocidas forma parte del trabajo. Las correcciones sugeridas por una IA también deben revisarse y probarse antes de incorporarlas.
Snyk: qué puede detectar y dónde ayuda
Snyk reúne distintas herramientas de seguridad para el desarrollo. Conviene distinguir sus análisis, porque revisar el código propio y revisar los componentes que instalamos son tareas diferentes.
Snyk Code: problemas en el código de la aplicación
Snyk Code realiza análisis estático (SAST): examina el código sin necesidad de ejecutar la aplicación. Entre los problemas que puede identificar están:
- Inyección SQL: datos introducidos por un usuario que llegan a una consulta de base de datos sin el tratamiento adecuado.
- Cross-site scripting (XSS): contenido no confiable que puede acabar ejecutándose como código en el navegador de otro usuario.
Los resultados ayudan a localizar el problema y entender el recorrido de los datos. La cobertura depende del lenguaje, del framework y de las reglas disponibles; una propuesta de corrección sigue necesitando revisión y pruebas. Snyk muestra ejemplos de estas detecciones en PHP.
Snyk Open Source: dependencias con vulnerabilidades conocidas
Snyk Open Source analiza las bibliotecas de terceros y sus dependencias, incluidas las que llegan de forma indirecta. Contrasta las versiones utilizadas con información de vulnerabilidades conocidas y ayuda a identificar actualizaciones que las corrigen cuando están disponibles.
Según el componente, esos fallos pueden permitir ejecutar código, exponer información o provocar una denegación de servicio. Encontrar una dependencia vulnerable exige valorar si el problema afecta al uso que hace nuestra aplicación; no todos los avisos tienen la misma prioridad.
La plataforma también incluye Snyk Container, para analizar vulnerabilidades en imágenes de contenedores, y Snyk IaC, para detectar configuraciones inseguras en infraestructura definida como código. Son análisis complementarios: pasar uno no equivale a haber comprobado toda la aplicación. Ver productos incluidos en los planes.
¿Puede empezar una pyme con el plan gratuito?
Sí. Snyk dispone de un plan Free para desarrolladores individuales y equipos pequeños, con acceso a análisis de código, dependencias, contenedores e infraestructura como código, además de integraciones con el editor, la línea de comandos y gestores de código fuente.
No es un servicio ilimitado. En la página de planes consultada el , Snyk indica límites de 200 pruebas para Open Source, 100 para Code, 300 para IaC y 100 para Container en el plan gratuito. Las cuotas y condiciones pueden cambiar; hay que comprobar también cómo se contabilizan las pruebas antes de automatizarlas. Consultar el plan Free y sus límites vigentes.
Para una pyme con un proyecto pequeño, puede ser un punto de partida para incorporar análisis de seguridad sin contratar inicialmente una licencia de pago. Lo importante es asignar a alguien la revisión de los resultados y la corrección de los problemas: activar una herramienta y acumular alertas no mejora por sí solo la seguridad.
Otras herramientas que pueden complementar la revisión
- SonarQube: análisis de calidad del código y problemas de seguridad. Las capacidades disponibles dependen del producto y la edición.
- Semgrep: análisis estático para detectar patrones inseguros y aplicar reglas de revisión del código.
- Gitleaks: búsqueda de posibles contraseñas, claves y tokens expuestos en archivos y en el historial de Git.
- ZAP (Zed Attack Proxy): herramienta gratuita y de código abierto para realizar pruebas sobre aplicaciones web en ejecución. Las pruebas activas deben planificarse en un entorno autorizado, preferiblemente de pruebas.
Una forma práctica de empezar
- Elegir una aplicación y definir su alcance: qué datos maneja, quién accede y qué operaciones son más sensibles.
- Analizar código, dependencias y secretos: comprobar que el lenguaje está soportado y revisar los permisos y el tratamiento del código antes de conectar un servicio externo.
- Priorizar y corregir: atender primero los problemas explotables que afectan a datos sensibles o a funciones expuestas. Documentar las excepciones y sus motivos.
- Probar los controles: usar cuentas con distintos roles, comprobar la separación de datos y verificar el comportamiento de las APIs y las sesiones.
- Repetir tras cada cambio relevante: incorporar análisis al proceso de desarrollo y comprobar que las correcciones no rompen el funcionamiento ni introducen nuevos fallos.
Las herramientas ayudan; la validación sigue siendo necesaria
Un informe sin alertas no garantiza que una aplicación sea segura. Los fallos de lógica de negocio, la asignación incorrecta de permisos o una separación deficiente entre clientes pueden requerir pruebas específicas y conocimiento del funcionamiento de la aplicación.
El OWASP Top 10 ayuda a conocer los principales riesgos. Para concretar requisitos y comprobar controles, OWASP ASVS ofrece una referencia más detallada que se puede adaptar al riesgo y al alcance del proyecto.
La IA puede generar código en segundos. Eso no significa que haya verificado su seguridad. La revisión humana, las pruebas y la validación de los controles siguen siendo imprescindibles.
El vibe coding acelera el desarrollo. La seguridad debe acompañarlo desde el primer momento, no añadirse al final.