La canalización principal de IA de un proveedor de infraestructura de aprendizaje automático se basaba en una combinación de bibliotecas de código abierto consolidadas y una biblioteca de preprocesamiento de datos más pequeña y especializada llamada dataprep, una utilidad para limpiar y estandarizar las entradas de los datos de entrenamiento. Las tres primeras dependencias (scikit-learn, NumPy, pandas) estaban entre los proyectos de código abierto más examinados del ecosistema de ML, con programas de seguridad activos, una respuesta rápida a las vulnerabilidades y una auditoría continua por parte de la comunidad. Con dataprep la historia era distinta: la mantenía un único desarrollador, su última confirmación de cambios era de ocho meses antes y no tenía proceso de divulgación de seguridad ni historial de auditoría de dependencias. Cuando un investigador de seguridad publicó una prueba de concepto que demostraba que un artefacto de modelo elaborado con fines maliciosos y procesado por dataprep podía ejecutar código arbitrario durante la fase de carga de datos, el proveedor no tenía ningún monitoreo implementado para detectar la divulgación. La vulnerabilidad permaneció en su canalización de IA de producción durante seis meses. El proveedor se enteró cuando el equipo de seguridad de un cliente señaló el aviso público. El programa de seguridad de la IA del proveedor había evaluado el proceso de entrenamiento del modelo, la seguridad de la API de inferencia y la procedencia de los datos de entrenamiento. No había evaluado la postura de seguridad de las bibliotecas que mediaban entre los datos de entrenamiento y el proceso de entrenamiento del modelo.
¿Qué son realmente las dependencias de la cadena de suministro de la IA?
Las dependencias de la cadena de suministro de la IA son las bibliotecas de código abierto, los componentes de modelos preentrenados, las utilidades de procesamiento de datos y los paquetes de marcos de ML que constituyen la pila de software sobre la que se construye un sistema de IA y a través de los cuales los ataques a la cadena de suministro pueden comprometer el sistema de IA sin atacar el propio modelo. Del mismo modo que la seguridad de la cadena de suministro de software reconoce que la seguridad de una aplicación depende de cada biblioteca y dependencia que incluye, la seguridad de la cadena de suministro de la IA reconoce que la integridad de un sistema de IA depende de cada componente de la pila que procesa sus datos de entrenamiento, ejecuta su inferencia o gestiona su implementación.
La dimensión del riesgo de las dependencias específicas de la IA va más allá del riesgo estándar de la cadena de suministro de software en varios aspectos. En primer lugar, las canalizaciones de IA suelen ensamblarse a partir de una mezcla heterogénea de marcos consolidados (TensorFlow, PyTorch, scikit-learn) y utilidades especializadas (herramientas de preprocesamiento de datos, bibliotecas de ingeniería de variables, utilidades de serialización de modelos), en la que las utilidades especializadas pueden tener una postura de seguridad mucho más débil que los marcos emblemáticos. Una organización que centra su programa de seguridad de dependencias en los marcos principales puede pasar por alto el riesgo concentrado en las utilidades especializadas más pequeñas, que reciben menos escrutinio y se mantienen de forma menos activa.
La vulnerabilidad de la serialización de modelos es un riesgo específico y bien documentado de las dependencias de IA. El formato pickle de Python, que muchos marcos de ML usan de forma predeterminada para guardar y cargar modelos, permite la ejecución de código arbitrario cuando se carga un artefacto de modelo malicioso. Las bibliotecas que gestionan la carga de modelos sin controles de deserialización segura crean una vía por la que un atacante de la cadena de suministro capaz de sustituir un artefacto de modelo por uno malicioso en el registro de modelos puede ejecutar código en el entorno de inferencia cuando se carga el modelo. Este ataque no requiere explotar el algoritmo del modelo, solo la capacidad de reemplazar el archivo del modelo serializado por uno malicioso.
La superficie de ataque de las bibliotecas de procesamiento de datos es el segundo riesgo específico. Las bibliotecas que se encargan del preprocesamiento de los datos de entrenamiento (leer, analizar, transformar y limpiar los datos de entrada) procesan datos no confiables de fuentes potencialmente no confiables. Una vulnerabilidad en una biblioteca de preprocesamiento de datos que se activa con datos de entrada maliciosos crea una vía por la que un atacante de la cadena de suministro capaz de introducir datos de entrenamiento maliciosos puede ejecutar código en el entorno de entrenamiento cuando se procesan esos datos. El vector de ataque son los datos de entrenamiento, no el modelo ni el algoritmo de entrenamiento.
El riesgo de la actualización y el mantenimiento de las dependencias es la dimensión de gobernanza. Las dependencias del ecosistema de ML varían enormemente en su actividad de mantenimiento, sus procesos de divulgación de seguridad y sus plazos de respuesta a vulnerabilidades. Una dependencia mantenida por un único desarrollador sin proceso de divulgación de seguridad no ofrece prácticamente ninguna garantía de seguridad: las vulnerabilidades pueden descubrirse y explotarse mucho antes de que el mantenedor las conozca. El problema de las dependencias transitivas lo amplifica: un marco principal bien mantenido puede incluir dependencias transitivas de utilidades mal mantenidas, lo que crea un riesgo de la cadena de suministro a través de una cadena de dependencias que va más allá de la postura de seguridad del marco principal.
Por qué es importante
Las dependencias de la cadena de suministro de la IA son importantes para la TPRM porque la seguridad del sistema de IA del proveedor está limitada por la seguridad de cada componente de su pila de dependencias, no solo por la arquitectura del modelo y el proceso de entrenamiento. Un proveedor cuyo programa de seguridad de la IA se centra en la capa del modelo y deja sin monitorear la capa de dependencias tiene una postura de seguridad más sólida en las capas que evalúa y desconocida en las que no evalúa.
Dónde se equivocan la mayoría de los equipos
La falla más constante es evaluar la seguridad de la IA en la capa del modelo (proceso de entrenamiento, API de inferencia, procedencia de los datos) sin extender la evaluación a la pila de dependencias sobre la que se construye la canalización de IA. La capa de dependencias es donde se producirán muchos ataques a la cadena de suministro de la IA.
- Seguridad de la IA evaluada en la capa del modelo sin evaluar la capa de dependencias
- Dependencias de utilidades especializadas no evaluadas: solo se atiende a los marcos principales
- Formato de serialización de modelos no evaluado en cuanto a la deserialización segura
- Monitoreo de dependencias ausente: sin proceso para seguir las divulgaciones de vulnerabilidades en las dependencias de IA
- Dependencias con un único mantenedor no identificadas como de riesgo elevado
Cómo se ve una buena práctica
Los programas maduros de seguridad de la cadena de suministro de la IA mantienen un inventario completo de las dependencias de IA, incluidas las utilidades especializadas y las dependencias transitivas; monitorean las divulgaciones de vulnerabilidades en todas las dependencias; evalúan los formatos de serialización de modelos para garantizar una deserialización segura; y aplican estándares de mantenimiento escalonados por riesgo que señalan como de riesgo elevado las dependencias con un único mantenedor o inactivas.
- Inventario completo de dependencias de IA: todas las bibliotecas, incluidas las utilidades especializadas y las dependencias transitivas
- Monitoreo continuo de vulnerabilidades: todas las dependencias de IA incluidas en el monitoreo de divulgaciones de vulnerabilidades
- Aplicación de la deserialización segura: carga de modelos con formatos seguros en lugar de pickle siempre que sea posible
- Evaluación del estado de las dependencias: actividad de los mantenedores, proceso de divulgación de seguridad, última versión publicada
- SBOM automatizado para canalizaciones de IA: lista de materiales de software que incluya las dependencias de ML
Herramientas
Seguridad de las dependencias: Snyk, Dependabot, OWASP Dependency-Check para el escaneo de bibliotecas de IA
Las herramientas de análisis de composición de software pueden aplicarse tanto a las dependencias de las canalizaciones de IA como a las de las aplicaciones. Para los profesionales de TPRM, preguntar si las dependencias de la canalización de IA del proveedor están incluidas en su programa de escaneo de SCA, en concreto si las utilidades especializadas de ML están cubiertas junto con los marcos principales, ofrece una pregunta concreta sobre la seguridad de las dependencias de IA.
Carga segura de modelos: registro de modelos de MLflow con verificación de integridad, ModelScan para la seguridad de pickle
ModelScan y herramientas similares escanean los artefactos de modelos serializados en busca de cargas maliciosas antes de cargarlos. Para los profesionales de TPRM, preguntar si el proceso de carga de modelos del proveedor usa una deserialización segura o escanea los artefactos de modelos antes de cargarlos ofrece una pregunta concreta sobre la seguridad de la serialización.
Desafíos de gobernanza
El desafío de gobernanza de las dependencias de la cadena de suministro de la IA es el problema de la heterogeneidad del ecosistema. El ecosistema de código abierto de AI/ML contiene miles de paquetes especializados con una calidad de mantenimiento muy variable. Un programa integral de seguridad de las dependencias para las canalizaciones de IA requiere herramientas de evaluación que abarquen todo el ecosistema, no solo los marcos emblemáticos.
- Incluya las dependencias de la canalización de IA en el escaneo de SCA
- Evalúe el formato de serialización de modelos: evite pickle cuando existan alternativas seguras
- Monitoree el estado de las dependencias: actividad de los mantenedores y proceso de divulgación de seguridad
- Solicite el SBOM de la canalización de IA: inventario completo de dependencias
- Señale las dependencias con un único mantenedor como sujetas a revisión adicional
Si usted forma parte de un equipo pequeño
Solicite a su proveedor de IA de mayor riesgo el SBOM de su canalización de IA: la lista completa de paquetes de Python y sus versiones en su pila de dependencias de ML. Luego compruebe dos cosas: primera, ¿se monitorean todos los paquetes en busca de divulgaciones de vulnerabilidades mediante una herramienta como Snyk o Dependabot? Segunda, para cualquier paquete con menos de tres colaboradores activos o sin confirmaciones de cambios en seis meses, ¿cuál es el proceso del proveedor para evaluar el riesgo de seguridad? Esas dos preguntas revelan si la capa de dependencias ha recibido una atención de seguridad equivalente a la de la capa del modelo.
- Solicite el SBOM de la canalización de IA: lista completa de dependencias de ML
- Pregunte si todos los paquetes se monitorean en busca de divulgaciones de vulnerabilidades
- Señale los paquetes con un único mantenedor o con inactividad prolongada
- Pregunte por el formato seguro de serialización de modelos
Qué exigir
Pregunte directamente:
"¿Puede proporcionar la lista de materiales de software de su canalización de IA, en concreto todas las dependencias de bibliotecas de ML, incluidas las utilidades especializadas? ¿Y se monitorean todas esas dependencias en busca de divulgaciones de vulnerabilidades mediante una herramienta automatizada de SCA?"
Evidencia que debe esperar
- SBOM de la canalización de IA con todas las dependencias de ML
- Cobertura de la herramienta de SCA para todas las dependencias de IA
- Confirmación del formato de serialización de modelos y de la carga segura
- Evaluación del estado de las dependencias de los paquetes de alto riesgo
A un proveedor que confirma la cobertura de seguridad de la IA se le debe pedir el SBOM de la canalización de IA. La seguridad de la capa del modelo abarca el modelo. La seguridad de la capa de dependencias abarca la pila sobre la que se ejecuta el modelo. Ambas son necesarias.
Cómo demostrarlo
- Registros del SBOM de la canalización de IA
- Cobertura del escaneo de SCA para las dependencias de IA
- Evaluación de la seguridad de la serialización de modelos
- Registros del monitoreo del estado de las dependencias
Conclusión clave
Cuatro bibliotecas. Tres bien auditadas. Una: un único mantenedor, ocho meses de inactividad, ejecución de código arbitrario mediante datos de entrenamiento maliciosos. Seis meses en la canalización de producción antes de descubrirse. El programa de seguridad de la IA abarcaba exhaustivamente la capa del modelo. La capa de dependencias, la pila sobre la que se ejecuta el proceso de entrenamiento del modelo, no estaba incluida en el alcance. Los ataques a la cadena de suministro de la IA no requieren comprometer el algoritmo del modelo. Requieren encontrar el eslabón más débil de la pila de dependencias que procesa los datos de entrenamiento o carga los artefactos del modelo. El SBOM de la canalización de IA es el inventario. El escaneo de SCA es el monitoreo. La deserialización segura es el control de arquitectura. Juntos abarcan la capa de dependencias que pasa por alto la evaluación de la capa del modelo.