Feature Mientras tienen prisa por comprender, construir y distribuir productos de inteligencia artificial, se insta a los desarrolladores y científicos de datos a que sean conscientes de la seguridad y no sean víctimas de ataques a la cadena de suministro.

Hay innumerables modelos, bibliotecas, algoritmos, herramientas prediseñadas y paquetes con los que jugar, y el progreso es implacable. El resultado de estos sistemas es quizás otra historia, aunque es innegable que siempre hay algo nuevo con lo que jugar, al menos.

No importa toda la emoción, el revuelo, la curiosidad y el miedo a perderse algo, no se puede olvidar la seguridad. Si esto no te sorprende, fantástico. Pero un recordatorio es útil aquí, especialmente porque la tecnología de aprendizaje automático tiende a ser elaborada por científicos en lugar de ingenieros, al menos en la fase de desarrollo, y aunque esas personas conocen cosas como arquitecturas de redes neuronales, cuantificación y siguientes... técnicas de capacitación genéricas, es comprensible que la seguridad de la información no sea su fuerte.

Elaborar un proyecto de IA no es muy diferente de construir cualquier otro software. Por lo general, unirá bibliotecas, paquetes, datos de entrenamiento, modelos y código fuente personalizado para realizar tareas de inferencia. Los componentes de código disponibles en repositorios públicos pueden contener puertas traseras ocultas o filtradores de datos, y los modelos y conjuntos de datos prediseñados pueden envenenarse para provocar que las aplicaciones se comporten inesperadamente de manera inapropiada.

De hecho, algunos modelos pueden contener malware que es ejecutado si su contenido no se deserializa de forma segura. La seguridad de los complementos ChatGPT también ha ven abajo un escrutinio minucioso.

En otras palabras, los ataques a la cadena de suministro que hemos visto en el mundo del desarrollo de software pueden ocurrir en el terreno de la IA. Los paquetes defectuosos podrían comprometer las estaciones de trabajo de los desarrolladores, lo que provocaría intrusiones dañinas en las redes corporativas, y los modelos y conjuntos de datos de entrenamiento manipulados podrían hacer que las aplicaciones clasifiquen cosas incorrectamente, ofendan a los usuarios, etc. Las bibliotecas y modelos con puertas traseras o con malware, si se incorporan al software enviado, también podrían dejar a los usuarios de esas aplicaciones expuestos a ataques.

Resolverán un problema matemático interesante y luego lo implementarán y listo. No está probado con lápiz, no hay equipo rojo de IA

En respuesta, están surgiendo nuevas empresas de ciberseguridad e inteligencia artificial específicamente para abordar esta amenaza; Sin duda, los jugadores establecidos también están atentos a esto, o eso esperamos. Los proyectos de aprendizaje automático deben ser auditados e inspeccionados, probados y evaluados en cuanto a seguridad.

“[La IA] ha surgido del mundo académico. En gran medida han sido proyectos de investigación en la universidad o han sido pequeños proyectos de desarrollo de software que han sido derivados en gran medida por académicos o grandes empresas, y simplemente no tienen la seguridad interna”, Tom Bonner, vicepresidente de investigación de HiddenLayer, uno dicha startup centrada en la seguridad, dijo El registro.

“Resolverán un problema matemático interesante usando software y luego lo implementarán y listo. No está probado, no hay equipos rojos de IA, evaluaciones de riesgos ni un ciclo de vida de desarrollo seguro. De repente, la IA y el aprendizaje automático realmente han despegado y todo el mundo está buscando participar en ello. Todos van y recogen todos los paquetes de software comunes que han surgido del mundo académico y, he aquí, están llenos de vulnerabilidades, llenos de agujeros”.

La cadena de suministro de IA tiene numerosos puntos de entrada para los delincuentes, que pueden utilizar cosas como Typosquatting para engañar a los desarrolladores para que utilicen copias maliciosas de bibliotecas que de otro modo serían legítimas, permitiendo a los delincuentes robar datos confidenciales y credenciales corporativas, secuestrar servidores que ejecutan el código y más, se argumenta. Las defensas de la cadena de suministro de software también deberían aplicarse al desarrollo de sistemas de aprendizaje automático.

"Si piensas en un gráfico circular de cómo te van a hackear una vez que abras un departamento de IA en tu empresa u organización", dijo Dan McInerney, investigador principal de seguridad de IA en Protect AI, El registro, “una pequeña fracción de ese pastel serán ataques de entrada de modelos, que es de lo que todo el mundo habla. Y una parte gigante atacará la cadena de suministro: las herramientas que se utilizan para construir el modelo”.

Los ataques de entrada son formas interesantes que la gente puede romper el software de IA al usarlo.

Para ilustrar el peligro potencial, HiddenLayer la otra semana destacó lo que cree firmemente es un problema de seguridad con un servicio en línea proporcionado por Hugging Face que convierte modelos en el inseguro formato Pickle al más seguro. tensores de seguridad, también desarrollado por Hugging Face.

Los modelos Pickle pueden contener malware y otros códigos arbitrarios que podrían ejecutarse silenciosa e inesperadamente cuando se deserializan, lo cual no es nada bueno. Safetensors se creó como una alternativa más segura: los modelos que utilizan ese formato no deberían terminar ejecutando código incrustado cuando se deserializan. Para aquellos que no lo saben, Hugging Face alberga cientos de miles de modelos de redes neuronales, conjuntos de datos y fragmentos de código que los desarrolladores pueden descargar y usar con solo unos pocos clics o comandos.

