Chequeo de ambiente: El checklist de seguridad del 'vibe coder'

Si vale la pena construirlo, vale la pena protegerlo.

Vibe coding ha generado mucho revuelo. Aunque la automatización y la codificación con IA no son nuevas, Vibe coding promete democratizar el desarrollo de software: simplemente describe lo que quieres en lenguaje natural y deja que el LLM haga el resto. 

Desde IDEs mejorados con IA como Cursor, Copilot in VS Code y Windsurf, hasta plataformas que abstraen completamente la codificación (como Bolt, Lovable y v0), ya ha habido una explosión de herramientas en este ámbito, y esperamos que el crecimiento exponencial continúe.

Consulta AINativeDev para una visión general del panorama del desarrollo de IA  

Solo queremos buenas vibraciones

Es liberador poder construir rápidamente y “olvidar que el código siquiera existe” —especialmente si no eres un desarrollador profesional—, pero el mayor riesgo con el "vibe coding" es que no sabes lo que no sabes, y muchas veces puede que no entiendas lo que hace el código generado por IA. 

Claro, puedes validar que hace lo que esperas, pero sin saber lo que ocurre "bajo el capó", no siempre sabrás qué riesgos está creando el código hasta que sea demasiado tarde (y depurar es notoriamente más difícil que escribir el código en primer lugar). Si vas a esforzarte en construir algo —incluso si aceleras ese proceso mediante el "vibe coding"— lo último que quieres es que los incidentes de seguridad te retrasen.

Incluso los desarrolladores experimentados tienen puntos ciegos en lo que respecta a la seguridad, y aunque el 'vibe coding' hace que el desarrollo de software sea más accesible, también hace que sea más rápido y fácil dejar tu aplicación expuesta a vulnerabilidades y ataques, como inyecciones SQL, ataques de path traversal y secretos vulnerables a actores maliciosos. Aunque algunas plataformas de 'vibe coding' se esfuerzan por adelantarse a las vulnerabilidades (v0 es por defecto escéptica con el código LLM), todavía existe un riesgo muy real de brechas de seguridad al hacer 'vibe coding'—lo que lleva a la observación sarcástica de que 'vibe coding' = Vulnerability-as-a-Service. 

Tomemos el siguiente ejemplo:

‍

Desafortunadamente, no hay una razón obvia por la que nuestro desafortunado amigo de arriba terminara teniendo que cerrar su aplicación y empezar de nuevo. Está claro que sus claves API se filtraron, lo que permitió a los hackers suplantar su identidad, lo que significa que pudieron acceder o alterar datos, funcionalidades o recursos.

Aquí podrían haber estado en juego una serie de trampas en la gestión insegura de claves API: la codificación de secretos directamente en su aplicación, un archivo de variables de entorno subido sin querer a su servidor, o ser víctima de una vulnerabilidad de path traversal (oye, incluso le pasó a Atlassian). Sin comprobaciones y procesos de seguridad adicionales, habría sido fácil para un hacker o un bot obtener acceso a sus claves API. 

Vulnerabilidades y riesgos de seguridad comunes

Ya seas solo tú y ChatGPT, o estés programando con una herramienta dedicada como Lovable, eres vulnerable a estos tipos comunes de ciberataques. 

cross-site scripting

cross-site scripting aprovecha las vulnerabilidades de las aplicaciones web en las que los datos introducidos por el usuario no se validan ni se limpian adecuadamente antes de mostrarse o procesarse. Los hackers pueden «inyectar» código malicioso a través de la información introducida por el usuario y, cuando se ejecuta el script inyectado, pueden acceder a información confidencial o realizar acciones no autorizadas en nombre de la víctima (en este caso, uno de sus usuarios). Los ataques XSS pueden ser inofensivos y divertidos (como en este tuit que se retuitea a sí mismo), pero ponen a sus usuarios en riesgo de que sus datos queden expuestos o incluso de que los hackers tomen el control de sus cuentas. 

Ataques de inyección SQL

