🤖 AI

Understanding the Impact of AI Code Assistants on Security API Usage: An Empirical Study

Este estudio empírico de 44 desarrolladores profesionales revela que, si bien GitHub Copilot mejora la corrección funcional y reduce marginalmente algunos patrones inseguros, no logra mejorar significativamente el uso de APIs de seguridad, dejando a menudo a los desarrolladores inconscientes de las vulnerabilidades restantes.

Autores originales: Zahra Mousavi, Chadni Islam, M. Ali Babar, Alsharif Abuadbba, Kristen Moore

Publicado 2026-07-14

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Zahra Mousavi, Chadni Islam, M. Ali Babar, Alsharif Abuadbba, Kristen Moore

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo un club secreto y necesitas instalar cerraduras de alta tecnología, alarmas y túneles secretos para mantener fuera a los intrusos. Estas cerraduras son como las APIs de Seguridad —herramientas especiales que los desarrolladores usan para proteger el software—. Pero aquí está el giro: estas cerraduras son complicadas. Si las instalas mal, el túnel "secreto" podría ser simplemente una puerta abierta de par en par para los hackers.

Ahora, imagina que tienes un asistente robot superinteligente llamado Copilot que puede escribir código por ti. Podrías pensar: "¡Genial, el robot conoce todas las reglas, así que mi club será la Fortaleza de la Soledad!". Pero un nuevo estudio realizado por Zahra Mousavi y su equipo en universidades y laboratorios de investigación en Australia decidió poner esta idea a prueba. No solo le pidieron al robot que construyera una cerradura; observaron a 44 desarrolladores profesionales reales intentando construir estas cerraduras, tanto con la ayuda del robot como sin ella.

Aquí está lo que encontraron, servido con una dosis de realidad.

El robot es un gran ayudante, pero un mal guardia de seguridad

Primero, la buena noticia: Copilot es un fantástico velocista. Cuando los desarrolladores tuvieron que construir una cerradura compleja (específicamente, un sistema Google OAuth para acceder a datos de usuario), el robot les ayudó a terminar el trabajo mucho más rápido.

Sin el robot, solo el 45% de los desarrolladores (10 de 22) lograron que la cerradura funcionara.
Con el robot, el 91% de los desarrolladores (20 de 22) lograron que funcionara.
El robot también redujo el tiempo para completar la tarea compleja en un 63%, bajando el promedio de 62 minutos a 23 minutos.

Así que, si tu objetivo es solo construir la puerta y hacer que se mueva, el robot es una gran victoria.

Pero aquí está la trampa: Que la puerta esté construida no significa que esté cerrada con llave. De hecho, ninguno de los desarrolladores, ya fuera usando el robot o no, logró construir una cerradura totalmente segura para las tareas que se les dieron. Cada intento en las tareas evaluadas tenía al menos un fallo importante.

La trampa del "Confía en mí"

El estudio analizó dos tipos específicos de cerraduras: JSSE (para conexiones de internet seguras) y Google OAuth (para iniciar sesión en aplicaciones). Encontraron que el robot no solucionaba los problemas de seguridad; en muchos casos, simplemente ayudaba a construir las cerraduras rotas más rápido.

El error de "Confiar en todos": Imagina a un guardia que deja pasar a cualquiera porque parece agradable. En el estudio, algunos desarrolladores (y el robot) configuraron el sistema para "confiar en todos los certificados". Esto es como decirle a tu guardia: "Si alguien muestra una identificación, déjalo pasar, incluso si es falsa". Este es un enorme agujero de seguridad.
El error del "Código secreto": Algunos desarrolladores escribieron sus contraseñas secretas directamente en el código, como escribir la llave de tu casa debajo del felpudo. ¡El robot también sugirió esto a veces!
El error de "No verificar": Al conectarse a un servidor, necesitas verificar si realmente estás hablando con la persona correcta. Muchas implementaciones omitieron este paso, dejando la puerta abierta para un atacante de "Hombre en el medio" (alguien que finge ser tu amigo para robarte tus cosas).

Los investigadores descubrieron que, aunque el robot ayudó a corregir algunos errores pequeños, no detuvo los grandes fallos de seguridad. De hecho, el 100% de las tareas evaluadas resultaron en código con problemas de seguridad. El robot no hizo que el código fuera más seguro que el de los humanos trabajando solos; simplemente hizo que el código inseguro apareciera más rápido.

El punto ciego humano

Esta es la parte más sorprendente de la historia. Los investigadores preguntaron a los desarrolladores: "¿Creen que su código es seguro?".

A pesar de que ninguno del código era realmente seguro, la mayoría de los desarrolladores dijeron: "¡Sí, creo que resolví esto de forma segura!".
Solo un puñado de personas se dio cuenta de que habían cometido un error.
Al hablar con el robot, casi nadie preguntó: "Oye, ¿esto es seguro?". Solo preguntaron: "Haz que funcione".