El convertidor Safetensors se ejecuta en la infraestructura de Hugging Face y se le puede indicar que convierta un modelo PyTorch Pickle alojado en Hugging Face en una copia en formato Safetensors. Pero ese proceso de conversión en línea en sí mismo es vulnerable a la ejecución de código arbitrario, según HiddenLayer.

Los investigadores de HiddenLayer dijeron que descubrieron que podían enviar una solicitud de conversión para un modelo Pickle malicioso que contuviera código arbitrario, y durante el proceso de transformación, ese código se ejecutaría en los sistemas de Hugging Face, permitiendo que alguien comenzara a jugar con el robot convertidor y sus usuarios. Si un usuario convierte un modelo malicioso, su token Hugging Face podría ser filtrado por el código oculto y "podríamos, de hecho, robar su token Hugging Face, comprometer su repositorio y ver todos los repositorios, conjuntos de datos y modelos privados que tiene ese usuario". acceso a”, argumentó HiddenLayer.

Además, se nos dice que se puede acceder a las credenciales del robot convertidor y filtrarlas mediante un código escondido en un modelo Pickle, lo que permite a alguien hacerse pasar por el robot y abrir solicitudes de extracción para cambios en otros repositorios. Esos cambios podrían introducir contenido malicioso si se aceptan. Le hemos pedido a Hugging Face una respuesta a los hallazgos de HiddenLayer.

"Irónicamente, el servicio de conversión a Safetensors era terriblemente inseguro", nos dijo Bonner de HiddenLayer. “Dado el nivel de acceso que tenía el robot de conversión a los repositorios, en realidad era posible robar el token que utilizan para enviar cambios a través de otros repositorios.

“Entonces, en teoría, un atacante podría haber enviado cualquier cambio a cualquier repositorio y hacer que pareciera que proviene de Hugging Face, y una actualización de seguridad podría haberlo engañado para que lo aceptara. La gente simplemente habría tenido modelos con puertas traseras o modelos inseguros en sus repositorios y no lo sabría”.

Esto es más que una amenaza teórica: Devops compra JFrog dijo que encontró Código malicioso escondido en 100 modelos alojados en Hugging Face.

En verdad, existen varias formas de ocultar cargas dañinas de código en modelos que, según el formato del archivo, se ejecutan cuando se cargan y analizan las redes neuronales, lo que permite a los malhechores obtener acceso a las máquinas de las personas. Los modelos PyTorch y Tensorflow Keras "representan el mayor riesgo potencial de ejecutar código malicioso porque son tipos de modelos populares con técnicas de ejecución de código conocidas que se han publicado", señaló JFrog.

Recomendaciones inseguras

Los programadores que utilizan asistentes que sugieren código para desarrollar aplicaciones también deben tener cuidado, advirtió Bonner, o podrían terminar incorporando código inseguro. GitHub Copilot, por ejemplo, fue entrenado en repositorios de código abierto, y al menos 350,000 de ellos son potencialmente vulnerables a un ataque. viejo problema de seguridad involucrando archivos Python y tar.

Python archivo tar El módulo, como su nombre indica, ayuda a los programas a descomprimir archivos tar. Es posible crear un .tar de modo que cuando el módulo Python extraiga un archivo dentro del archivo, intente sobrescribir un archivo arbitrario en el sistema de archivos del usuario. Esto puede explotarse para eliminar configuraciones, reemplazar scripts y causar otras travesuras.

La falla fue detectada en 2007 y destacó nuevamente en 2022, lo que llevó a la gente a comenzar a parchear proyectos para evitar esta explotación. Es posible que esas actualizaciones de seguridad no hayan llegado a los conjuntos de datos utilizados para entrenar grandes modelos de lenguaje para programar, se lamentó Bonner. "Entonces, si le pides a un LLM que vaya y descomprima un archivo tar ahora mismo, probablemente te devolverá el código vulnerable [antiguo]".

Bonner instó a la comunidad de IA a comenzar a implementar prácticas de seguridad de la cadena de suministro, como exigir a los desarrolladores que demuestren digitalmente que son quienes dicen ser al realizar cambios en los repositorios de códigos públicos, lo que tranquilizaría a la gente de que las nuevas versiones de las cosas fueron producidas por desarrolladores legítimos. y no fueron cambios maliciosos. Eso requeriría que los desarrolladores protejan todo lo que utilicen para autenticarse para que nadie más pueda hacerse pasar por ellos.

Y todos los desarrolladores, grandes y pequeños, deben realizar evaluaciones de seguridad e inspeccionar las herramientas que utilizan, y realizar pruebas de penetración de su software antes de implementarlo.

Intentar reforzar la seguridad en la cadena de suministro de IA es complicado, y con tantas herramientas y modelos en desarrollo y lanzamiento, es difícil mantenerse al día.

McInerney, de Protect AI, destacó que “ese es el estado en el que nos encontramos ahora. Hay mucha fruta madura que existe por todas partes. Simplemente no hay suficiente personal para verlo todo porque todo avanza muy rápido”. ®

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://go.theregister.com/feed/www.theregister.com/2024/03/17/ai_supply_chain/