Si vale la pena construirlo, vale la pena asegurarlo.

La codificación vibrante ha generado mucha expectación. Aunque automatizar y codificar con IA no es algo nuevo, la codificación vibrante promete democratizar el desarrollo de software: basta con describir lo que quieres en lenguaje natural y dejar que el LLM haga el resto. 

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

Consulte AINativeDev para conocer el panorama del desarrollo de la IA  

Sólo queremos buenas vibraciones

Es liberador poder construir rápidamente y "olvidarse de que el código existe" -especialmente si no eres un desarrollador profesional-, pero el mayor riesgo de la codificación vibrante es que no sabes lo que no sabes, y muchas veces puede que no entiendas lo que hace el código generado por la IA. 

Claro, puedes validar que hace lo que esperas que haga, pero sin saber lo que está pasando bajo el capó, no siempre sabrás qué riesgos está creando el código hasta que sea demasiado tarde (y la depuración es notoriamente más difícil que escribir el código en primer lugar). Si vas a hacer el esfuerzo de construir algo -incluso si estás acelerando ese proceso a través de la codificación vibrante- lo último que quieres es retroceder por incidentes de seguridad.

Incluso los desarrolladores experimentados tienen puntos ciegos cuando se trata de seguridad, y mientras que la codificación vibe hace que el desarrollo de software sea más accesible, también hace que sea más rápido y más fácil dejar tu aplicación expuesta a vulnerabilidades y ataques, como inyecciones SQL, ataques de path traversal y secretos vulnerables a malos actores. Aunque algunas plataformas de vibe coding están haciendo un esfuerzo por adelantarse a las vulnerabilidades(v0 es por defecto escéptica con el código LLM), sigue existiendo un riesgo muy real de brechas de seguridad cuando se utiliza vibe coding, lo que lleva a la sarcástica observación de que vibe coding = Vulnerabilidad-como-Servicio. 

Basta con ver el siguiente ejemplo:

‍

Por desgracia, no hay una razón obvia por la que nuestro desafortunado amigo haya tenido que cerrar su aplicación y empezar de nuevo. Está claro que sus claves API se filtraron, lo que permitió a los hackers hacerse pasar por él, lo que significa que podían acceder o alterar datos, funcionalidades o recursos.

En este caso podrían haber intervenido varios trucos inseguros en la gestión de claves de API: la codificación de secretos en su aplicación, un archivo de variables de entorno subido involuntariamente a su servidor o ser víctima de una vulnerabilidad de paso de ruta ( incluso le ocurrió a Atlassian). Sin controles y procesos de seguridad adicionales, habría sido fácil para un hacker o un bot acceder a sus claves API. 

Vulnerabilidades y riesgos de seguridad comunes

Tanto si eres sólo tú y ChatGPT, como si estás codificando con una herramienta dedicada como Lovable, eres vulnerable a estos tipos comunes de ciberataques. 

Secuencias de comandos en sitios cruzados (XSS)

Un ataque de secuencias de comandos en sitios cruzados (XSS) aprovecha las vulnerabilidades de las aplicaciones web en las que las entradas proporcionadas por el usuario no se validan o desinfectan correctamente antes de mostrarse o procesarse. Los hackers pueden entonces "inyectar" código malicioso a través de la entrada del usuario, y cuando el script inyectado se ejecuta, puede acceder a información sensible o realizar acciones no autorizadas en nombre de la víctima (en este caso, uno de sus usuarios). Los ataques XSS pueden ser una diversión inofensiva (como en este tuit que se retuitea a sí mismo), pero ponen a tus usuarios en riesgo de que sus datos queden expuestos o incluso sus cuentas sean controladas por piratas informáticos. 

Ataques de inyección SQL

Al igual que el 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 compañía no había aplicado un parche de seguridad a una de sus dependencias.  

Ataques path traversal

Los atacantes pueden manipular las entradas de rutas de archivos (normalmente URL o parámetros de archivos) para engañar a su aplicación para 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 mediante 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 que está ejecutando Confluence, basándose en los permisos del usuario bajo el cual se estaba ejecutando Confluence.