Al igual que XSS, un ataque de inyección SQL (SQLi) inyecta código malicioso en una aplicación, a menudo a través de un campo de entrada de usuario vulnerable. Dado que SQL es el lenguaje que muchas aplicaciones utilizan para consultar su base de datos subyacente, este tipo de ataque permite a los hackers ver o modificar su base de datos, accediendo a datos confidenciales o incluso eliminando registros. La filtración de datos de Equifax de 2017 fue el resultado de un ataque de inyección SQL; Equifax en sí no fue el objetivo, la empresa no había aplicado un parche de seguridad a una de sus dependencias.  

Ataques de Path Traversal

Los atacantes pueden manipular las entradas de rutas de archivos (normalmente URLs o parámetros de archivo) para engañar a su aplicación y que devuelva archivos o directorios no públicos, eludiendo los controles de acceso y permitiéndoles leer y escribir en archivos que contienen datos confidenciales. Este tipo de ataque también es posible debido a entradas de usuario inseguras. En 2010, los investigadores descubrieron una vulnerabilidad de path traversal en la aplicación Confluence de Atlassian que habría permitido a los atacantes recuperar cualquier archivo en el servidor donde se ejecutaba Confluence, basándose en los permisos del usuario bajo el cual se ejecutaba Confluence.

Fuga de secretos

Los secretos, como contraseñas, claves de cifrado, tokens API y certificados digitales, proporcionan a los delincuentes las llaves de su reino. Estos datos confidenciales pueden permitir a los hackers suplantar su identidad, acceder a sus datos y modificar su código. Según elinforme GitGuardian State of Secrets Sprawl, en 2024 se encontraron la asombrosa cifra de 23 millones de secretos en repositorios de código fuente públicos (un 25 % más que el año anterior). Los secretos pueden quedar expuestos al codificarlos accidentalmente en su aplicación o a través de una vulnerabilidad como la de tj-actions/changed-files de marzo de 2025: los atacantes modificaron el código de GitHub Action tj-actions/changed-files, lo que provocó que la acción comprometida imprimiera secretos de CI/CD en los registros de compilación de GitHub Actions.

ataques a la cadena de suministro

Entre el 85 % y el 95 % del código de su aplicación podría estar basado en bibliotecas y proyectos de código abierto. ataques a la cadena de suministro explotan un tipo específico de vulnerabilidad ni se dirigen a una aplicación concreta, sino que se centran en los proyectos de código abierto subyacentes de los que dependen muchas empresas. La filtración de datos de Equifax mencionada anteriormente fue el resultado de un ataque a la cadena de suministro que ya se había mitigado, lo que demuestra la importancia de supervisar las dependencias y aplicar los parches de seguridad con prontitud. 

Vibe coding es una herramienta excelente para la exploración y la creación de pruebas de concepto, pero en el momento en que te interese convertir algo en un producto y negocio viable, querrás establecer controles de seguridad y mejores prácticas para proteger lo que has creado. 

¿No basta con pedirle a la IA que escriba código más seguro?

Mira, esta es una pregunta válida. Sabemos que la IA no escribe código seguro por defecto, pero una mejora muy rápida y sencilla es pedirle explícitamente que lo haga seguro (como añadir literalmente las palabras "y hazlo seguro" a tu prompt). Sorprendentemente, esto realmente resulta en código con menos vulnerabilidades.

También puede hacer que la IA revise su propio código en busca de vulnerabilidades y brechas de seguridad, como pedirle que encuentre secretos codificados, verifique que los datos no sean de acceso público, escanee el proyecto en busca de dependencias vulnerables o identifique campos de entrada de usuario (como formularios) con validación de entrada insuficiente. Todos estos esfuerzos mejorarán la seguridad de su aplicación.

Pero el objetivo de verificar el código generado por IA en busca de posibles alucinaciones, vulnerabilidades u otras brechas de seguridad es que resulta demasiado arriesgado dejar que se corrija por sí mismo sin supervisión humana. Es posible integrar la IA con los métodos de análisis tradicionales para mejorar las cosas, pero no para sustituirlos (por ejemplo, Aikido utiliza la IA para triaje automático las alertas triaje automático y proponer soluciones).

