Errores de seguridad en el código generado por IA: Qué sucede cuando los desarrolladores omiten la revisión

Lo cual es muy, muy importante hoy en día. Dado que usamos mucho código de IA y también muchas herramientas de IA para generar código, quiero plantear el tema sobre las trampas de seguridad en el código generado por IA, un tema que más y más desarrolladores explorarán. Sabemos que los modelos están mejorando cada vez más, pero ¿nuestro código es seguro al final? ¿Y qué sucede si el desarrollador no revisa este código más tarde? Así que la agenda de hoy será una pequeña introducción sobre mí, quién soy, qué hago, y también la promesa del código de IA. Cómo el código de IA es bueno para nosotros, cómo podemos usarlo, por qué podemos usarlo, y algunas suposiciones peligrosas sobre este código y la ayuda de la IA.

Más adelante, continuaremos con lo que cambia cuando el propio desarrollador no solo usa la herramienta, sino que también revisa el código más tarde. Y aquí compartiré con ustedes cinco trampas, que creo que son realmente importantes en el mundo de la seguridad, y de las que debemos estar conscientes. Más adelante, quiero compartir con ustedes información sobre dónde pueden aprender sobre seguridad, también cómo pueden estar al día, y por supuesto, si tienen preguntas, pueden preguntar más tarde. Así que comencemos.

Sobre mí, brevemente, soy un desarrollador front-end con 11 años de experiencia, usando IA diariamente, diferentes herramientas de IA, como un cursor, como código, y también VS Code, extensiones para IA, como un Copilot, Kiro también, así que todas las variedades. Mi rol en mi empresa es un principio. Así que por esa razón, tengo la oportunidad de usar muchas herramientas, pero también de ver cuáles se ajustan, son malas o buenas para nosotros, como estándares de la empresa. También, estoy haciendo charlas tecnológicas, y soy autor de algunos libros, y soy un Docker captain, este es un título otorgado por Docker, a los participantes de la comunidad, que son realmente buenos en lo que hacen, y también, soy un orador.

Entonces, hablando de guías de Docker, todas estas guías fueron escritas por mí, así que si estás interesado, por ejemplo, en cómo dockerizar una aplicación de ReactJS de la mejor manera, puedes ir a la documentación oficial y verificar. Dicho esto, quiero compartir contigo algo muy importante, y es el lanzamiento de mi nuevo libro, y este es Docker for ReactJS Developers. Este libro es una pieza faltante, que intento llenar en nuestro mundo de la tecnología. Simplemente porque muchos recursos en Internet están escritos de una manera que los desarrolladores de back-end deberían explorar y entender Docker. Y cuando hablamos desde la perspectiva del front-end, está ausente. Así que intento traer la información y llenar este vacío para la comunidad. Puedes revisar Docker for ReactJS Developers. Si te encanta ir a Docker o React, este libro es para ti. El resto de los libros están relacionados solo con entrevistas en el mundo de React, y también tengo un libro para TypeScript. Definitivamente visita mi sitio web, y si estás interesado, revisa, escríbeme, o simplemente comparte tu opinión.

Ahora, volviendo a la presentación en sí. Hoy, realmente quiero mencionar algo muy importante, y esa es la promesa de la IA. ¿Cuál es la promesa de la IA? Entonces, la mayoría de los desarrolladores hoy en día están usando IA para escribir código. Pero, ¿es el código en sí lo suficientemente bueno, y la velocidad a la que la IA es realmente buena, promete entregar una buena calidad de código? Y también, vi a muchas personas, incluyéndome a mí, que estamos usando IA, pero dejamos de pensar en todo el proceso. Dejamos de pensar en cómo deberíamos desarrollar la aplicación de la manera correcta. Y también, me vi a mí mismo y a muchos desarrolladores, estoy enseñando que esta zona de confort del código generado por IA y la velocidad en sí, no tiene sentido. Y por esa razón, quiero decir algunas razones incómodas de la realidad y lo que realmente está sucediendo cuando usamos IA sin pensar en lo que causará más adelante en nuestra aplicación. Lo que asumimos.