Fuga de secretos

Los secretos, como contraseñas, claves de cifrado, tokens de API y certificados digitales, dan a los malos actores las llaves de su reino. Estos datos sensibles pueden permitir a los hackers hacerse pasar por ti, acceder a tus datos y modificar tu código. Según el informe GitGuardian State of Secrets Sprawl, en 2024 se encontraron 23 millones de secretos en repositorios públicos de código fuente (un 25% más que el año anterior). Los secretos pueden quedar expuestos al codificarlos accidentalmente en tu 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 la acción de GitHub tj-actions/changed-files, haciendo que la acción comprometida imprimiera secretos de CI/CD en los registros de construcción de las acciones de GitHub.

Ataques a la cadena de suministro

Hasta el 85-95% del código de su aplicación podría estar basado en bibliotecas y proyectos de código abierto. Los ataques a la cadena de suministro no explotan un tipo específico de vulnerabilidad ni se dirigen a una aplicación concreta, sino que van tras 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 había sido mitigado, lo que demuestra la importancia de supervisar sus dependencias y aplicar los parches de seguridad con prontitud. 

Vibe coding es una herramienta increíble para explorar y construir una prueba de concepto, pero en el momento en que te interese convertir algo en un producto y un negocio viables, querrás establecer controles de seguridad y buenas prácticas para proteger lo que has construido. 

¿No puedo pedirle a la IA que escriba un 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 sucia es pedirle explícitamente que lo haga seguro (es decir, añadir literalmente las palabras "y hazlo seguro" a tu pregunta). Sorprendentemente, esto da como resultado un código con menos vulnerabilidades.

También puedes hacer que la IA revise su propio código en busca de vulnerabilidades y lagunas de seguridad, por ejemplo, pidiéndole que encuentre secretos codificados, que verifique que los datos no son de acceso público, que analice el proyecto en busca de dependencias vulnerables o que identifique campos de entrada de usuario (como formularios) con una validación de entrada insuficiente. Todos estos esfuerzos mejorarán la seguridad de tu aplicación.

Pero la cuestión de comprobar el código generado por la IA en busca de posibles alucinaciones, vulnerabilidades u otras brechas de seguridad es que es demasiado arriesgado que se corrija solo sin supervisión humana. Es absolutamente posible integrar la IA con los métodos de análisis tradicionales para mejorar las cosas, pero no para sustituirlas (por ejemplo, Aikido utiliza la IA para autoevaluar las alertas de seguridad y proponer correcciones).

Los mejores ingenieros de software suelen ser también los que se sienten más cómodos admitiendo que no saben algo. El problema de confiar demasiado en la IA para que se controle a sí misma es que no es raro que haga una afirmación segura sobre algo que está mal, en lugar de admitir la incertidumbre. Por eso no recomendamos confiar únicamente en la IA para proteger 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 convirtiera en algo de moda. Una de las mayores lecciones que aprenden los nuevos desarrolladores es a subirse a hombros de gigantes. Habrá muchos componentes de su aplicación que son sensibles y de misión crítica (cosas como la autenticación, la criptografía, o incluso sólo la forma en que permite a los usuarios subir archivos a su interfaz de usuario), y pedir Cursor o GPT para construir esos para usted es: 

1. No va a contribuir a la diferenciación de su producto
2. Alta probabilidad de introducir riesgos de seguridad

En esos casos, es mucho mejor recurrir a proveedores que se centren exclusivamente en solucionar esos problemas. Los LLM no están específicamente formados en mejores prácticas o en resolver un problema de la forma más eficiente o segura. En muchos casos, la solución más elegante es utilizar un servicio preexistente en lugar de crear uno propio (incluso si se descarga el trabajo pesado a la IA).

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

‍

Nivel 0

Estas son las medidas de seguridad que querrás poner en práctica lo antes posible. Una vez que estas prácticas se hayan establecido y formen parte de tu proceso, podrás construir libremente sin acabar con el ambiente.

Aplicar las mejores prácticas de Git