Los ingenieros de software más competentes suelen ser también los que se sienten más cómodos admitiendo cuando no saben algo. El problema de depender demasiado de la IA para que se autorregule es que no es raro que haga una afirmación segura sobre algo incorrecto, en lugar de admitir incertidumbre. Por eso no recomendamos depender únicamente de la IA para asegurar tu aplicación.

La buena noticia es que muchas empresas y proyectos de código abierto se han dedicado a abordar estos problemas de seguridad mucho antes de que el 'vibe coding' se popularizara. Una de las mayores lecciones que aprenden los nuevos desarrolladores es la de 'subirse a hombros de gigantes'. Habrá muchos componentes en tu aplicación que son sensibles y de misión crítica (cosas como la autenticación, la criptografía, o incluso cómo permites a los usuarios subir archivos a tu interfaz de usuario), y pedir a Cursor o GPT que los construyan por ti es: 

1. No contribuirá a la diferenciación de tu producto
2. Muy probable que introduzca riesgos de seguridad

En esos casos, es mucho mejor apoyarse en proveedores que se centran puramente en soluciones a esos problemas. Los LLM no están específicamente entrenados en mejores prácticas o en resolver un problema de la manera más eficiente o segura. En muchos casos, la solución más elegante es utilizar un servicio preexistente en lugar de construir el tuyo propio (incluso si estás delegando el trabajo pesado a la IA).

Es fácil sentirse abrumado y no saber por dónde empezar. Hemos elaborado esta lista de verificación para ayudarte a empezar a construir de forma más segura. 

Nivel 0

Estas son las medidas de seguridad básicas e imprescindibles que querrás implementar lo antes posible. Una vez que estas prácticas estén establecidas y formen parte de tu proceso, podrás construir libremente sin romper el ritmo.

Implementa las mejores prácticas de Git.

Uno de los errores comunes del 'vibe coding' es que, al añadir nueva funcionalidad o intentar solucionar un problema, resulta más intuitivo simplemente reemplazar lo que se tenía antes con el nuevo código generado por IA. Esto funciona hasta que deja de hacerlo; con el tiempo, es posible que se encuentre con un muro donde nada de lo que produce la IA ayuda y esté incluso peor que antes.

Para esto sirve el control de versiones

El control de versiones como Git surgió como una forma para que los desarrolladores colaboraran en proyectos sin sobrescribir el trabajo de los demás. Pero incluso si trabajas solo, sirve como una forma de respaldar tu progreso, lo que ayuda a aislar errores y a poder revertir un cambio cuando algo sale mal. Aquí tienes tres prácticas clave de Git que te ayudarán a construir de forma más segura:

Crear un archivo .gitignore para archivos sensibles

Un archivo .gitignore es simplemente un archivo de texto plano que le indica a Git qué debe ignorar (es decir, no subir a tu repositorio). Normalmente, querrás que Git ignore los archivos generados por ordenador, como los logs, ya que estos saturan tu repositorio y podrían contener información sobre la aplicación que podría utilizarse para comprometerla. Tu archivo .env también debería ignorarse, ya que contiene variables de entorno sensibles (como claves API y contraseñas) que los hackers podrían usar para suplantarte y obtener acceso a tu sistema. 

Mantener un historial de commits claro

Mantener los cambios lo más autocontenidos posible facilita la identificación de cuándo se introdujo un error o una vulnerabilidad, y simplifica la reversión sin tener que rehacer otro trabajo. Ir un paso más allá y configurar commits firmados verifica que los desarrolladores correctos están enviando código a tu repositorio (¡incluso si solo eres tú!). 

Separar las ramas de desarrollo de características, staging y producción

