IA y código
Seguridad del código generado por IA: riesgos y cómo revisarlo
La seguridad del código generado por IA consiste en tratar el código de asistentes y agentes de programación como el de un colaborador al que no conoces: comprueba cada dependencia que añade, analízalo en busca de secretos y fallos de inyección, y haz que una persona lo revise antes de fusionarlo. Los riesgos nuevos que trae la IA son paquetes obsoletos, maliciosos o que ni siquiera existen.
Plan gratuito, sin tarjeta.
¿Qué riesgos de seguridad tiene el código generado por IA?
Los asistentes y agentes de programación escriben código prediciendo lo que suele venir a continuación, a partir de código existente. Eso los hace rápidos, y también hace que repitan lo que era habitual en ese código, incluidas versiones antiguas de bibliotecas, API obsoletas y malas prácticas de seguridad. Un modelo no sabe qué versión de un paquete se parcheó el mes pasado salvo que lo consulte, y un agente que puede ejecutar comandos puede instalar lo que sugiere antes de que nadie lea el cambio.
Ninguno de estos riesgos es nuevo por sí solo. Lo que cambia es el volumen y la velocidad: más código, más dependencias nuevas y menos personas leyendo cada línea. La respuesta es aplicar de forma automática las comprobaciones que aplicarías a cualquier contribución externa, para que nadie se las salte cuando el diff es grande.
- Versiones de dependencias obsoletas o con vulnerabilidades conocidas, sugeridas a partir de los datos de entrenamiento.
- Nombres de paquetes que no existen, o que un atacante ha registrado porque los modelos tienden a inventarlos.
- Paquetes maliciosos recién publicados, incluidos nombres que imitan bibliotecas populares.
- Secretos pegados en el código o en la configuración: claves de API, tokens, cadenas de conexión.
- Patrones inseguros, como consultas SQL o comandos de shell construidos a partir de cadenas, comprobaciones de certificados desactivadas o criptografía débil.
- Agentes con permisos amplios que instalan paquetes, ejecutan scripts o suben cambios sin revisión.
¿Qué es el slopsquatting?
El «slopsquatting» consiste en registrar un paquete con un nombre que los modelos de IA tienden a inventar, de modo que quien instale ese nombre inventado reciba el código del atacante. La palabra combina «slop», jerga inglesa para el contenido de baja calidad generado por máquinas, con el typosquatting, en el que los atacantes registran variantes mal escritas de paquetes populares. Funciona porque registros públicos como npm y PyPI permiten a cualquiera publicar con un nombre que nadie ha reclamado todavía.
Un estudio revisado por pares y presentado en USENIX Security 2025 probó 16 modelos generadores de código y generó 576.000 muestras de código. Los autores indican que la proporción media de paquetes alucinados fue de al menos el 5,2 % en los modelos comerciales y del 21,7 % en los de código abierto, y recopilaron 205.474 nombres de paquetes inventados distintos. Al repetir la misma instrucción diez veces, un nombre inventado volvió a aparecer más de una vez en el 58 % de los casos, y eso es lo que hace que esos nombres sean lo bastante predecibles como para registrarlos.
El proyecto OpenSSF Malicious Packages publica informes de paquetes maliciosos detectados en registros de código abierto en formato OSV, con identificadores que empiezan por MAL-. Contrastar las dependencias con él detecta los paquetes que ya están documentados. No puede detectar un paquete registrado ayer que nadie ha analizado, así que complementa la comprobación de que un paquete existe, de quién lo publica y de cuánto tiempo lleva disponible. Esa comprobación, en el momento en que un agente propone un paquete, está en la hoja de ruta de KROMSE.
Cómo revisar el código escrito por IA antes de fusionarlo
El objetivo es una rutina que funcione igual tanto si el cambio lo escribió una persona como si lo escribió un agente. Casi todo puede vivir en el pipeline que ya ejecuta tus pruebas; la parte humana es leer el diff con el escepticismo con el que leerías la pull request de un desconocido. OpenSSF publica una guía de instrucciones centradas en la seguridad para asistentes de código, un buen punto de partida para los propios prompts.
- Incluye los archivos de bloqueo (lockfiles) en el repositorio e instala a partir de ellos en CI, para que las versiones revisadas sean las que se publican.
- Fija versiones exactas para las dependencias nuevas y revisa cada cambio en el lockfile, no solo en el manifiesto.
- Confirma que cada paquete nuevo existe, que es el que querías y que tiene un publicador y un historial que puedes comprobar.
- Mantén una lista de paquetes aprobados o instala a través de un proxy de registro interno que bloquee el resto.
- Ejecuta análisis de código fuente, detección de secretos y comprobación de dependencias en cada cambio, y bloquea la fusión ante nuevos hallazgos críticos.
- Exige un revisor con nombre y apellidos para los cambios escritos por IA, y no permitas que los agentes fusionen ni desplieguen por su cuenta.
¿El código escrito por IA cambia tus obligaciones con el Reglamento de Ciberresiliencia?
El Reglamento de Ciberresiliencia (Cyber Resilience Act, CRA) impone sus obligaciones al fabricante de un producto con elementos digitales. Su considerando 34 establece que las obligaciones de gestión de las vulnerabilidades se aplican al producto en su totalidad, incluidos todos los componentes integrados. El artículo 13(5) exige diligencia debida al integrar componentes de terceros, incluidos los de código abierto, y el anexo I, parte II, pide a los fabricantes identificar y documentar los componentes, también mediante una nomenclatura de materiales de los programas informáticos (SBOM), y llevar a cabo exámenes y pruebas eficaces y periódicos de la seguridad del producto.
En la práctica, una dependencia que ha añadido un agente es un componente de terceros como cualquier otro, y la vulnerabilidad que introduzca te toca gestionarla durante el período de soporte. Las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026; la mayoría de las demás obligaciones, a partir del 11 de diciembre de 2027.
Qué detectan las comprobaciones automáticas y qué se les escapa
Las bases de datos de vulnerabilidades conocen las vulnerabilidades que se han dado a conocer, y una base de datos de paquetes maliciosos conoce los paquetes que alguien ha analizado. El análisis de código fuente encuentra patrones de riesgo conocidos, como una consulta construida con datos introducidos por el usuario, pero no una regla de negocio mal planteada ni una comprobación de permisos ausente que parece código normal. Analizar el código actual en busca de secretos no ve una clave que se subió y luego se borró, porque sigue en el historial de git.
Por eso una rutina de revisión combina varias comprobaciones con una persona que lee el cambio. Cuando una herramienta no informa de nada, anota lo que no podía ver, para que «sin hallazgos» no se lea como «sin riesgo». En el código escrito por IA, las mayores lagunas son los paquetes demasiado nuevos para figurar en ninguna base de datos y los nombres que no existían hasta que un modelo los sugirió.
Disponible hoy en KROMSE
KROMSE comprueba el código y las dependencias que producen tu equipo y sus asistentes de IA; informa de los hallazgos y no modifica el código.
- Contrasta lockfiles y manifiestos con OSV.dev mediante OSV-Scanner, para proyectos npm, Yarn v1, pnpm, Poetry, uv, pip, módulos de Go, Cargo, Maven, Gradle, Composer, Bundler y .NET.
- Marca como críticas las dependencias que figuran en la base de datos OpenSSF Malicious Packages, con la eliminación como única solución.
- Detecta con Gitleaks credenciales subidas al repositorio en el código del commit analizado; los valores de los secretos se enmascaran y nunca se almacenan. No se analiza el historial de git.
- Análisis de código fuente para 11 lenguajes: C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala y Swift.
- Una explicación en lenguaje claro de cada hallazgo y un veredicto de IA por hallazgo, dentro del uso incluido en tu plan.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026 (noviembre)Plugin para agentes de programación. Un plugin para agentes de programación con IA comprobará cada paquete que proponga el agente antes de que entre en el código, incluidos los paquetes que no existen o que se publicaron hace solo unos días.
- Próximamente · T4 2026 (noviembre)Propuestas de corrección con IA, aprobadas por una persona. KROMSE propondrá correcciones para los hallazgos, redactadas con IA y aplicadas solo después de que una persona de tu equipo las apruebe.
- Próximamente · T1 2027Seguridad de agentes y modelos de IA. KROMSE generará una lista de materiales de IA (AI bill of materials), revisará las herramientas y los permisos que pueden usar tus agentes y detectará archivos de modelo inseguros.
Preguntas frecuentes
¿El código generado por IA es menos seguro que el escrito por personas?
Depende del modelo, de la instrucción y de la revisión. El código generado por IA tiende a repetir lo que era habitual en el código existente, incluidas versiones obsoletas y patrones inseguros, y llega en mayor volumen. Revísalo como el código de un colaborador desconocido: las mismas pruebas, los mismos análisis y la aprobación de una persona antes de fusionarlo.
¿Qué es el slopsquatting?
El slopsquatting consiste en registrar un paquete con un nombre que los modelos de IA tienden a inventar, de modo que quien instale ese nombre inventado reciba el código del atacante. Es una variante del typosquatting. Las defensas son verificar que cada dependencia nueva existe y es la prevista, fijar las versiones en un lockfile incluido en el repositorio y contrastar los paquetes con bases de datos de paquetes maliciosos.
¿Cómo evito que un agente de IA instale paquetes maliciosos?
Limita lo que puede hacer el agente: nada de instalaciones fuera de un entorno aislado (sandbox), instalaciones solo desde una lista aprobada o un proxy de registro interno, y ninguna fusión sin revisión humana. Contrasta las dependencias nuevas con datos de vulnerabilidades y de paquetes maliciosos en CI, y fija las versiones en un lockfile incluido en el repositorio.
¿Puede KROMSE decirme si un paquete sugerido por una IA no existe?
Hoy no. KROMSE contrasta las dependencias de tus lockfiles y manifiestos con OSV.dev, incluidos los informes de OpenSSF Malicious Packages, así que un paquete malicioso ya documentado se marca como crítico. La detección de nombres de paquetes inventados y de paquetes publicados hace solo unos días está en la hoja de ruta, mediante un plugin para agentes de programación.
¿KROMSE corrige el código generado por IA?
No. KROMSE informa de los hallazgos, los explica en lenguaje claro y puede dar un veredicto de IA por hallazgo dentro del uso incluido en tu plan. No edita código ni abre pull requests, y su aplicación de GitHub tiene acceso de solo lectura. Las correcciones propuestas por IA que aprueba una persona están en la hoja de ruta.
¿Los secretos del código generado por IA aparecen en un análisis de KROMSE?
KROMSE ejecuta Gitleaks sobre el código del commit que analiza e informa de las credenciales subidas al repositorio, con los valores de los secretos enmascarados y sin almacenarlos nunca. No analiza el historial de git, así que no encuentra una clave que se subió y luego se borró. Rota cualquier clave que haya quedado expuesta, siga o no en el código.
Guías relacionadas
Fuentes
- Spracklen et al., «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», USENIX Security 2025
- Grupo de trabajo de buenas prácticas de OpenSSF: «Security-Focused Guide for AI Code Assistant Instructions»
- Repositorio OpenSSF Malicious Packages
- OpenSSF: detección de paquetes maliciosos con la API de OSV
- Reglamento (UE) 2024/2847 (Reglamento de Ciberresiliencia)