Uno de los escollos habituales de la codificación vibrante es que, al añadir una nueva funcionalidad o intentar solucionar un problema, resulta más intuitivo sustituir simplemente lo que tenías antes por el nuevo código generado por la IA. Esto funciona hasta que deja de funcionar; al final, puede que te topes con un muro en el que nada de lo que produce la IA sirva de ayuda y te encuentres incluso peor que antes.

Para esto sirve el control de versiones

El control de versiones como Git surgió como una forma de que los desarrolladores colaboraran en proyectos sin sobrescribir el trabajo de los demás. Pero incluso si estás construyendo en solitario, sirve como una forma de respaldar tu progreso, lo que ayuda a aislar errores y ser capaz de revertir un cambio cuando algo va 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 los archivos sensibles

Un archivo .gitignore es simplemente un archivo de texto plano que le dice a Git lo que debe ignorar (es decir, no confirmar en tu repositorio). Típicamente, quieres que Git ignore archivos generados por ordenador como los logs, ya que estos desordenan tu repositorio y podrían contener información sobre la aplicación que podría ser usada para comprometerla. Tu archivo .env también debería ser ignorado, ya que contiene variables de entorno sensibles (como claves API y contraseñas) que los hackers podrían utilizar para hacerse pasar por ti y obtener acceso a tu sistema. 

Mantener un historial claro de confirmaciones

Mantener los cambios lo más autocontenidos posible hace que sea más fácil identificar cuándo se ha introducido un error o una vulnerabilidad, y más fácil revertirlos sin tener que rehacer otro trabajo. Ir un paso más allá y establecer confirmaciones firmadas verifica que los desarrolladores correctos están confirmando código en tu repositorio (¡incluso si solo eres tú!). 

Separar las ramas de desarrollo, de ensayo y de producción.

Las ramas en Git ayudan a crear espacios distintos y autónomos para trabajar, previsualizar y publicar código. El desarrollo activo de nuevas funciones en una rama separada ayuda a evitar que el código inacabado, con errores o inseguro se transfiera accidentalmente a la aplicación activa. Una vez que una nueva característica o funcionalidad está completamente desarrollada y probada, una rama de ensayo actúa como otra puerta de seguridad y calidad, lo que le permite revisar y finalizar los cambios antes de liberar a la producción. Sólo las características totalmente probadas y estables pueden fusionarse en la rama de producción (normalmente llamada principal).

Repositorios Git alojados: GitHub GitLab   

Mantener los secretos separados del código

‍

‍

Secretos-como sus contraseñas, claves de cifrado, tokens API y certificados digitales-deben ser manejados por separado del código para evitar comprometer directamente a su base de código. Puedes comprobar tu código en busca de secretos con Aikido, incluso desde tu IDE Cursor.

Proteja su 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 objetivo abrumando 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 entrega de contenidos (CDN) como CloudFlare o CloudFront. Algunos proveedores de alojamiento de dominios incluso ofrecen una CDN como servicio integrado. 

No te autentiques solo