Entonces, cuando el código se ejecuta sin errores, el proceso de verificación, se desplaza de una manera hacia la IA. Lo que quiero decir aquí. Entonces, imagina que generamos alguna característica. Esta característica es realmente grande. Y después del cambio de IA, digamos miles de archivos, lo que solemos hacer es confiar ciegamente en que la IA que el código en sí es muy bueno solo porque el modelo es muy bueno. Pero a menudo esa no es la realidad. Y lo vi de primera mano cómo nuestras aplicaciones fueron comprometidas, fueron hackeadas solo porque lo que está sucediendo es que el desarrollador no hace lo que se necesita hacer al final. Y eso es revisar el código en sí. Y el proceso de revisión es muy difícil solo porque la IA puede cambiar muchos archivos y generalmente las personas solo los miran y no intentan detectar los errores o usar IA para corregirlos. Entonces, lo que está sucediendo en mi equipo hoy en día es que las personas, desarrolladores senior, están diciendo que esto es culpa de la IA. El código es una mierda, pero culpemos a la IA.

Y la IA también lo es. Entonces, cuando culpas a la IA, simplemente no estás diciendo nada. Eres la persona que usa la IA. Así que, la propiedad del código es tuya. Y es tu responsabilidad verificar el código en sí.

Bien. Algunas suposiciones peligrosas para el código de IA. En primer lugar, parece limpio. Así que, nada sospechoso. Pero, ¿es esto realmente cierto? La aplicación compila. Entonces, técnicamente, esto debería funcionar. La aplicación está bien. Mi prueba pasó. Así que, todo está cubierto. Y además, el sprint está terminando.

Arreglaremos esto más tarde. Así que, todas estas suposiciones, las hice por mí mismo y también la gente las hace mucho. Pero la dura realidad de entender es que la IA realmente produce código rápido. Parece realmente agradable. Estructuralmente es bueno. Es capaz de entender tu contexto de la aplicación.

Pero son prácticas heredadas ciegamente como código que no está verificado lo suficiente, código que expone vulnerabilidades de seguridad al público, código que está usando, digamos, algunas de las variables de entorno, codificadas en la aplicación. O IA, solo porque es muy rápida generando código, no significa que debamos confiar en ella. Y vimos muchos, muchos ataques surgiendo hoy en día, incluyendo la biblioteca oficial de React.js. Fue comprometida. El lado del servidor de la misma, fue comprometido solo porque hoy en día intentamos producir mucho código, pero en este proceso rápido, no tenemos verificación de validez.

¿Es este el enfoque correcto? ¿Es este código seguro? Y, de nuevo, la realidad es que no hay responsabilidad compartida con la IA. Si alguien intenta hackearte y tiene éxito, culparán a los desarrolladores, no a la herramienta de IA detrás de ello. Así que, ten en cuenta que cada código que va a producción, es tu código. Estás asignado a él. En la historia de GitHub y también en los commits, tu nombre estará puesto, no la herramienta de IA, que generó este código.

Entonces, ¿qué cambia cuando el propio desarrollador revisa el código antes de enviarlo? El código es confiable en lugar de cuestionado. Vimos que la IA puede generar código muy rápido, pero este código puede ser comprometido. Y cuando revisas el código, estás seguro de que el código está listo para ir a producción y todo estará bien. Así que también, los casos extremos son ignorados. ¿Qué significa eso? A veces usamos diferentes aplicaciones comunicándose entre sí, lo que significa que la relación entre aplicaciones puede ser comprometida, puede estar exponiendo secretos, o podemos comunicarnos con la aplicación de la manera incorrecta, o muchas, muchas variedades. Cuando hablamos de seguridad, debemos seguir las reglas de que tantas capas de seguridad como sea posible tienes en tu aplicación para verificar que tu código es seguro.

Esto significa que al final, tu aplicación será realmente segura y no estarás comprometido. Así que más seguridad, es igual a una aplicación suficientemente buena y buen nombre en la comunidad. Así que también, aquí es muy, muy importante entender la propiedad. De nuevo, dije muchas veces que tu código es tu responsabilidad, pero esto es muy, muy importante hoy en día, solo porque vi muchos ejemplos de, está bien, la IA puede hacer eso, la IA puede hacer muchas cosas, pero al final, tú eres la persona detrás de la IA. Así que úsala como un desarrollador, pero tampoco es lo suficientemente buena para enviar algo que no esté verificado.