El branching en Git ayuda a crear espacios de trabajo distintos y autocontenidos para desarrollar, previsualizar y lanzar código. Desarrollar activamente nuevas funcionalidades en una rama separada ayuda a evitar que código inacabado, con errores o inseguro se envíe accidentalmente a tu aplicación en producción. Una vez que una nueva funcionalidad o característica está completamente desarrollada y probada, una rama de staging actúa como otra puerta de seguridad y calidad, permitiéndote revisar y finalizar los cambios antes de lanzarlos a producción. Solo las funcionalidades completamente probadas y estables pueden entonces fusionarse en tu rama de producción (normalmente llamada main).

Repositorios Git alojados: GitHub GitLab   

Mantener los secretos separados del código

‍

‍

Los secretos —como tus contraseñas, claves de cifrado, tokens de API y certificados digitales— deben gestionarse por separado del código para evitar subirlos directamente a tu base de código. Puedes revisar tu código en busca de secretos con Aikido, incluso desde tu Cursor IDE.

Protege tu aplicación de ataques DDoS

Un ataque distribuido de denegación de servicio (DDoS) intenta interrumpir el tráfico normal de un servidor, servicio o red específicos saturando el objetivo o su infraestructura circundante con un pico de tráfico de Internet. Estos ataques pueden tener consecuencias devastadoras, y es sorprendentemente sencillo protegerse integrando protecciones DDoS básicas con una red de distribución de contenidos (CDN) como CloudFlare o CloudFront. Algunos proveedores de alojamiento de dominios incluso ofrecen una CDN como servicio integrado. 

No implementes la autenticación por tu cuenta

La autenticación (como su flujo de inicio de sesión) es un componente sensible de su aplicación que querrá dejar en manos de expertos. Utilizar una herramienta dedicada para aplicar una política de contraseñas y ofrecer fácilmente inicio de sesión único o incluso autenticación multifactor para su aplicación a medida que escala, protegerá sus cuentas de usuario y su reputación. 

Excelentes herramientas: Auth0, Quasr 

Nunca implemente su propia criptografía

Del mismo modo, la criptografía es una especialidad, por lo que siempre debe confiar en mecanismos, bibliotecas y herramientas establecidos. Construir sus propias implementaciones, o usar flags y opciones que no comprende completamente,

te expondrá a riesgos importantes. Librerías como NaCL exponen pocas opciones, lo que te restringe a buenas elecciones.

Nivel 1

Configura un pipeline de CI/CD para monitorizar tu código

Implementar un proceso de CI/CD con pruebas es como añadir puntos de control de calidad a la cadena de montaje del código de su aplicación. Puede integrar análisis estático de código para realizar Pruebas de seguridad de aplicaciones estáticas SAST), que analizan su código en busca de fallos que puedan dar lugar a vulnerabilidades de seguridad. También puede integrar una herramienta para Pruebas de seguridad de aplicaciones dinámicas (DAST, a veces denominadas supervisión de superficie) para simular ataques e identificar vulnerabilidades en la interfaz de su aplicación web (como buscar puertos abiertos o tráfico entrante sin restricciones). 

DAST de código abierto: ZAP

SAST de código abierto: Opengrep

Monitoriza tus dependencias  

Lo sepas o no, la mayor parte del código que impulsa tu aplicación probablemente proviene de proyectos de código abierto y bibliotecas de terceros en los que se entrenan los modelos de IA. Estas son tus dependencias, y a veces incluso estas tienen sus propias dependencias, todo lo cual conforma tu cadena de suministro de software. Un solo fallo en cualquiera de estas bibliotecas podría poner en riesgo toda tu aplicación, pero puedes reducir el riesgo utilizando las herramientas adecuadas para monitorear tus dependencias en busca de vulnerabilidades conocidas.

Herramienta recomendada: Trivy

Configúralo en segundos con Aikido

Verifica tus dependencias en busca de malware