Es como un grupo de personas construyendo un puente y pidiendo ayuda a un robot. El robot les ayuda a colocar los ladrillos rápidamente, pero nadie comprueba si el puente puede soportar peso. Cuando se les pregunta: "¿Creen que este puente aguantará?", la mayoría dice: "¡Claro!", aunque esté a punto de colapsar.

¿Podemos enseñar mejor al robot?

Los investigadores intentaron una cosa más. Pidieron a los desarrolladores que le dijeran específicamente al robot: "¡Oye, revisa esto por seguridad!" o "¡Eres un experto en seguridad, arregla esto!".

Cuando lo hicieron, el robot sí corrigió algunos de los errores en la cerradura más simple (JSSE).
Sin embargo, para la cerradura más compleja (OAuth), el robot seguía pasando por alto muchos agujeros de seguridad críticos, incluso cuando se le pedía que tuviera cuidado.

La conclusión

Este estudio sugiere que, si bien los asistentes de IA como Copilot son increíbles para ayudarnos a escribir código rápido y correctamente, no son un escudo mágico contra los hackers.

El Robot: Excelente en velocidad y función, pero no es un experto en seguridad.
Los Humanos: A menudo demasiado confiados en el robot y no verifican la seguridad por sí mismos.
El Resultado: Estamos construyendo sistemas que parecen seguros pero que en realidad están llenos de agujeros.

Los investigadores concluyen que no podemos confiar solo en el robot para mantenernos seguros. Necesitamos ser nosotros quienes hagamos las preguntas difíciles de seguridad, verifiquemos el trabajo y nos aseguremos de que las "cerraduras" que construimos estén realmente cerradas. El robot es una herramienta poderosa, pero no es un reemplazo para una mente consciente de la seguridad.

Resumen Técnico: Comprensión del Impacto de los Asistentes de Código de IA en el Uso de APIs de Seguridad

Planteamiento del Problema

Las Interfaces de Programación de Aplicaciones (API) de seguridad, como SSL/TLS y OAuth, son fundamentales para la seguridad del software moderno, pero son frecuentemente mal utilizadas debido a su complejidad, documentación insuficiente y falta de capacitación de los desarrolladores. Dicho mal uso conduce a vulnerabilidades graves, incluyendo ataques de Hombre en el Medio (MitM) y brechas de datos. Aunque los asistentes de código basados en Modelos de Lenguaje de Gran Escala (LLM), como GitHub Copilot, se están adoptando cada vez más para acelerar el desarrollo, su impacto en el uso seguro de estas APIs críticas sigue siendo insuficientemente explorado.

La investigación existente se ha centrado principalmente en salidas de modelos generadas a partir de prompts predefinidos sin intervención del desarrollador, o en patrones de vulnerabilidad generales en lugar de un mal uso específico de las API. Existe una brecha crítica en la comprensión de cómo los desarrolladores profesionales interactúan con los asistentes de IA al implementar APIs de seguridad, cómo estas herramientas influyen en la seguridad final del código y hasta qué punto los desarrolladores reconocen y mitigan los problemas de seguridad en los flujos de trabajo asistidos por IA.

Metodología

Los autores llevaron a cabo un estudio empírico intrasujeto que involucró a 44 desarrolladores profesionales de Java. El diseño del estudio comparó dos condiciones para cada participante:

Condición Experimental: Completar una tarea con la asistencia de GitHub Copilot.
Condición de Control: Completar una tarea diferente sin ninguna asistencia de IA.

Tareas:
Los participantes fueron asignados a dos tareas de programación que involucraban distintas APIs de seguridad:

Tarea JSSE: Implementar un método createSSLSocket para establecer conexiones seguras SSL/TLS.
Tarea de Google OAuth: Implementar un método authorize para una aplicación de escritorio para acceder a los datos de Gmail del usuario mediante OAuth.

Procedimiento:

Los participantes trabajaron en un entorno virtual controlado de AWS con VS Code.
El estudio utilizó el contrabalanceo para mitigar los efectos de aprendizaje y fatiga, dividiendo a los participantes en cuatro grupos según el orden de las tareas y la disponibilidad de Copilot.
Las sesiones fueron grabadas en pantalla y los participantes completaron encuestas posteriores a la tarea sobre su conciencia de seguridad y autoevaluación de la seguridad del código.
Evaluación: El código fue analizado para verificar la corrección funcional y la seguridad. El análisis de seguridad consistió en una revisión manual realizada por dos expertos en seguridad utilizando una taxonomía de mal uso de API de seguridad (Mousavi et al.). Se utilizó un modelo de regresión logística para analizar el impacto de Copilot y el trasfondo del participante en los resultados. Además, un análisis posterior al estudio consistió en volver a solicitar a Copilot instrucciones centradas en la seguridad para probar su capacidad para identificar y corregir mal usos.

Contribuciones Clave

Este estudio presenta la primera investigación empírica centrada en el desarrollador sobre el uso de asistentes de código de IA para tareas de API de seguridad en entornos realistas. Las principales contribuciones son:

Evidencia Empírica sobre el Impacto de Copilot: Un análisis comparativo del desarrollo asistido por Copilot frente al desarrollo sin asistencia respecto a la corrección funcional y el uso seguro de las API.
Identificación de Mal Usos Persistentes: Una categorización detallada de los mal usos de las API de seguridad que persisten, se introducen o se mitigan parcialmente cuando se utiliza Copilot.
Análisis de la Conciencia del Desarrollador: Una investigación sobre cómo los desarrolladores interactúan con Copilot en relación con la seguridad, incluyendo sus estrategias de prompting y su capacidad para reconocer implementaciones inseguras.
Perspectivas de Ingeniería de Prompts: Una evaluación de si los prompts dirigidos hacia la seguridad pueden guiar eficazmente a Copilot para generar código más seguro.

Resultados Clave

Corrección Funcional (RQ1)

Copilot mejoró significamente la corrección funcional, particularmente para la tarea de OAuth, que era más compleja.

Tarea JSSE: Todos los participantes produjeron código funcional independientemente del uso de Copilot, aunque los usuarios de Copilot completaron la tarea más rápido (14 min frente a 26 min).
Tarea de OAuth: Las tasas de éxito aumentaron del 45% (sin asistencia) al 91% (con asistencia de Copilot), con una disminución en los tiempos de finalización del 63%.
Significancia Estadística: La regresión logística confirmó un efecto positivo estadísticamente significativo de Copilot en los resultados funcionales ( $p = 0.007$ ).

Resultados de Seguridad (RQ2)

A pesar de las mejoras en la funcionalidad, ningún participante produjo una implementación completamente segura en ninguna de las dos condiciones.

Mal Usos de JSSE: Se identificaron tres tipos: Estándares SSL/TLS inseguros (M1), confianza en todos los certificados (M2) y falta de verificación de nombre de host (M-3). Copilot mostró una reducción ligera y no significativa en M1 y M2, pero no evitó M3.
Mal Usos de OAuth: Se encontraron seis mal usos críticos, incluyendo almacenamiento local de secretos (M4), almacenamiento local de tokens (M5), falta de parámetros de estado (M6), falta de autenticación de SP (M7), falta de PKCE (M8) e insuficiencia en la protección de la transmisión (M9).
Impacto General: Copilot no mejoró significativamente el uso seguro de las API. La tasa de mal uso fue alta en ambas condiciones, con el 100% de las implementaciones conteniendo al menos un fallo de seguridad.

Conciencia de Seguridad (RQ3)

Los desarrolladores demostraron una conciencia de seguridad limitada al interactuar con Copilot.

Prompting: Solo 7 de los 44 participantes mencionaron explícitamente la seguridad en sus prompts. En la mayoría de los casos, el lenguaje de seguridad era una copia textual de la descripción de la tarea en lugar de una preocupación genuina. Solo dos participantes demostraron una consideración de seguridad deliberada en sus prompts.
Autoevaluación: Hubo una discrepancia significativa entre la percepción y la realidad de la seguridad. La mayoría de los participantes creían que sus soluciones eran seguras a pesar de la presencia de vulnerabilidades críticas.
Prompting Posterior al Estudio: Cuando se le instó explícitamente a "revisar el código y mejorarlo basándose en las mejores prácticas de seguridad", Copilot corrigió con éxito algunos mal usos de JSSE (por ejemplo, M1 y M2) y ofreció recomendaciones para el almacenamiento de tokens de OAuth. Sin embargo, falló al abordar otros problemas críticos de OAuth, como la falta de parámetros de estado o PKCE, lo que indica limitaciones en su razonamiento de seguridad para flujos complejos.

Significancia y Reivindicaciones

El artículo sostiene que los desafíos de seguridad en el desarrollo asistido por IA no son solo una limitación de la salida del modelo de IA, sino también un problema de conciencia del desarrollador. Incluso cuando se les informó que la seguridad sería evaluada, los desarrolladores rara vez interactuaron con la herramienta desde una perspectiva de seguridad y a menudo no lograron reconocer el código inseguro.

El estudio concluye que, si bien los asistentes de IA como Copilot mejoran la productividad y la corrección funcional, actualmente no permiten que los desarrolladores produzcan implementaciones completamente seguras de las API de seguridad. Los autores enfatizan que:

La dependencia ciega del código generado por IA introduce vulnerabilidades graves.
El prompting orientado a la seguridad puede generar mejoras, pero no es una panacea para todos los tipos de mal uso.
El uso efectivo de la IA en el desarrollo seguro requiere que los desarrolladores mantengan una base sólida en principios de seguridad y evalúen críticamente el código generado por la IA.

Los autores posicionan este trabajo como un paso fundacional hacia la comprensión de la intersección entre la IA y la seguridad del software, llamando a futuras investigaciones sobre herramientas conscientes de la seguridad, mejora de la usabilidad de las API y un mejor alineamiento de los LLM con las mejores prácticas de seguridad.