Como dije, veamos algunas trampas, que la IA a menudo hace y cómo evitarlas, por supuesto. Así que primero que todo, lo que sucede cuando la IA crea aplicaciones es que usa mucho buen HTML, usa mucho buen, digamos, CSS, y es muy buena creando la aplicación en sí. Pero cuando hablamos de ataques de seguridad como ataques de inyección, por ejemplo, puedes poner una inyección SQL en tu entrada solo porque la IA nunca sanitizó la entrada en sí. O digamos, ataques que son realmente comunes hoy en día, es que olvidaste eliminar algunas verificaciones de sanitización o comprometes la sanitización en neto solo, lo que lleva a una aplicación comprometida.

Así que aquí la regla, es siempre validar, cuando hablamos de formularios, cuando hablamos de entradas, o cualquier tipo de envío o interacción del usuario a la base de datos y backend para ser validados y sanitizados de manera adecuada. Y para ser honesto, aquí el ejemplo es muy malo. La IA no hará la validación y sanitización por sí misma. Las herramientas generarán el código, pero no son lo suficientemente inteligentes para pensar en la dirección de cómo esto debería ser validado o sanitizado de la mejor manera posible. Y aquí también quiero compartir que usualmente la IA toma información de Internet. Y enseñamos a nuestros modelos desde Internet. En Internet puedes encontrar muchos buenos ejemplos, pero la mayoría de los ejemplos son realmente peligrosos y no sabes quién es la persona detrás de ellos. De nuevo, no confíes en la IA. Valida el código antes de ir a producción.

El segundo ataque es muy popular. Así que esto es lógica de autenticación no segura. Imagina que tienes un formulario en tu sitio web. Y este formulario es utilizado por personas para poder iniciar sesión en tu aplicación. Así que imagina que estás solicitando y escribiendo a la IA, por favor, genérame un formulario de inicio de sesión. Quiero poder iniciar sesión. Y no especificas cómo ocurrirá el proceso de autenticación. Qué herramientas de autenticación usarás. Usualmente lo que hará la IA es generar las credenciales de inicio de sesión, usuarios de prueba, o prueba 1, 2, 3, o algo que no está listo para ningún entorno como staging o producción. Esto es para propósitos de prueba. Así que para que la IA pueda generar un proceso de autorización y autenticación adecuado, debes decirle exactamente a la IA qué seguir y también qué herramientas estarás usando, como Auth0, por ejemplo, o JWT token o algo más.

Dicho esto, sobre la lógica de autenticación, cada vez debes validar, hacer cualquier cosa que falte. Como, digamos, usuario, que es usuario de prueba, úsalo en tu aplicación o archivos de prueba, con los que puedes ir de manera segura a tu aplicación, pero olvidaste eliminarlo, solo porque la IA es muy buena para generar costos rápidamente. Así que la segunda trampa, es básicamente autorización rota. Bien, así que imagina que la IA generará el formulario. Este formulario de inicio de sesión es muy bueno. Se ve bonito, brillante, hermoso, pero al final, solo le estás diciendo a la IA, bien, este es mi usuario. Quiero que este usuario solo pueda acceder al panel de control. Y no quiero que pueda acceder a, digamos, configuraciones del sistema o cualquier tipo de configuraciones, que afectarán a diferentes usuarios. Así que la IA generará el formulario, pondrá alguna validación, probablemente la validación en sí será tonta, solo porque la IA no sabe mucha información, lo que tienes en tu base de datos. Imagina que este usuario de prueba puede acceder al panel de control, pero también a las configuraciones. Y cuando las configuraciones han cambiado, todo se cambia en tu aplicación. Básicamente está comprometido solo porque nunca especificaste a la IA, cuál es tu proceso de autorización, qué permisos deberías tener para diferentes roles, y si este usuario específico, es rol de editor o rol de administrador o qué rol en sí.

