Home Tecnología Siete pasos para lograr visibilidad en la cadena de suministro de IA,...

Siete pasos para lograr visibilidad en la cadena de suministro de IA, antes de que una infracción fuerce el problema

16
0

Cuatro de cada 10 aplicaciones empresariales incluirán agentes de IA para tareas específicas este año. Sin embargo, la investigación del Informe Índice 2025 de la Universidad de Stanford muestra que una mera 6% de las organizaciones contar con una estrategia avanzada de seguridad de IA.

Palo Alto Networks predice que el año 2026 traerá las primeras demandas importantes que responsabilizan personalmente a los ejecutivos por acciones deshonestas de IA. Muchas organizaciones están lidiando con cómo contener la naturaleza acelerada e impredecible de las amenazas de la IA. La gobernanza no responde a soluciones rápidas como mayores presupuestos o más private.

Existe una brecha de visibilidad en lo que respecta a cómo, dónde, cuándo y a través de qué flujos de trabajo y herramientas se utilizan o modifican los LLM. Un CISO le dijo a VentureBeat que los SBOM modelo son el salvaje oeste de la gobernanza precise. Sin visibilidad de qué modelos se ejecutan y dónde, la seguridad de la IA se convierte en conjeturas y la respuesta a incidentes se vuelve imposible.

Durante los últimos años, el gobierno de EE. UU. ha seguido una política de exigir SBOM para todo el software program adquirido para su uso. Los modelos de IA los necesitan más, y la falta de mejoras consistentes en esta área es uno de los riesgos más importantes de la IA.

La brecha de visibilidad es la vulnerabilidad.

Harness encuestó a 500 profesionales de la seguridad en Estados Unidos, Reino Unido, Francia y Alemania. Los hallazgos deberían alarmar a todos los CISO: el 62% de sus pares no tienen forma de saber dónde se utilizan los LLM en su organización. Es necesario un mayor rigor y transparencia a nivel de SBOM para mejorar la trazabilidad del modelo, el uso de datos, los puntos de integración y los patrones de uso por departamento.

Las empresas siguen experimentando niveles cada vez mayores de inyección inmediata (76%), código LLM susceptible (66%) y jailbreak (65%). Estos se encuentran entre los riesgos y métodos de ataque más letales que utilizan los adversarios para extraer todo lo que puedan del modelado de IA y los esfuerzos de LLM de una organización. A pesar de gastar millones en software program de ciberseguridad, muchas organizaciones no ven los esfuerzos de intrusión de estos adversarios, ya que están encubiertos con técnicas de supervivencia y técnicas de ataque comparables que no pueden ser rastreadas por los sistemas perimetrales heredados.

“La IA en la sombra se ha convertido en el nuevo punto ciego empresarial”, dijo Adam Arellano, CTO de campo en Aprovechar. “Las herramientas de seguridad tradicionales se crearon para código estático y sistemas predecibles, no para modelos de aprendizaje adaptables que evolucionan a diario”.

Informe de IBM sobre el costo de una vulneración de datos en 2025 cuantifica el costo y descubre que el 13% de las organizaciones informaron violaciones de modelos o aplicaciones de IA el año pasado. De los vulnerados, el 97% carecía de controles de acceso mediante IA. Una de cada cinco infracciones denunciadas se debió a IA en la sombra o uso no autorizado de IA. Los incidentes de IA en la sombra cuestan 670.000 dólares más que sus contrapartes de intrusión de referencia comparables. Cuando nadie sabe qué modelos se ejecutan y dónde, la respuesta a incidentes no puede evaluar el impacto.

Por qué los SBOM se detienen en el archivo del modelo

Orden Ejecutiva 14028 (2021) y el Memorando M-22-18 de la OMB (2022) requieren SBOM de software program para proveedores federales. Marco de gestión de riesgos de IA del NISTlanzado en 2023, exige explícitamente AI-BOM como parte de su función “Mapa”, reconociendo que los SBOM de software program tradicionales no capturan los riesgos específicos del modelo. Pero las dependencias de software program se resuelven en el momento de la compilación y permanecen fijas.

Por el contrario, las dependencias del modelo se resuelven en tiempo de ejecución, a menudo obteniendo pesos de los puntos finales HTTP durante la inicialización y mutan continuamente a través del reentrenamiento, la corrección de deriva y los bucles de retroalimentación. Adaptadores LoRA modifique los pesos sin management de versiones, lo que hace imposible rastrear qué versión del modelo se está ejecutando realmente en producción.

He aquí por qué esto es importante para los equipos de seguridad: Cuando los modelos de IA se guardan en formato de pepinillocargarlos es como abrir un archivo adjunto de correo electrónico que ejecuta código en su computadora, excepto que estos archivos, que actúan como archivos adjuntos, son confiables de forma predeterminada en los sistemas de producción.