La autenticación (al igual que 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 específica para aplicar una política de contraseñas y ofrecer fácilmente un inicio de sesión único o incluso una autenticación multifactor para tu aplicación a medida que creces protegerá tus cuentas de usuario y tu reputación. 

Grandes herramientas: Auth0, Quasr 

Nunca haga su propia criptografía

Del mismo modo, la criptografía es un campo de especialización, así que confía siempre en los mecanismos, bibliotecas y herramientas establecidos. No construyas tus propias implementaciones, ni utilices banderas y opciones que no entiendas completamente,

le expondrá a grandes riesgos. Bibliotecas como NaCL exponen pocas opciones, restringiéndote a buenas elecciones.

‍

Nivel 1

Configure un canal CI/CD para supervisar su código

Implementar una canalización 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 herramientas de análisis estático de código para realizar pruebas estáticas de seguridad de aplicaciones (SAST), que analizan su código en busca de fallos que puedan dar lugar a vulnerabilidades de seguridad. También puede integrar una herramienta de pruebas dinámicas de seguridad de aplicaciones (DAST, a veces denominada supervisión de superficie) para simular ataques e identificar vulnerabilidades en el frontend de su aplicación web (como la búsqueda de puertos abiertos o tráfico entrante sin restricciones). 

DAST de código abierto: ZAP

Opensource SAST: Opengrep

Supervise sus dependencias  

Tanto si es consciente de ello como si no, es probable que la mayor parte del código que alimenta su aplicación proceda de proyectos de código abierto y bibliotecas de terceros en los que se entrenan los modelos de IA. Éstas son sus dependencias, y a veces incluso éstas tienen sus propias dependencias, todas las cuales conforman su cadena de suministro de software. Un solo fallo en cualquiera de estas bibliotecas podría poner en peligro toda su aplicación, pero puede reducir el riesgo utilizando las herramientas adecuadas para supervisar sus dependencias en busca de vulnerabilidades conocidas.

Herramienta recomendada: Trivy

Prepáralo en segundos con Aikido

Compruebe si sus dependencias contienen malware

Del mismo modo, su cadena de suministro puede incluir paquetes maliciosos que contengan malware. Estos son excepcionalmente peligrosos, ya que los atacantes suelen actuar con rapidez después de haber conseguido introducir malware en su código. Así que también hay que reaccionar con rapidez. Tenga en cuenta que las bases de datos Common Vulnerabilities and Exposures (CVE) son demasiado lentas y no le mantendrán a salvo de este tipo de ataques.

Herramientas: Aikido Intel

Prepáralo en segundos con Aikido

Utilice ficheros de bloqueo para proteger su cadena de suministro

Si no utiliza archivos de bloqueo, cada vez que compile su aplicación, obtendrá las últimas versiones de todos los paquetes de código abierto. Los archivos de bloqueo permiten realizar compilaciones reproducibles utilizando las mismas versiones de las dependencias de código abierto. Esto mantiene la estabilidad de la aplicación en caso de que se produzcan cambios en las dependencias, pero también protege la aplicación contra ataques a la cadena de suministro cuando la última versión de una dependencia se ha visto 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 acción de GitHub tj-actions/changed-files, haciendo que la acción comprometida imprimiera secretos de CI/CD en los registros de compilación de GitHub Actions.

Evite los ataques de secuencias de comandos en sitios cruzados con cabeceras CSP estrictas

Las cabeceras CSP pueden protegerle de los ataques XSS más comunes proporcionando una capa de seguridad adicional que controla qué recursos dinámicos se permite cargar. Eso impide que los atacantes inyecten scripts en sus páginas web.

Comprueba si los has configurado correctamente con Aikido

Utilizar un cortafuegos de aplicaciones web

Utilice un cortafuegos de aplicaciones web (WAF) o una autoprotección de aplicaciones en tiempo de ejecución (RASP) para proteger los servidores orientados a la web contra amenazas desconocidas de día cero, incluidas las amenazas desconocidas de inyección SQL o XSS. La herramienta escanea e impide las peticiones de los usuarios con comportamiento sospechoso o malicioso (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

Una vez aplicadas las medidas de seguridad anteriores, es hora de mejorar la seguridad.

Aplicar las mejores prácticas para contenedores

Los contenedores empaquetan el software para que pueda ejecutarse de forma fiable cuando se traslada de un entorno informático a otro. Agrupan una aplicación con todas sus dependencias necesarias, como bibliotecas, 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 coherente, independientemente del entorno en el que se despliegue. 

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

Mantenga actualizadas las imágenes base de Docker 

Las vulnerabilidades en la imagen base de tu contenedor (el plano de lo que compone tu contenedor) ponen en riesgo tu aplicación. Descargue regularmente todas las actualizaciones de seguridad de su imagen base. En el caso de los servidores, puedes delegar esta tarea en un proveedor PaaS como Heroku o AWS Beanstalk.

Escanee su seguridad Docker usando: Syft Grype Trivy

Prepáralo en segundos con Aikido

Ejecutar contenedores Docker con privilegios restringidos

Los privilegios limitados dificultan a los atacantes exitosos tomar el control del host o rebotar a otros servicios. Evita ejecutar contenedores con roles de usuario privilegiados, como root en sistemas Unix, o Administrador o Sistema en sistemas Windows.

Proteja sus secretos

Mantener los secretos separados del código es un buen comienzo. Si utilizas contenedores, también querrás asegurarte de que tus archivos secretos y otros datos confidenciales están protegidos adecuadamente. 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, rotar los secretos con regularidad y establecer 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

Compruebe si sus paquetes han llegado al final de su vida útil (EOL)

A medida que los paquetes envejecen y dejan de recibir soporte, aumenta el riesgo de que se produzcan exploits. Debes asegurarte de actualizar los paquetes que pronto lleguen al final de su vida útil.

O configúrelo en segundos con la función de escaneado de contenedores de Aikido

Aplique las mejores prácticas a sus cuentas en la nube

Mantenga separadas las cuentas en la nube de desarrollo, ensayo y producción. 

Al igual que quieres mantener separadas tus ramas Git de desarrollo, staging y producción, lo mismo se aplica a tus cuentas en la nube. Aunque podrías crear redes virtuales dentro de tus cuentas en la nube para mantener separadas la puesta en escena y la producción, esto puede volverse complicado más adelante a medida que crezcas, ya que acabarás gestionando continuamente los derechos de acceso de los usuarios para los nuevos desarrolladores. Recomendamos mantener el desarrollo, la puesta en escena y la infraestructura de producción en cuentas en la nube completamente separadas. Todos los proveedores de la nube ofrecen facturación unificada, así que un quebradero de cabeza menos.

Utilizar herramientas de gestión de la postura ante la nube

Los proveedores de la nube ofrecen tantas funciones que es fácil pasar por alto o configurar mal algo que te ponga en peligro. Utilice una herramienta de gestión de la postura de seguridad en la nube (CSPM) para escanear su nube en busca de anomalías.

Herramientas CSPM: Cloudsploit AWS Inspector

Prepáralo en segundos con Aikido

Activar las alertas de presupuesto en nube

En caso de que su cuenta en la nube sea pirateada, una forma segura de detectar que alguien está minando Bitcoin en su cuenta es configurar alertas de presupuesto para controlar los gastos. Tu proveedor de servicios en la nube debería ofrecer alertas integradas para esto, o puedes configurar un escaneo de la nube con Aikido para comprobar si hay problemas de presupuesto y desconfiguraciones arriesgadas. 

Compruebe sus LLMs para los exploits más comunes

Además de construir con LLM, puede que estés integrando LLM en tu producto de cara al público. Puede tener un chatbot que ofrezca soporte a los usuarios, o un asistente de IA que les ayude a incorporarse. Si tus clientes interactúan con un LLM de cualquier forma, es una buena idea probar los exploits más comunes para no exponer a los clientes a riesgos de seguridad. 

Compruebe los exploits más comunes: OWASP Top 10 para LLMs

Más allá de

Implantar un ciclo de vida de desarrollo seguro

Una gran parte de la práctica moderna de la seguridad se desplaza hacia la izquierda: la introducción de medidas de seguridad en el ciclo de vida del desarrollo en una fase más temprana. Esto ayuda a adquirir el hábito de las buenas prácticas en cada fase del proyecto y a detectar los problemas antes de que se conviertan en una amenaza real. Eso significa adherirse a una lista de comprobación de seguridad como ésta, familiarizarse con los fallos de seguridad típicos y estar atento a ellos durante la revisión del código, e implementar comprobaciones de seguridad también en los pull requests. 

Más información: Top Ten de OWASP

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 especializados siguen siendo vulnerables a las brechas. Aunque el código de las vibraciones no es seguro por defecto, si adoptas las mejores prácticas de seguridad desde el principio podrás entregarte por completo a las vibraciones. Sea lo que sea lo que estés construyendo, merece la pena el esfuerzo. 

Para saber más

• Lista de comprobación de seguridad del CTO de SaaS 2025 de Aikido
• Guía de código abierto para la seguridad de las aplicaciones de las startups

‍