1. Objetivos de aprendizaje
Este módulo pretende llevar los conceptos de seguridad de software tradicionales al mundo de la Inteligencia Artificial.
El alumno debe terminar siendo capaz de diseñar un sistema en el que ningún modelo, dataset, paquete, container o proveedor pueda incorporarse a producción sin pasar por un proceso de validación.
Competencias que debe adquirir el alumno
- Identificar una AI Supply Chain completa.
- Construir un threat model de la cadena.
- Clasificar los activos de la cadena.
- Controlar procedencia e integridad.
- Diseñar una zona de cuarentena.
- Analizar modelos externos.
- Analizar datasets.
- Controlar dependencias Python.
- Analizar imágenes Docker.
- Aplicar seguridad a Kubernetes.
- Implementar SBOM.
- Diseñar AI-BOM.
- Aplicar firmas digitales.
- Implementar provenance.
- Diseñar gates de seguridad en CI/CD.
- Evaluar proveedores externos de IA.
- Controlar plugins y herramientas.
- Detectar compromisos de Supply Chain.
- Integrar los eventos con un AI-SOC.
- Responder ante un compromiso de la cadena.
2. ¿Por qué la AI Supply Chain es diferente?
Una aplicación web tradicional ya tiene una cadena de dependencias compleja. Sin embargo, una plataforma de IA introduce componentes adicionales que pueden convertirse en vectores de ataque.
Aplicación tradicional
Application │ ├── Operating System ├── Runtime ├── Libraries ├── Frameworks ├── Database └── External APIs
Aplicación de IA
AI Application │ ├── Operating System ├── Runtime ├── Libraries ├── AI Framework ├── Model ├── Model Configuration ├── Tokenizer ├── Dataset ├── Embedding Model ├── Vector Database ├── Prompt Templates ├── Plugins ├── Agent Tools ├── Container ├── GPU Runtime ├── External AI APIs └── CI/CD
La superficie de ataque ya no es únicamente la aplicación. Es toda la cadena de componentes necesarios para construir y ejecutar la aplicación.
3. Threat Modeling de la AI Supply Chain
Antes de implementar controles debemos identificar qué estamos intentando proteger.
Cadena completa
INTERNET
│
┌───────────┴───────────┐
│ │
Model Sources Package Sources
│ │
└───────────┬───────────┘
▼
QUARANTINE
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Models Data Dependencies
│ │ │
└─────────────┼─────────────┘
▼
Security Gate
│
┌──────┴──────┐
▼ ▼
Registry CI/CD
│ │
└──────┬──────┘
▼
Production
│
┌────────────┼────────────┐
▼ ▼ ▼
Model Tools APIs
│ │ │
└────────────┼────────────┘
▼
AI-SOC
Preguntas del threat model
- ¿Quién puede introducir componentes?
- ¿Quién puede modificarlos?
- ¿Quién puede aprobarlos?
- ¿Quién puede desplegarlos?
- ¿Dónde se almacenan?
- ¿Cómo se verifica su integridad?
- ¿Cómo conocemos su procedencia?
- ¿Qué ocurre si un proveedor es comprometido?
- ¿Qué ocurre si una dependencia desaparece?
- ¿Podemos reconstruir el artefacto?
4. Principales amenazas
| Amenaza | Descripción | Impacto |
|---|---|---|
| Dependency Confusion | Uso de un paquete malicioso en lugar del paquete interno esperado. | Compromiso del build. |
| Typosquatting | Paquete con nombre similar a uno legítimo. | Ejecución de código. |
| Malicious Package | Dependencia diseñada para atacar al consumidor. | RCE / robo de secretos. |
| Model Tampering | Manipulación de pesos o configuración. | Compromiso del modelo. |
| Dataset Poisoning | Introducción de datos manipulados. | Comportamiento malicioso. |
| Container Compromise | Imagen manipulada o vulnerable. | Compromiso del runtime. |
| Registry Compromise | Manipulación del repositorio de artefactos. | Distribución de artefactos maliciosos. |
| CI/CD Compromise | Manipulación del proceso de construcción. | Compromiso de toda la cadena. |
| Provider Compromise | Compromiso de un proveedor externo. | Impacto indirecto sobre la organización. |
5. Model Supply Chain
Un modelo debe considerarse un artefacto de software.
Model Package │ ├── weights ├── configuration ├── tokenizer ├── metadata ├── adapters ├── quantization └── auxiliary files
Por tanto, debemos aplicar controles equivalentes a los que aplicamos a un binario o una imagen de container.
Ciclo de vida seguro
Obtención desde una fuente autorizada.
El artefacto no entra directamente en producción.
Hash, firma, metadata y provenance.
Análisis estático y dinámico.
Validación según política.
Registro en Model Registry.
Promoción controlada hacia producción.
Monitorización continua.
6. Integridad de artefactos
El mecanismo más sencillo para comprobar que un fichero no ha cambiado es un hash criptográfico.
SHA-256
sha256sum model.bin
Supongamos:
a8e9d7c5f1a2...
Ese valor debe almacenarse junto al artefacto aprobado.
Verificación
EXPECTED="a8e9d7c5f1a2..."
ACTUAL=$(sha256sum model.bin | awk '{print $1}')
if [ "$EXPECTED" != "$ACTUAL" ]; then
echo "INTEGRITY FAILURE"
exit 1
fi
echo "MODEL VERIFIED"
Un hash proporciona integridad, pero no proporciona autenticidad por sí solo. Si un atacante puede modificar simultáneamente el fichero y el registro del hash, el control deja de ser útil.
7. Firmas digitales
Para mejorar el modelo de confianza necesitamos demostrar no solo que un artefacto no ha cambiado, sino quién lo aprobó.
Artifact │ ▼ Hash │ ▼ Digital Signature │ ▼ Verification
La firma permite establecer una relación de confianza:
Artifact
│
├── Hash
│
└── Signature
│
▼
Signing Identity
En ecosistemas cloud-native pueden utilizarse herramientas como Cosign y proyectos como Sigstore.
Principio
La producción debería aceptar únicamente artefactos que cumplan la política de firma establecida.
8. Formatos de modelos y deserialización
Uno de los riesgos que debe conocer un especialista de seguridad es que determinados formatos de serialización pueden permitir ejecución de código durante la carga.
El caso clásico en Python es pickle.
Dependiendo del formato, cargar un artefacto no confiable puede ejecutar código con los privilegios del proceso que realiza la carga.
Arquitectura segura
Internet │ ▼ Download │ ▼ Quarantine │ ▼ Static Analysis │ ▼ Sandbox │ ▼ Validation │ ▼ Approved Registry │ ▼ Production
El sandbox debe tener privilegios mínimos y estar aislado de las redes internas sensibles.
9. Data Supply Chain
Los datos son otro artefacto crítico.
Data lifecycle
Source │ ▼ Collection │ ▼ Normalization │ ▼ Cleaning │ ▼ Transformation │ ▼ Training │ ▼ Validation │ ▼ Model
Cada etapa debe generar trazabilidad.
Data provenance
| Campo | Ejemplo |
|---|---|
| Source | Internal / External provider |
| Version | dataset-v4.2 |
| Timestamp | 2026-08-29T08:30:00Z |
| Hash | SHA-256 |
| Transformation | Normalization + filtering |
| Owner | Data Engineering |
| Approval | Security + Data Governance |
Data Poisoning
Un atacante puede intentar introducir datos diseñados para alterar el comportamiento del modelo.
Por ello necesitamos controles sobre:
- fuentes;
- calidad;
- anomalías;
- procedencia;
- integridad;
- versionado;
- aprobación.
10. Software Dependency Security
Un sistema de IA puede tener cientos de dependencias.
Inventario
pip freeze
O:
pip list --format=json
Auditoría
pip install pip-audit pip-audit
En un entorno real este análisis debería ejecutarse automáticamente en CI/CD.
Política de dependencias
ALLOW:
approved packages
REVIEW:
new packages
unknown maintainers
BLOCK:
critical vulnerabilities
malicious packages
unapproved sources
11. Container Supply Chain
Los workloads de IA se ejecutan frecuentemente dentro de containers.
Dockerfile │ ▼ Base Image │ ▼ Dependencies │ ▼ Application │ ▼ Container Image │ ▼ Registry │ ▼ Production
Buenas prácticas
- Evitar
latest. - Fijar versiones.
- Usar imágenes mínimas.
- Ejecutar como usuario no root.
- Reducir Linux capabilities.
- Escanear vulnerabilidades.
- Firmar imágenes.
- Utilizar digest.
- Controlar el registry.
Tag vs Digest
ai-service:1.4.2
Frente a:
ai-service@sha256:xxxxxxxx
El digest identifica de forma inequívoca el artefacto.
12. Kubernetes y AI Supply Chain
Cuando la plataforma de IA se ejecuta sobre Kubernetes, aparecen nuevos puntos de control.
Developer │ ▼ Container Registry │ ▼ Admission Controller │ ▼ Kubernetes │ ├── Namespace ├── ServiceAccount ├── Secret ├── ConfigMap ├── Pod └── NetworkPolicy
Admission Control
Una estrategia madura consiste en impedir que Kubernetes ejecute imágenes que no cumplen determinadas políticas.
Ejemplos de políticas:
- Imagen obligatoriamente firmada.
- Registry permitido.
- Digest obligatorio.
- No root.
- No privileged containers.
- Capabilities restringidas.
- Seccomp obligatorio.
- Resource limits.
Principio
Developer → Registry → Security Gate → Kubernetes
│
├── ALLOW
└── DENY
13. SBOM — Software Bill of Materials
Un SBOM describe los componentes que forman parte de un artefacto.
Para una aplicación de IA puede contener:
- frameworks;
- librerías;
- versiones;
- dependencias transitivas;
- licencias;
- vulnerabilidades conocidas.
Ejemplo conceptual
Application │ ├── Python ├── PyTorch ├── Transformers ├── FastAPI ├── Pydantic ├── NumPy └── Requests
Herramientas como Syft permiten generar inventarios de componentes.
14. AI-BOM
El SBOM no captura necesariamente todos los elementos específicos de IA. Por eso resulta útil ampliar el concepto hacia un AI-BOM.
AI-BOM │ ├── Application │ ├── Model │ ├── Name │ ├── Version │ ├── Hash │ └── Provider │ ├── Dataset │ ├── Source │ ├── Version │ └── Hash │ ├── Dependencies │ ├── Container │ ├── Embedding Model │ ├── Vector DB │ ├── Tools │ ├── Plugins │ └── External Providers
Ser capaces de responder rápidamente a la pregunta: "¿De qué depende exactamente este sistema de IA?"
15. Provenance
La provenance describe cómo se creó un artefacto.
No queremos únicamente conocer:
¿Qué modelo tenemos?
Queremos poder responder:
¿Quién lo construyó? ¿Con qué código? ¿Con qué dataset? ¿Con qué dependencias? ¿Con qué pipeline? ¿En qué entorno? ¿Con qué versión? ¿Quién lo aprobó?
Cadena de provenance
Source Code
│
▼
Commit
│
▼
Build
│
├── Dependencies
├── Dataset
└── Model
│
▼
Artifact
│
▼
Sign
│
▼
Registry
│
▼
Deployment
16. AI-DevSecOps Pipeline
La seguridad de la Supply Chain debe integrarse en el pipeline.
COMMIT
│
▼
┌──────────┐
│ SAST │
└────┬─────┘
▼
Dependency Scan
│
▼
Secret Scan
│
▼
BUILD
│
▼
Container Scan
│
▼
Model Scan
│
▼
Dataset Checks
│
▼
SBOM/AI-BOM
│
▼
Provenance
│
▼
Signing
│
▼
Security Gate
│
┌─────┴─────┐
▼ ▼
ALLOW DENY
│
▼
Registry
│
▼
Production
Principio clave
La seguridad debe ser un gate automático, no una recomendación documental.
17. Policy as Code
Las políticas de seguridad deben poder convertirse en reglas automatizadas.
Ejemplo conceptual
artifact: require_signature: true require_hash: true container: allow_root: false require_digest: true dependencies: critical_cve: deny model: approved_registry: true provenance_required: true deployment: security_approval: required
Este enfoque permite que el pipeline pueda decidir automáticamente si un artefacto puede avanzar.
18. Third-Party AI Providers
Utilizar una API externa de IA significa incorporar un tercero a nuestra cadena.
Evaluación de proveedor
| Área | Preguntas |
|---|---|
| Datos | ¿Dónde se procesan? ¿Se almacenan? |
| Privacidad | ¿Se utilizan para entrenamiento? |
| Seguridad | ¿Cómo se protegen las interfaces? |
| Identidad | ¿Cómo se gestionan las credenciales? |
| Disponibilidad | ¿Qué ocurre ante una caída? |
| Incidentes | ¿Cómo se notifican? |
| Continuidad | ¿Existe estrategia de salida? |
Una dependencia excesiva de un proveedor puede transformar un incidente externo en un incidente operacional interno.
19. Plugins, Tools y Agent Supply Chain
Los agentes de IA amplían todavía más la Supply Chain.
Agent │ ├── Search Tool ├── Browser Tool ├── Database Tool ├── File Tool ├── Email Tool ├── API Tool └── Shell Tool
Cada herramienta tiene:
- código;
- dependencias;
- credenciales;
- permisos;
- interfaces;
- datos de entrada;
- datos de salida.
Principio de mínimo privilegio
Si una herramienta solo necesita consultar una base de datos, no debería tener permisos de escritura.
READ ONLY
│
▼
Database Query
NO:
INSERT
UPDATE
DELETE
DROP
20. Model Registry y Artifact Registry
Los registries deben convertirse en componentes de confianza.
Un registry seguro debería proporcionar
- Autenticación.
- Autorización.
- Versionado.
- Hashes.
- Firmas.
- Audit logs.
- Metadata.
- Provenance.
- Retención.
- Rollback.
Flujo
UNTRUSTED │ ▼ Quarantine Registry │ ▼ Security Validation │ ▼ Approved Registry │ ▼ Production
21. Detección de ataques contra la Supply Chain
La Supply Chain también debe integrarse en el sistema de monitorización.
Eventos relevantes
- Nuevo modelo.
- Nuevo hash.
- Nuevo dataset.
- Nueva dependencia.
- Cambio de versión.
- Nueva imagen.
- Modificación de firma.
- Cambio de permisos.
- Acceso anómalo al registry.
- Deployment fuera de CI/CD.
- Uso de proveedor no autorizado.
Regla de detección
IF production_model_hash != approved_model_hash THEN CRITICAL ALERT + BLOCK DEPLOYMENT + QUARANTINE ARTIFACT + NOTIFY AI-SOC
22. Supply Chain Incident Response
Supongamos que descubrimos que una dependencia utilizada por nuestro servicio de IA ha sido comprometida.
Respuesta
Determinar qué versión está comprometida.
Identificar sistemas afectados.
Bloquear la dependencia y nuevos deployments.
Eliminar el componente comprometido.
Reconstruir desde una cadena confiable.
Escanear y validar los nuevos artefactos.
Promover mediante CI/CD seguro.
Buscar indicadores de compromiso históricos.
23. Laboratorio 1 — Inventario de una AI Supply Chain
Escenario
Una empresa dispone de un chatbot corporativo con la siguiente arquitectura:
Browser │ ▼ API Gateway │ ▼ AI Agent │ ├── LLM API ├── Vector DB ├── Search ├── Internal DB └── Document Store
El sistema se ejecuta en Kubernetes y se despliega mediante GitHub Actions.
Pregunta
Construye el inventario completo de Supply Chain.
Resolución
No debemos quedarnos únicamente con los componentes visibles.
Application │ ├── Source Code ├── Python Dependencies ├── Base Container ├── Final Container ├── Kubernetes Manifests ├── LLM Provider ├── Prompt Templates ├── Model ├── Embedding Model ├── Vector DB ├── Search Tool ├── Database Tool ├── Documents ├── CI/CD ├── Secrets └── Registry
Todos ellos forman parte del perímetro de confianza.
24. Laboratorio 2 — Detección de dependencia comprometida
Escenario
El equipo descubre que la versión 4.2.1 de una librería utilizada
por el servicio de IA ha sido comprometida.
La organización tiene 37 servicios.
Objetivo
Determinar qué servicios están afectados y diseñar la respuesta.
Resolución
- Consultar SBOM de todos los servicios.
- Identificar los que utilizan la versión afectada.
- Correlacionar deployments.
- Bloquear nuevas promociones.
- Revocar la versión comprometida.
- Buscar indicadores de compromiso.
- Construir una versión segura.
- Generar nuevo SBOM.
- Firmar el nuevo artefacto.
- Desplegar.
- Monitorizar.
25. Laboratorio 3 — Modelo manipulado
Escenario
El equipo recibe una actualización del modelo.
El proveedor asegura que únicamente ha realizado una actualización de metadata.
Sin embargo:
Approved SHA256: AAA111 New SHA256: BBB222
Pregunta
¿Debe desplegarse?
Resolución
No automáticamente.
El cambio de hash significa que el artefacto no es idéntico al aprobado.
Debe entrar nuevamente en:
Quarantine │ ▼ Verification │ ▼ Analysis │ ▼ Security Approval │ ▼ Signing │ ▼ Production
26. Laboratorio 4 — Kubernetes Admission Control
Objetivo
Diseñar una política que impida ejecutar imágenes que:
- no procedan del registry autorizado;
- no estén firmadas;
- utilicen
latest; - se ejecuten como root;
- utilicen privileged mode.
Resolución conceptual
IF registry != trusted-registry
DENY
IF image_tag == latest
DENY
IF signature == invalid
DENY
IF container.runAsRoot == true
DENY
IF privileged == true
DENY
En una implementación real estas políticas pueden integrarse mediante admission controllers y motores de policy-as-code.
27. Laboratorio 5 — Construcción de un AI-BOM
Objetivo
Crear un inventario que permita reconstruir completamente un sistema de IA.
Debe incluir como mínimo:
- modelo;
- dataset;
- dependencias;
- container;
- plugins;
- proveedores;
- versiones;
- hashes;
- responsables.
Ejemplo
AI-BOM
Application:
corporate-assistant
Model:
provider: Internal
version: 7.3
sha256: ...
Dataset:
corporate-docs
version: 2026.08
sha256: ...
Container:
registry: internal
digest: sha256:...
Dependencies:
torch
transformers
fastapi
pydantic
Tools:
search
database
Providers:
LLM Provider
Embedding Provider
28. Proyecto final del módulo
Construye una AI Supply Chain Security Platform
El alumno debe diseñar una arquitectura completa para una organización que quiera permitir el uso de IA sin perder control sobre su cadena de suministro.
Requisitos funcionales
- Model Registry.
- Artifact Registry.
- Quarantine.
- Dependency Scanning.
- Container Scanning.
- Model Verification.
- Dataset Validation.
- SBOM.
- AI-BOM.
- Provenance.
- Digital Signatures.
- Policy Engine.
- CI/CD Security Gate.
- Provider Inventory.
- Plugin Inventory.
- Audit Logging.
- SIEM Integration.
- Incident Response.
Arquitectura esperada
INTERNET
│
┌──────────────┼──────────────┐
▼ ▼ ▼
MODELS DATA DEPENDENCIES
│ │ │
└──────────────┼──────────────┘
▼
QUARANTINE
│
▼
SECURITY ANALYSIS
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Hashing Vulnerability Provenance
│ Scanning │
└─────────────────┼─────────────────┘
▼
POLICY ENGINE
│
▼
AI-BOM/SBOM
│
▼
SIGNING
│
▼
TRUSTED REGISTRY
│
▼
CI/CD
│
▼
KUBERNETES
│
▼
AI RUNTIME
│
┌─────────────┼─────────────┐
▼ ▼ ▼
MODEL TOOLS APIs
│ │ │
└─────────────┼─────────────┘
▼
AI-SOC
29. Evaluación del alumno
| Área | Peso |
|---|---|
| Threat Modeling | 10% |
| Model Security | 10% |
| Data Supply Chain | 10% |
| Dependency Security | 10% |
| Container/Kubernetes Security | 15% |
| SBOM / AI-BOM | 10% |
| CI/CD Security | 10% |
| Incident Response | 10% |
| Proyecto final | 15% |
30. Checklist profesional
- ☐ Tenemos inventario de modelos.
- ☐ Tenemos inventario de datasets.
- ☐ Tenemos inventario de dependencias.
- ☐ Los artefactos tienen hash.
- ☐ Los artefactos críticos están firmados.
- ☐ Existe Model Registry.
- ☐ Existe Artifact Registry.
- ☐ Existe zona de cuarentena.
- ☐ Se escanean dependencias.
- ☐ Se escanean containers.
- ☐ Existe SBOM.
- ☐ Existe AI-BOM.
- ☐ Tenemos provenance.
- ☐ Existe policy-as-code.
- ☐ CI/CD tiene security gates.
- ☐ Kubernetes valida los artefactos.
- ☐ Los plugins están inventariados.
- ☐ Los proveedores externos están evaluados.
- ☐ Existe audit trail.
- ☐ Los eventos llegan al SOC.
- ☐ Existe procedimiento de respuesta.
- ☐ Podemos reconstruir un artefacto.
- ☐ Podemos identificar qué sistemas utilizan una dependencia comprometida.
31. Herramientas recomendadas
pip-audit
Auditoría de dependencias Python.
Trivy
Análisis de vulnerabilidades de containers y otros artefactos.
Syft
Generación de SBOM.
Grype
Detección de vulnerabilidades a partir de SBOM y artefactos.
Cosign
Firma y verificación de artefactos.
Sigstore
Infraestructura de confianza para firma y verificación.
OPA
Policy-as-code y control automatizado.
Kubernetes
Plataforma de ejecución y enforcement de políticas.
32. Referencias y recursos
OWASP
- OWASP Top 10 for LLM Applications
- OWASP Machine Learning Security
- OWASP Software Supply Chain Security
- OWASP Software Component Verification Standard
NIST
- NIST AI Risk Management Framework
- NIST Secure Software Development Framework
- NIST Cybersecurity Framework
Cloud Native Security
- SLSA
- Sigstore
- Cosign
- in-toto
- SPDX
- CycloneDX
- Open Policy Agent
33. Preguntas de comprobación
Pregunta 1
¿Por qué un hash no es suficiente para garantizar la autenticidad de un modelo?
Porque si el atacante puede modificar tanto el artefacto como el lugar donde se almacena el hash esperado, puede generar un nuevo hash. La firma digital añade una relación de confianza con una identidad de firma.
Pregunta 2
¿Por qué production no debería descargar directamente modelos desde Internet?
Porque elimina los controles de cuarentena, análisis, aprobación, firma, provenance y policy enforcement. Production debería consumir artefactos previamente validados desde un registry confiable.
Pregunta 3
¿Qué diferencia existe entre SBOM y AI-BOM?
El SBOM se centra principalmente en componentes de software. El AI-BOM amplía el inventario para incluir elementos propios de los sistemas de IA, como modelos, datasets, embeddings, herramientas, plugins y proveedores.
Pregunta 4
¿Qué debe ocurrir si Kubernetes recibe una imagen no firmada?
En una arquitectura madura, el admission control debería rechazar el deployment antes de que el workload sea ejecutado.
34. Conclusión
La seguridad de una plataforma de IA no consiste únicamente en proteger el modelo frente a prompt injection o proteger el endpoint mediante un firewall.
La verdadera superficie de ataque incluye todo aquello que participa en la construcción, entrenamiento, distribución, despliegue y operación del sistema.
La cadena de confianza
SOURCE ↓ CODE ↓ DEPENDENCIES ↓ DATA ↓ MODEL ↓ BUILD ↓ CONTAINER ↓ SBOM / AI-BOM ↓ PROVENANCE ↓ SIGNING ↓ REGISTRY ↓ CI/CD ↓ KUBERNETES ↓ AI RUNTIME ↓ AI-SOC
"No confíes en el componente. Verifica el componente."
Una arquitectura de AI Supply Chain madura transforma una cadena de dependencias potencialmente desconocidas en una cadena de confianza verificable, auditable y monitorizada.