Y sí, me encanta este. Así que secretos en el código. Sí, vista realista. Tenemos muy buen progreso de herramientas de IA y esos modelos, que generan código. Pero aún así, vi muchos ejemplos en revisiones de código, que la IA pone ciegamente secretos en el código, en lugar de ponerlos en algunos archivos, que nunca se comprometen a Git, como archivos dot NV o cualquier mecanismo secreto, o digamos secretos de GitHub y etcétera. Ciegamente ponen algo que nunca será expuesto, pero ahora está expuesto solo porque usamos IA.

Y déjame darte un ejemplo. Así que tengo un cliente, y estaba trabajando con IA para cambiar, digamos, cómo el backend se comunica con el frontend. Y cambiamos la URL de la API, y también las credenciales para poder usar este backend. Y proporciono información a la IA, como el contexto en sí, qué es el backend, cómo podemos conectar y etcétera. Y lo que vi es que en lugar de actualizar el archivo dot NV, creó directamente la variable, era const. Así que directamente, puso el secreto en el código mismo, lo que hace que mi aplicación esté realmente expuesta al mundo. Y por favor, nunca comprometas archivos dot NV, nunca confíes ciegamente en la IA, y también los secretos deben permanecer en lugares específicos. Por esa razón, muchos, digamos, proveedores de hosting, especifican un lugar específico para los secretos. Tu código es básicamente código, pero nunca debería incluir ningún tipo de secretos o variables de entorno.

Y el último, también es muy, muy bueno, y eso es la ceguera de dependencias y cadena de suministro. Así que, vi una aplicación, era una aplicación de ReactJS. Así que esta aplicación de ReactJS, era antigua, como de un año y medio, y nadie la tocó. Y por supuesto, decidimos usar IA para actualizar nuestra aplicación a una nueva versión de ReactJS, y también para actualizar todo lo relacionado con los cambios en esta versión. Lo que está sucediendo es que React, era realmente antiguo, era como, creo, 16.8, y no estaba actualizado, así que la IA misma intentó actualizar a nuevas versiones. Pero lo que está sucediendo es que la IA actualiza a una versión específica, que una semana antes, React World y también Next.js y muchas personas compartieron alrededor del mundo que esta versión específica, está comprometida, y deberíamos actualizar al último parche. Desafortunadamente, la IA no hace eso, sino que instala directamente la versión comprometida de ReactJS. Y este es solo un pequeño ejemplo. También, cuando vi como ejemplo es que cuando la IA actualiza los paquetes de NPM, también agregó algunos paquetes que no quiero, y más tarde, no hace como una verificación, por ejemplo, NPM audit, pero lo que está sucediendo es que solo me dice, está bien, está hecho. Todo está funcionando bien. La compilación es buena. Todo está bien. Pero en una simple verificación de auditoría, encontré como 10 o 20. No recuerdo exactamente, pero eran muchas vulnerabilidades de seguridad solo porque, nuevamente, confié ciegamente en la IA.

Así que muchas personas me preguntan qué pueden usar, como información para estar seguros y también mantenerse actualizados. Estas son mis preferencias. Por supuesto, te aconsejo encarecidamente que las revises, explores el internet. Tenemos mucha información sobre seguridad, pero en lo que confío es realmente en la organización CVA, que es un sitio web que incluye todas las vulnerabilidades de seguridad en este sitio web y también les da un identificador o ID específico, que más tarde puede usarse para referenciar la vulnerabilidad para ver también cuán seria es esta vulnerabilidad. Por ejemplo, este fue el lugar donde nuestra comunidad de React y React mismo mencionaron que tienen una vulnerabilidad en los componentes del servidor. Proporcionaron el ID y esta vulnerabilidad, estaba en el rango máximo posible y era alta. Así que por esa razón, todos en el mundo que usan React entienden que tienen algo en React que está comprometido, y por esa razón, deberíamos actualizar los presupuestos.

