“Eres lo que comes” se aplica en sentido figurado a los humanos. Pero se aplica literalmente a los grandes modelos de lenguaje (LLM) que impulsan las herramientas de inteligencia artificial generativa (GenAI). Realmente son lo que comen.
Si los conjuntos de datos masivos que reciben los LLM desde sitios web, foros, repositorios y proyectos de código abierto están envenenados con sesgos, errores, propaganda y otra basura, eso es lo que regurgitarán. Si los conjuntos de datos son completos, precisos y no politizados, es mucho más probable que obtenga resultados útiles y confiables. No está garantizado, pero es más probable.
Aquellos que utilizan cada vez más herramientas GenAI para escribir código de software deben tener esto en cuenta. Sí, esas herramientas aportan una serie de beneficios seductores al desarrollo de software. Son increíblemente rápidos; no necesitan dormir, tomar café ni vacaciones; no exigen salario ni prestaciones; y no intentan sindicalizarse.
De ahí la prisa por emplearlos. El código creado por GenAI, de uso común durante menos de 18 meses, es ahora el cuarto componente principal del software. Los otros tres, que existen desde hace décadas, son el código que usted escribió (propietario), el código que compró (comercial) y el software de código abierto (OSS) (en su mayoría gratuito).
Pero ninguno de ellos era ni es perfecto; después de todo, son creados por humanos imperfectos. Entonces, el código GenAI, que crea código a partir de la ingesta de lo que ya existe, tampoco es perfecto. Numerosos expertos en software han descrito Herramientas GenAI como tener la capacidad de un desarrollador junior que ha sido capacitado y es capaz de producir código útil, pero que necesita mucha supervisión y supervisión. En otras palabras, se debe probar rigurosamente para detectar vulnerabilidades y posibles conflictos de licencia, como cualquier otro código.
Estudios como el anual “Seguridad de código abierto y análisis de riesgos”(OSSRA) informe del Centro de Investigación de Ciberseguridad Synopsys documento que necesita. De 1.703 bases de código escaneadas para el informe OSSRA
- El 96% contenía OSS, el 84% tenía al menos una vulnerabilidad y el 48% contenía al menos una vulnerabilidad de alto riesgo.
- El 54% tenía conflictos de licencia y el 31% contenía OSS sin licencia.
- El 89% contenía OSS con más de cuatro años de antigüedad y el 91% contenía OSS que no se había actualizado durante dos años o más.
Obviamente, el código creado a partir de esas y otras bases de código existentes traerá los mismos problemas a lo que generan las herramientas GenAI. Eso no significa que las organizaciones no deban usar GenAI, como tampoco significa que no deban usar OSS. Simplemente significa que deben someter el código al mismo régimen de pruebas que los demás.
Ese es el mensaje de la firma de analistas Gartner en su informe de diciembre de 2023 “Predice 2024: IA y ciberseguridad: convertir la disrupción en una oportunidad”. Pronostica la creciente adopción de GenAI, pero ofrece algunas advertencias. Entre ellos, desacredita enérgicamente la idea de que GenAI eliminará la necesidad de realizar pruebas, señalando que “hasta 2025, la IA generativa provocará un aumento de los recursos de ciberseguridad necesarios para protegerla, provocando un gasto incremental de más del 15% en seguridad de aplicaciones y datos. .”
Esto tiene sentido ya que una cosa que no es discutible es que las herramientas GenAI son rápidas. Pueden producir mucho más código que los humanos. Pero a menos que todo el conjunto de datos introducido en el LLM utilizado para crear su herramienta GenAI sea perfecto (no lo es), debe probar su seguridad, calidad y confiabilidad, junto con el cumplimiento de los requisitos de licencia de OSS.
No solo eso, las herramientas GenAI también pueden ser «envenenadas» cuando piratas informáticos criminales inyectan muestras de códigos maliciosos en los datos de capacitación suministrados a un LLM. Eso puede llevar a la herramienta a generar código infectado con malware.
Por eso las pruebas son cruciales. Y los tres métodos esenciales de prueba de software (análisis estático, análisis dinámico y análisis de composición de software (SCA)) deberían ser obligatorios para garantizar la seguridad y la calidad del software, cualquiera que sea su fuente.
De manera significativa, las pruebas necesarias para el código GenAI son paralelas a las del OSS. Con el código fuente abierto, es fundamental conocer su procedencia: quién lo creó, quién lo mantiene (o no), qué otros componentes de software necesita para funcionar (dependencias), cualquier vulnerabilidad conocida en él y qué disposiciones de licencia rigen su uso. Una herramienta SCA ayuda a encontrar esa información.
Esta es también la razón por la que una lista de materiales de software (SBOM, por sus siglas en inglés), un inventario de toda la cadena de suministro de un producto de software, se ha vuelto esencial para utilizar OSS de manera segura. Un SBOM es igualmente esencial para utilizar las herramientas GenAI de forma segura.
Es una versión del mantra “confía pero verifica” del presidente Reagan. Excepto en este caso, no confíes hasta que lo verifiques. Esta es una advertencia importante para los programadores, quienes pueden tener una falsa sensación de seguridad gracias a GenAI. Ya hay investigaciones que muestran que es más probable que los desarrolladores acepten código no seguro y de baja calidad si proviene de una herramienta GenAI que si su vecino se lo diera o lo encontraran en Stack Overflow.
Como dijo Jason Schmitt, director general de Synopsys Software Integrity Group, el origen del código creado con GenAI «introduce nuevos riesgos e incertidumbre en la cadena de suministro de software». Dado que provino de LLM capacitados con grandes conjuntos de datos, “¿Eso me abre a riesgos que realmente no puedo entender? La fuente de eso [code] Ahora importa”, dijo.
Así que no le temamos a la GenAI, pero no nos cieguemos ante sus límites ni sus riesgos. Úselo para tareas de codificación rutinarias y repetitivas, pero deje los segmentos complejos y personalizados de una aplicación a los humanos. Y pruébalo con el mismo rigor que necesita cualquier otro código de software.
Recuerde, proviene de otro software. Para más información Para saber cómo Synopsys puede ayudarle a generar confianza en su software, visite www.synopsys.com/software.