Un modelo de PyTorch guardado de esta manera es un código de bytes de Python serializado que debe ser deserializado y ejecutado para cargar. Cuando se ejecuta torch.load(), Los códigos de operación de pickle se ejecutan secuencialmente.. Cualquier invocable incrustado en la secuencia se activa. Estos comúnmente incluyen os.system(), conexiones de crimson y shells inversos.

Tensores segurosun formato alternativo que almacena solo datos tensoriales numéricos sin código ejecutableaborda los riesgos inherentes del pepinillo. Aún así, la migración significa reescribir funciones de carga, revalidar la precisión del modelo y potencialmente perder el acceso a modelos heredados donde el código de entrenamiento authentic ya no existe. Ese es uno de los principales factores que frena la adopción. En muchas organizaciones, no se trata sólo de una política, sino de un esfuerzo de ingeniería.

Los archivos de modelo no son artefactos inertes: son puntos de entrada ejecutables a la cadena de suministro.

Los estándares existen y han estado vigentes durante años, pero su adopción continúa retrasada. CiclónDX 1.6 agregado ML-BOM soporte en abril de 2024. SPDX 3.0, lanzado en abril de 2024, incluía perfiles de IA. Las ML-BOM complementan, pero no reemplazan, los marcos de documentación como las tarjetas modelo y las hojas de datos para conjuntos de datos, que se centran en los atributos de rendimiento y la ética de los datos de capacitación en lugar de hacer de la procedencia de la cadena de suministro una prioridad. VentureBeat continúa viendo que la adopción está rezagada y la rapidez con la que esta área se está convirtiendo en una amenaza existencial para los modelos y los LLM.

Una encuesta de Lineaje de junio de 2025 descubrió que el 48% de los profesionales de seguridad admiten que sus organizaciones se están quedando atrás en los requisitos de SBOM. La adopción de ML-BOM es significativamente menor.

En pocas palabras: Las herramientas existen. Lo que falta es urgencia operativa.

Las AI-BOM permiten la respuesta, no la prevención

Las AI-BOM son análisis forenses, no cortafuegos. Cuando ReversingLabs descubrió modelos nullifAI comprometidos, la procedencia documentada habría identificado inmediatamente qué organizaciones los descargaron. Es muy valioso saberlo para responder a incidentes, aunque es prácticamente inútil para la prevención. El presupuesto para proteger las listas de materiales AI debe tener en cuenta ese issue.

El ecosistema de herramientas ML-BOM está madurando rápidamente, pero aún no es donde se encuentran los SBOM de software program. Herramientas como Syft y Trivy generan inventarios de software program completos en minutos. Las herramientas ML-BOM se encuentran más temprano en esa curva. Los proveedores ofrecen soluciones, pero la integración y la automatización aún requieren pasos adicionales y más esfuerzo. Las organizaciones que comienzan ahora pueden necesitar procesos manuales para llenar los vacíos.

Las AI-BOM no detendrán el envenenamiento del modelo, ya que esto ocurre durante el entrenamiento, a menudo antes de que una organización descargue el modelo. Tampoco bloquearán la inyección rápida, ya que ese ataque explota lo que hace el modelo, no su procedencia. La prevención requiere defensas en tiempo de ejecución que incluyan validación de entradas, cortafuegos rápidos, filtrado de salidas y validación de llamadas a herramientas para sistemas agentes. Las AI-BOM son herramientas de visibilidad y cumplimiento. Valioso, pero no sustituto de la seguridad en tiempo de ejecución. Los CISO y los líderes de seguridad dependen cada vez más de ambos.

La superficie de ataque sigue expandiéndose

Informe de la cadena de suministro de software 2025 de JFrog documentó más de 1 millón de nuevos modelos que llegarán a Hugging Face solo en 2024, con un Aumento de 6,5 veces de modelos maliciosos. Para abril de 2025, proteger los escaneos de AI de 4,47 millones de versiones de modelos encontró 352.000 problemas sospechosos o inseguros en 51.700 modelos. La superficie de ataque se expandió más rápido que la capacidad de cualquiera para monitorearla.

A principios de 2025, ReversingLabs descubrió modelos maliciosos usando “nullifAI” Técnicas de evasión que eludieron la detección de Picklescan. Hugging Face respondió en 24 horas, eliminando los modelos y actualizando Picklescan para detectar técnicas de evasión similares, lo que demuestra que la seguridad de la plataforma está mejorando, incluso a medida que aumenta la sofisticación de los atacantes.

“Muchas organizaciones están adoptando con entusiasmo modelos públicos de aprendizaje automático para impulsar una rápida innovación”. dicho Yoav Landman, director de tecnología y cofundador de JFrog. “Sin embargo, más de un tercio todavía depende de esfuerzos manuales para gestionar el acceso a modelos seguros y aprobados, lo que puede dar lugar a posibles descuidos”.

Siete pasos para la visibilidad de la cadena de suministro de IA