Asimismo, tu cadena de suministro puede incluir paquetes maliciosos que contengan malware. Estos son excepcionalmente peligrosos, ya que los atacantes suelen actuar rápidamente después de lograr introducir malware en tu código. Por lo tanto, también necesitas reaccionar rápidamente. Ten en cuenta que las bases de datos de Common Vulnerabilities and Exposures (CVE) son demasiado lentas y no te protegerán de este tipo de ataques.

Herramientas: Aikido Intel

Configúralo en segundos con Aikido

Utiliza lockfiles para proteger tu cadena de suministro.

Si no utilizas lockfiles, cada vez que compiles tu aplicación, obtendrás las últimas versiones de todos los paquetes de código abierto. Los lockfiles permiten compilaciones reproducibles al obtener las mismas versiones de tus dependencias de código abierto. Esto mantiene tu aplicación estable en caso de cambios disruptivos en tus dependencias, pero también protege tu aplicación contra ataques a la cadena de suministro cuando la última versión de una dependencia ha sido comprometida. Un ejemplo reciente de esto es la vulnerabilidad tj-actions/changed-files de marzo de 2025: los atacantes modificaron el código de la GitHub Action tj-actions/changed-files, haciendo que la acción comprometida imprimiera secretos de CI/CD en los registros de compilación de GitHub Actions.  

Prevenir ataques de scripting entre sitios con cabeceras CSP estrictas

Las cabeceras CSP pueden protegerte de ataques XSS comunes al proporcionar una capa de seguridad adicional que controla qué recursos dinámicos se permiten cargar. Esto evita que los atacantes inyecten scripts en tus páginas web.

Verifica si los has configurado correctamente con Aikido

Utilice un firewall de aplicaciones web firewall de aplicaciones.

Utilice un firewall de aplicaciones web firewall de aplicaciones WAF) o autoprotección de aplicaciones en tiempo de ejecución proteger los servidores web frente a amenazas desconocidas de día cero, incluidas las amenazas desconocidas de inyección SQL o XSS. La herramienta analiza y previene las solicitudes de los usuarios con comportamientos sospechosos o maliciosos (como una carga útil de inyección), actuando como última línea de defensa contra los ataques. 

Grandes herramientas: AWS WAF Aikido Zen

Nivel 2

Con las medidas de seguridad anteriores implementadas, es el momento de elevar tu postura de seguridad.

Implementa las mejores prácticas para contenedores.

Los contenedores empaquetan el software para que pueda ejecutarse de forma fiable al trasladarse de un entorno informático a otro. Agrupan una aplicación con todas sus dependencias necesarias, como librerías, frameworks y archivos de configuración (todo en su cadena de suministro), en un único paquete. Esto garantiza que la aplicación se ejecute de forma consistente, independientemente del entorno en el que se despliegue. 

Si utiliza contenedores para el despliegue, existen algunas mejores prácticas que le ayudarán a fortalecer su aplicación.

Mantén actualizadas tus imágenes base de Docker 

Las vulnerabilidades en la imagen base de su contenedor (el esquema de lo que compone su contenedor) ponen en riesgo su aplicación. Descargue regularmente todas las actualizaciones de seguridad para su imagen base. Para los servidores, puede delegar esto a un proveedor de PaaS como Heroku o AWS Beanstalk.

Analiza la seguridad de tu Docker con: Syft Grype Trivy

Configúralo en segundos con Aikido

Ejecuta contenedores Docker con privilegios restringidos

Los privilegios limitados dificultan que los atacantes exitosos tomen el control del host o salten a otros servicios. Evite ejecutar contenedores con roles de usuario privilegiados, como root en sistemas Unix, o Administrator o System en sistemas Windows.

Protege tus secretos

Separar los secretos del código es un buen comienzo. Si utilizas contenedores, también querrás asegurarte de que tus archivos de secretos y otros datos sensibles estén adecuadamente protegidos. Esto incluye el uso de herramientas de gestión de secretos (muchos proveedores de la nube ofrecen las suyas propias), secretos de Kubernetes si utilizas Kubernetes, la rotación regular de secretos y el establecimiento de fechas de caducidad para tus secretos. 

