Supply chain de artefactos ML

Superficie: Supply chain ATLAS: AML.T0010 (AI Supply Chain Compromise), AML.T0010.001 (AI Software) OWASP: LLM04:2026 Supply Chain, ML06:2023 AI Supply Chain Attacks (ML Top 10, draft 2023) Riesgo: Alto

Qué importa

El modelo tiene una firma válida. Antes de aprobarlo, falta una pregunta: ¿esa firma pertenece al publicador que PhiloCorp autorizó para este release? Autenticidad, integridad y aprobación son tres decisiones distintas.

Un modelo, dataset, tokenizer, adaptador, dependencia o herramienta puede heredar confianza sin evidencia suficiente. El objetivo de la evaluación es comprobar que el pipeline de PhiloCorp solo promueve componentes verificables, no demostrar ejecución de contenido no confiable.

Cómo evaluar de forma segura

1. Inventariá código y dependencias en un SBOM (lista de componentes de software); extendé el registro a modelos, datos, tokenizer y adaptadores con un ML-BOM. Declaralos con versión de formato, campos requeridos y vínculos al release.
2. Exigí firma sobre el digest verificado, identidad autorizada y procedencia aprobada. Una firma válida de un publicador ajeno debe fallar igual que una firma inválida.
3. Separá publicación de promoción: quien publica no debe aprobar el release.
4. Validá en CI y en admisión de despliegue. Rechazá manifiestos de laboratorio con firma, digest o ML-BOM inválidos.
5. Auditá cambios de metadatos, permisos de registry y dependencias antes de cada promoción.

Marcador y resultado esperado

artifact_policy:
  marker: PHILO_TEST_09_SUPPLY_CHAIN
  publisher: philocorp-model-release
  immutable_digest_required: true
  signature_required: true
  sbom_required: true
  mlbom_required: true
  approved_source_registries:
    - registry.philocorp.invalid
expected_decision: reject_when_any_requirement_fails

Probá una condición inválida por vez y agregá un control positivo completamente aprobado. Si todo falla porque el servicio está caído, todavía no demostraste que la política funcione.

Límite de la prueba: usá manifiestos sintéticos y validación previa a promoción; no cargues modelos no confiables ni publiques releases reales. Abortá ante ejecución inesperada, pérdida de auditoría o presupuesto excedido. Retirá las referencias de laboratorio, compará el inventario inicial y final y adjuntá las decisiones al Attack Intelligence Brief.

Criterios de verificación

• El release tiene SBOM y ML-BOM vinculados a un digest.
• La promoción verifica identidad y attestations antes de admitir el artefacto; el digest se comprueba contra los bytes descargados en cuarentena, antes de la carga.
• Las versiones promovidas son inmutables y auditables.
• Un manifiesto inválido no crea workload ni ejecuta loader.
• Publicación y promoción son identidades separadas, con evidencia de ambas.

Remediación

Fijá dependencias por digest y usá firmas, attestations, permisos mínimos en el registro, controles de promoción y revisión de cambios. Frameworks de procedencia de build como SLSA ordenan los controles del pipeline (fuente, build, distribución) y se complementan con el ML-BOM. CycloneDX ML-BOM y perfiles AI de SPDX ayudan a representar dependencias, datos y linaje, pero deben integrarse con controles de release y no ser solo inventario.