La brecha entre horas y semanas en la respuesta a incidentes de la cadena de suministro de IA se scale back a la preparación. Las organizaciones con visibilidad incorporada antes de la infracción tienen la información necesaria para reaccionar con mayor precisión y velocidad. Los que no tienen revuelo. Nada de lo siguiente requiere un nuevo presupuesto, sólo la decisión de tratar la gobernanza del modelo de IA con la misma seriedad que la seguridad de la cadena de suministro de software program.

  1. Comprométete a crear un inventario modelo y definir procesos para mantenerlo actualizado. Encuesta a los equipos de la plataforma ML. Escanee el gasto en la nube para fabricante de salvia, IA de vértice, y lecho de roca uso. Revisar abrazando la cara descargas en registros de crimson. Una hoja de cálculo funciona: nombre del modelo, propietario, clasificación de datos, ubicación de implementación, fuente y fecha de la última verificación. No puedes asegurar lo que no puedes ver.

  2. Apueste por el uso de técnicas avanzadas para gestionar y redirigir IA en la sombra utilice aplicaciones, herramientas y plataformas que sean seguras. Encuesta cada departamento. Verifique las claves API en las variables de entorno. Tenga en cuenta que los equipos de contabilidad, finanzas y consultoría pueden tener aplicaciones de inteligencia synthetic sofisticadas con múltiples API que se vinculan directamente y utilizan los datos patentados de la empresa. La brecha de visibilidad del 62% existe porque nadie preguntó.

  3. Exija la aprobación humana para los modelos de producción y diseñe siempre flujos de trabajo con un intermediario humano. Cada modelo que toca los datos del cliente necesita un propietario designado, un propósito documentado y un registro de auditoría que muestre quién aprobó la implementación. Tal como lo hacen los equipos rojos en Anthropic, OpenAI y otras empresas de inteligencia synthetic, diseñe procesos de aprobación de intermediarios humanos para cada lanzamiento de modelo.

  4. Considere exigir SafeTensors para nuevas implementaciones. Los cambios de política no cuestan nada. Tensores seguros almacena sólo datos numéricos del tensorno se ejecuta código durante la carga. abuelo existente conservar en vinagre modelos con aceptación de riesgo documentada y plazos de caducidad.

  5. Considere la posibilidad de pilotear ML-BOM primero para el 20% superior de los modelos de riesgo. Elija los que tocan los datos de los clientes o toman decisiones comerciales. Arquitectura de documentos, fuentes de datos de entrenamiento, linaje del modelo base, dependencias del marco. Usar CiclónDX 1.6 o SPDX 3.0. Comience de inmediato si aún no lo está haciendo, teniendo en cuenta que la procedencia incompleta es mejor que ninguna cuando ocurren incidentes.

  6. Trate cada extracción de modelo como una decisión de la cadena de suministro, de modo que se convierta en parte de la memoria muscular de su organización. Verifique los hashes criptográficos antes de la carga. Caché de modelos internamente. Bloquee el acceso a la crimson en tiempo de ejecución para entornos de ejecución de modelos. Aplique el mismo rigor que las empresas aprendieron de leftpad, event-stream y colors.js.

  7. Agregue gobernanza de IA a los contratos de proveedores durante el próximo ciclo de renovación. Exija SBOM, procedencia de los datos de capacitación, management de versiones del modelo y SLA de notificación de incidentes. Pregunte si sus datos entrenan modelos futuros. No cuesta nada solicitarlo.

2026 será un año de ajuste de cuentas para los SBOM de IA

Proteger los modelos de IA se está convirtiendo en una prioridad en las salas de juntas. El Ley de IA de la UE Las prohibiciones ya están en vigor, con multas que alcanzan los 35 millones de euros o el 7% de los ingresos globales. Los requisitos SBOM de la Ley de Resiliencia Cibernética de la UE comienzan este año. Se requiere el cumplimiento whole de la Ley de IA antes del 2 de agosto de 2027.

Las compañías de seguros cibernéticos están observando. Dada la prima de 670.000 dólares por las infracciones de la IA en la sombra y la exposición emergente a la responsabilidad ejecutiva, se espera que la documentación de gobernanza de la IA se convierta en un requisito de política este año, de la misma manera que la preparación para el ransomware se convirtió en algo en juego después de 2021.

El Plugfest de Armonización SBOM de SEI Carnegie Mellon analizó 243 SBOM de 21 proveedores de herramientas para software program idéntico y encontró una variación significativa en el recuento de componentes. Para los modelos de IA con dependencias integradas y cargas útiles ejecutables, hay mucho en juego.

El primer incidente con un modelo envenenado, que cuesta siete cifras en respuesta y multas, hará que el caso ya debería haber sido obvio.

Los SBOM de software program se volvieron obligatorios después de que los atacantes demostraron que la cadena de suministro period el objetivo más fácil. Las cadenas de suministro de IA son más dinámicas, menos visibles y más difíciles de contener. Las únicas organizaciones que ampliarán la IA de forma segura son aquellas que crean visibilidad ahora, antes de que la necesiten.

avotas