Herramientas de gestión de secretos: HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

Más información: Gestión segura de secretos en contenedores: mejores prácticas y estrategias

Verifica tus paquetes para su Fin de Vida Útil (EOL)

A medida que los paquetes envejecen y dejan de ser compatibles, el riesgo de exploits aumenta. Debe asegurarse de actualizar los paquetes que pronto alcanzarán su fin de vida útil.

O configúralo en segundos con la función de escaneo de contenedores de Aikido

Implementa las mejores prácticas para tus cuentas en la nube.

Mantener separadas las cuentas en la nube de desarrollo, staging y producción 

Así como se recomienda mantener separadas las ramas Git de desarrollo, staging y producción, lo mismo se aplica a las cuentas en la nube. Aunque se podrían crear redes virtuales dentro de las cuentas en la nube para mantener separadas las fases de staging y producción, esto puede volverse complicado a medida que se crece, ya que se acabaría gestionando continuamente los derechos de acceso de los usuarios para los nuevos desarrolladores. Recomendamos mantener la infraestructura de desarrollo, staging y producción en cuentas de la nube completamente separadas. Todos los proveedores de la nube ofrecen facturación unificada, lo que supone un dolor de cabeza menos.

Utiliza herramientas de gestión de la postura cloud

Los proveedores de servicios en la nube ofrecen tantas funciones que es fácil pasar por alto o configurar incorrectamente algo que te ponga en riesgo. Utiliza una herramienta seguridad en la nube gestión seguridad en la nube (CSPM) para analizar tu nube en busca de anomalías.

CSPM : Cloudsploit AWS Inspector

Configúralo en segundos con Aikido

Habilitar alertas de presupuesto en la nube

En caso de que tu cuenta en la nube sea hackeada, una forma infalible de detectar que alguien está minando Bitcoin en tu cuenta es tener alertas de presupuesto configuradas para monitorizar el gasto. Tu proveedor de la nube debería ofrecer alertas integradas para esto, o puedes configurar el escaneo en la nube con Aikido para verificar problemas de presupuesto y configuraciones erróneas de riesgo. 

Verifica tus LLM en busca de los exploits más comunes

Además de construir con LLMs, podría estar integrando LLMs en su producto de cara al público. Podría tener un chatbot que ofrezca soporte a los usuarios, o un asistente de IA que les ayude en su incorporación (onboarding). Si sus clientes interactúan con un LLM de cualquier forma, es una buena idea probarlos para detectar los exploits más comunes y así no exponer a los clientes a riesgos de seguridad. 

Consulte los exploits más comunes: Top 10 OWASP LLM.

Más allá

Implementa un ciclo de vida de desarrollo seguro.

Una parte importante de las prácticas de seguridad modernas es el 'shifting left', que consiste en integrar las medidas de seguridad en el ciclo de vida del desarrollo de forma más temprana. Esto te ayuda a adquirir el hábito de buenas prácticas en cada etapa del proyecto y a detectar problemas antes de que se conviertan en una amenaza real. Esto implica adherirse a una lista de verificación de seguridad como esta, familiarizarse con las fallas de seguridad típicas y buscarlas durante la revisión de código, e implementar verificaciones de seguridad también en las pull requests. 

Más información: OWASP Top Ten

Más información: Artículo de Wikipedia sobre el ciclo de vida del desarrollo de sistemas

Cualquiera puede ser víctima de un ciberataque —incluso las empresas multinacionales con departamentos de seguridad dedicados siguen siendo vulnerables a las brechas. Aunque el 'vibe code' no es seguro por defecto, al adoptar las mejores prácticas de seguridad desde el principio, aún puedes dejarte llevar por las 'vibes'. Todo lo que construyas merece el esfuerzo. 

Lectura adicional

• Lista de verificación de seguridad para CTO de SaaS de Aikido para 2025
• Guía de código abierto para la seguridad de las aplicaciones de las empresas emergentes

Descarga tu lista de verificación de seguridad de Vibe Coding gratis.