Los asistentes de programación aceleran el desarrollo, pero una aplicación que funciona puede seguir exponiendo datos o concediendo permisos indebidos. La seguridad exige comprobar mucho más que el resultado visible.
Una aplicación puede arrancar, responder con rapidez y superar sus pruebas funcionales sin ser segura. Esa diferencia resulta especialmente importante cuando los asistentes de inteligencia artificial permiten generar cambios a una velocidad superior a la capacidad del equipo para revisarlos.
El problema no es exclusivo del código generado por IA. Los desarrolladores humanos también introducen vulnerabilidades. Lo que cambia es la escala: producir más código en menos tiempo aumenta la cantidad de trabajo que debe verificarse.
Qué significa que un código falle una prueba de seguridad
Las evaluaciones de seguridad ayudan a comparar herramientas, pero sus resultados necesitan contexto. No es lo mismo analizar una función aislada que una aplicación completa, ni detectar una debilidad potencial que confirmar una vulnerabilidad explotable.
También importa qué lenguajes se prueban, qué instrucciones recibe el modelo y qué tipos de fallo busca el análisis. Un porcentaje obtenido en un conjunto de ejercicios no describe automáticamente la proporción de aplicaciones reales que están en peligro.
Por eso, afirmar que cierto porcentaje de muestras falla una comprobación no permite concluir que ese mismo porcentaje de programas contiene vulnerabilidades críticas. La gravedad depende del fallo, de su exposición y de las consecuencias que tendría aprovecharlo.
El punto ciego: comprobar que algo funciona no basta
Imagina una aplicación que permite descargar facturas. Una prueba funcional confirma que, al pulsar el botón, aparece el documento solicitado. Todo parece correcto.
Pero queda una pregunta decisiva: ¿puede un usuario cambiar el identificador de la factura y descargar la de otra persona?
Si el servidor no comprueba que el documento pertenece al usuario autorizado, la aplicación puede exponer información aunque su interfaz funcione perfectamente. La función cumple su cometido visible, pero incumple una condición de seguridad esencial.
Un asistente necesita suficiente contexto para implementar esa comprobación. Y el equipo debe verificar que existe, que se aplica en el lugar adecuado y que no puede eludirse.
Los errores conocidos y la lógica del negocio requieren controles distintos
Algunas vulnerabilidades responden a patrones que las herramientas automáticas pueden identificar: ciertas consultas inseguras a bases de datos, usos peligrosos de funciones o credenciales escritas directamente en el código.
Otros problemas dependen de las reglas del producto. Por ejemplo, que un descuento solo pueda utilizarse una vez, que un reembolso no supere el importe pagado o que una persona no pueda aprobar su propia solicitud.
Un analizador no siempre dispone de esa información. Una segunda IA tampoco tiene por qué conocerla si nadie se la proporciona. Para revisar estos casos hace falta definir qué operaciones están permitidas, quién puede realizarlas y qué límites deben respetarse.
Ambas categorías importan. Los atacantes pueden aprovechar tanto errores conocidos como fallos de lógica; que una vulnerabilidad sea sencilla no la convierte en irrelevante.
El análisis estático ayuda, pero no certifica una aplicación
El análisis estático examina el código sin ejecutar la aplicación y busca patrones asociados a problemas. Es una capa útil, aunque puede producir alertas que requieren interpretación y dejar fuera fallos que dependen del comportamiento del sistema.
Las pruebas sobre la aplicación en ejecución aportan otra perspectiva. También deben revisarse las dependencias, la configuración, los permisos y la gestión de secretos.
En conjunto, estos controles permiten detectar problemas diferentes. Ninguno, por separado, garantiza que el software sea seguro.
Cómo incorporar IA sin perder el control de los cambios
La respuesta no consiste en revisar con desconfianza únicamente lo que escribe una máquina. Consiste en aplicar criterios de seguridad a todo el código y ajustar la profundidad de la revisión al riesgo del cambio.
- Definir los requisitos: especificar permisos, datos sensibles y operaciones que nunca deberían permitirse.
- Mantener los cambios manejables: las modificaciones pequeñas y bien explicadas facilitan una revisión efectiva.
- Automatizar comprobaciones: combinar pruebas, análisis de código y revisión de dependencias y secretos.
- Probar los abusos posibles: comprobar qué ocurre al acceder a recursos ajenos, repetir operaciones o alterar parámetros.
- Asignar responsabilidad: quien aprueba un cambio debe entender sus efectos, especialmente en autenticación, pagos o tratamiento de información sensible.
La IA puede ayudar a redactar pruebas y localizar posibles errores. Sin embargo, pedirle que revise su propia propuesta no sustituye una verificación independiente: puede repetir las mismas suposiciones equivocadas.
La mirada de SombraRadio: la velocidad también exige capacidad de revisión
El beneficio de los asistentes de programación no debería medirse únicamente por las líneas que producen o por la rapidez con la que completan una tarea. También importa cuánto trabajo cuesta comprobar, corregir y mantener el resultado.
Si la generación se acelera y la revisión se queda atrás, el equipo acumula cambios que todavía no comprende lo suficiente. La aprobación humana aporta valor cuando implica una revisión real, no cuando se convierte en un trámite.
El código generado por IA debe tratarse como una propuesta que necesita evidencias de funcionamiento y seguridad. Que parezca convincente o supere una demostración no basta para ponerlo en manos de los usuarios.
Sombra Radio · Apoyo de lectores
Ayuda a mantener viva Sombra Radio
Tu aportación voluntaria nos ayuda a seguir publicando sobre IA. Puedes apoyarnos desde 1 € al mes.