Otro recurso, muy, muy bueno, muy útil, es Cloudflare, por supuesto. Son un proveedor realmente bueno, digamos, y también tienen Radar, que nos proporciona información en el mundo real en tiempo real, básicamente, sobre lo que está sucediendo, cuántos problemas de seguridad tenemos, y cómo los riesgos de seguridad están aumentando hoy en día. Desafortunadamente, si investigas un poco, encontrarás que antes de la era de la IA, cuando escribíamos el código, por supuesto, estábamos comprometidos. El hacking en sí mismo estaba involucrado, pero hoy en día, este número está aumentando mucho solo porque ahora podemos usar la IA no solo para escribir el código, sino también para intentar comprometer tu aplicación y usar bots para intentar ralentizar o hackear tu aplicación. Para realizar ataques DDoS o cualquier tipo de vulnerabilidades.

Otro recurso serán básicamente los sitios web oficiales, como Meta, Apple, Google, Reddit, Next.js, o bloggers, YouTubers. Cuando sucede algo realmente grande, como los últimos problemas de seguridad en Next.js y React.js, probablemente, muchos desarrolladores compartirán esta información alrededor del mundo y tratarán de prevenirse a sí mismos y también de ayudar al resto. Pero, está bien, sabemos de dónde mantenernos actualizados sobre lo que está sucediendo, pero la pregunta es, ¿de dónde debería comenzar a aprender sobre seguridad? Usualmente, la seguridad es un tema muy grande. En esta presentación, básicamente cubro las trampas más comunes que he visto, como el ejemplo que hace la IA. Por supuesto, la variedad de riesgos de seguridad de la IA es realmente mucha y para poder mantenerse actualizado y también aprender sobre seguridad y cómo verificar y explorar la seguridad de alguna manera, quiero darte algunos ejemplos de sitios web muy buenos que personalmente uso.

El primero es all apps o básicamente el sitio web de la organización, al que puedes ir y explican de una manera muy, muy agradable cada vulnerabilidad de seguridad. Explican qué es, cómo está afectando tu aplicación y también cómo puedes protegerte. Otro buen recurso se llama Flare Learning. Tienen una ruta de aprendizaje. Puedes ir y seguir algunos cursos. Al final, tendrás una muy buena comprensión de la seguridad en sí. Y por último, pero no menos importante, está TryHackMe. Este sitio web realmente hermoso está creado de una manera que tu propósito allí es intentar hackear el sitio web en sí. Tienes tareas y si eres lo suficientemente inteligente, podrás hackear con éxito el sitio web, lo cual es realmente agradable y un buen recurso para aprender. Por supuesto, explora libros, explora YouTube, publicaciones de blogs, etcétera. El tema de la seguridad es muy, muy grande. Y creo que muchas personas deberían hablar sobre ello solo porque lo que está sucediendo hoy en día es que realmente las aplicaciones se hacen de una manera que la IA nos ayuda, pero la IA no nos defiende.

Todas estas trampas son muy buenas. Las entendemos. Intentaremos mantenernos seguros, pero también cómo deberíamos prevenir estos problemas de seguridad, lo que podemos hacer es básicamente crear reglas de IA. Por ejemplo, en Cursor, puedes crear reglas específicas para la herramienta Cursor y usar estas reglas específicas. Así que cada vez que generes el código, estas herramientas serán utilizadas, y más adelante, estamos seguros de que tenemos una lista de verificación y esta lista de verificación validará que cada paso esté validado, estás seguro, y todas estas trampas no están en tu código.

Creé un repositorio público sobre eso. Por supuesto, puedes ir a explorar, comprometerlo si quieres en tu propio código o intentar apoyar a la comunidad o contribuir al código abierto y crear más reglas. Personalmente, lo que estoy haciendo es que tengo reglas para el código, cómo escribir un código, qué estructura seguir, cuáles son las mejores prácticas. También, estoy incluyendo aquí la seguridad de IA, el rendimiento y no al final, las pruebas.

Las pruebas son muy importantes. Es como una forma de prevenirte antes de que ocurra algo peor. Y si cambias algo, por supuesto, la prueba fallará. Así que deberías actualizar tu código. Y no en el último punto es probablemente la documentación. No olvides actualizar la documentación, trátala como si fuera código, y también actualiza los paquetes NPM de tu aplicación a la última versión. De esa manera, estarás al día y sabrás que nada malo sucederá, al menos por ahora. Porque cuando hablamos de seguridad, todo es para hoy.