Riesgos del modelo, los datos y la cadena de suministro

Una aplicación basada en un LLM se construye a partir de muchos componentes de terceros: modelos base, ajustes finos, conjuntos de datos, embeddings, plugins y dependencias de software comunes. Cada eslabón es un punto en el que un atacante puede comprometer el sistema.

A diferencia del software tradicional, los artefactos de ML suelen ser binarios opacos de gran tamaño descargados de repositorios públicos con una procedencia poco fiable. Un archivo de pesos envenenado o un conjunto de datos con una puerta trasera es difícil de detectar mediante inspección.

Proteger el pipeline significa hacer un seguimiento de cada componente y verificarlo desde su origen hasta producción.

El envenenamiento de datos manipula los datos de entrenamiento o de ajuste fino para corromper el modelo resultante. Un atacante que pueda aportar incluso una pequeña fracción de las muestras de entrenamiento puede modificar el comportamiento de forma medible.

• Ataques contra la disponibilidad: degradan la precisión general.
• Ataques dirigidos: provocan clasificaciones erróneas específicas.
• Ataques de puerta trasera: implantan un activador oculto (consulte la escena siguiente).

Los datos extraídos de la web y los documentos RAG aportados por usuarios son puntos de entrada habituales para el envenenamiento porque son voluminosos y se revisan poco.

Una puerta trasera es un ataque de envenenamiento que hace que el modelo se comporte con normalidad, excepto cuando aparece un activador secreto en la entrada. El activador podría ser una frase poco frecuente, una secuencia de tokens o un patrón de marca de agua.

Ejemplo: un modelo de finalización de código ajustado con datos envenenados se comporta correctamente hasta que aparece un comentario mágico; entonces genera código inseguro. Las puertas traseras son sigilosas porque los benchmarks estándar parecen limpios.

Defensas: utilice únicamente proveedores de modelos confiables y firmados; ejecute análisis de detección de activadores y anomalías; realice el ajuste fino con datos verificados bajo su control.

Los pesos de los modelos no son solo datos; algunos formatos ejecutan código al cargarse. Python pickle (utilizado por archivos .bin y .pt antiguos de PyTorch) puede ejecutar código arbitrario durante la deserialización.

Cargar un modelo serializado con pickle que no sea de confianza equivale a ejecutar un programa que no es de confianza.

• Prefiera safetensors, que almacena solo tensores y no puede ejecutar código.
• Analice o ejecute en un sandbox cualquier archivo pickle que deba cargar.
• Trate los archivos de modelos procedentes de repositorios públicos como binarios no confiables.

Establezca de dónde procede cada artefacto y que no haya sido manipulado.

• Fije las versiones y revisiones exactas de los modelos y conjuntos de datos; nunca utilice latest.
• Verifique las sumas de comprobación o los hashes con un valor de referencia fiable.
• Prefiera artefactos firmados; verifique las firmas cuando el editor las proporcione.
• Mantenga una ML-BOM (lista de materiales) que enumere los modelos, los conjuntos de datos y sus fuentes.

Los modelos pueden memorizar y reproducir posteriormente partes de sus datos de entrenamiento, incluidos secretos, PII o texto protegido por derechos de autor. Los atacantes utilizan ataques de extracción para conseguir que revelen este contenido.

• Elimine la PII y los secretos de los corpus de entrenamiento y de ajuste fino.
• Aplique la deduplicación; la memorización se correlaciona con la repetición de muestras.
• Considere técnicas de privacidad diferencial para conjuntos de datos sensibles.
• Pruebe los modelos con sondas de extracción antes de publicarlos.

Dos ataques de privacidad tienen como objetivo los modelos desplegados:

• Inferencia de pertenencia: determinar si un registro concreto formaba parte del conjunto de entrenamiento. Esto puede constituir por sí mismo una vulneración de la privacidad (por ejemplo, en un conjunto de datos médicos).
• Inversión del modelo: reconstruir entradas de entrenamiento representativas a partir del comportamiento del modelo o de sus embeddings.

Mitigue estos riesgos limitando la exposición de las puntuaciones de confianza, añadiendo regularización o privacidad diferencial y restringiendo el acceso sin restricciones a consultas de modelos de alto valor.

Los sistemas RAG almacenan los embeddings de los documentos en una base de datos vectorial. Estos conllevan sus propios riesgos:

• Inversión de embeddings: los embeddings pueden filtrar suficiente información como para reconstruir parcialmente el texto de origen, por lo que son datos sensibles.
• Filtración entre tenants: la recuperación sin controles de acceso puede mostrar documentos de otro tenant.
• Envenenamiento del índice: un documento malicioso añadido al índice puede secuestrar recuperaciones posteriores (inyección indirecta).

Aplique controles de acceso en el momento de la recuperación y revise los documentos antes de indexarlos.

Además de los modelos, las aplicaciones basadas en LLM dependen de la cadena de suministro de software habitual, así como de plugins y conectores que conceden al modelo nuevas capacidades.

• Un plugin malicioso o comprometido puede leer el contexto y exfiltrar datos.
• Los paquetes de PyPI/npm afectados por typosquatting o secuestrados pueden introducir una puerta trasera en la aplicación.
• Las dependencias transitivas vulnerables amplían la superficie de ataque.

Utilice archivos de bloqueo, analice con herramientas SCA, revise los permisos de los plugins y prefiera fuentes evaluadas y firmadas.

Trate el pipeline de ML como cualquier otra ruta de CI/CD de producción, con controles sólidos:

• Aísle los entornos de entrenamiento y de ajuste fino; restrinja quién puede enviar datos.
• Firme y verifique los artefactos en cada etapa; rechace los que no estén firmados o no coincidan.
• Valide los conjuntos de datos mediante detección de anomalías y comprobaciones de procedencia.
• Supervise continuamente los modelos desplegados para detectar desviaciones y comportamientos inesperados.

Marcos como MITRE ATLAS y NIST AI RMF ayudan a estructurar estos controles.

La seguridad de los modelos, los datos y la cadena de suministro consiste en garantizar la confianza y la verificación durante todo el ciclo de vida:

• Conozca sus fuentes (procedencia, firmas, ML-BOM).
• Trate los pesos y los conjuntos de datos como potencialmente hostiles hasta verificarlos.
• Proteja la privacidad frente a filtraciones, inferencias e inversiones.
• Bloquee las dependencias, los plugins y los almacenes vectoriales.

El punto menos costoso para detener un artefacto envenenado es antes de que llegue a entrar en su pipeline.

Riesgos de los modelos, los datos y la cadena de suministro:

• La cadena de suministro de ML abarca modelos base, ajustes finos, conjuntos de datos, embeddings, plugins y dependencias.
• El envenenamiento y las puertas traseras corrompen el entrenamiento; revise y firme las fuentes de datos.
• Evite los formatos pickle no seguros; prefiera safetensors para los pesos que no sean de confianza.
• Verifique la procedencia mediante versiones, sumas de comprobación, firmas y una ML-BOM.
• Proteja la privacidad frente a la filtración, la inferencia de pertenencia y la inversión; proteja los embeddings y los almacenes vectoriales.
• Bloquee las dependencias y los plugins; proteja el pipeline de extremo a extremo utilizando ATLAS y NIST AI RMF como guías.