Caso B - PhiloCorp Model Release Gate: del artefacto a la decisión de promoción

Tipo: Capstone sintético Superficies: Supply chain, registry, ML-BOM, CI/CD, admisión Kubernetes y loader OWASP: LLM04:2026 Supply Chain, ML06:2023 AI Supply Chain Attacks (ML Top 10, draft 2023) Riesgo potencial: Crítico cuando la cadena permite ejecutar contenido no confiable

Escenario

El release llega con una firma válida y un nombre conocido. En el expediente ficticio de PhiloCorp, eso todavía no lo convierte en un release aprobado: falta comprobar quién firmó, qué bytes evaluó el equipo y si son los mismos que el despliegue intenta usar.

registry.philocorp.invalid representa el registro de un clasificador sintético. deploy.philocorp.invalid representa su promoción a un namespace de laboratorio. Todos los artefactos son inertes; resolución, promoción y admisión se evalúan sin instalar paquetes, deserializar modelos ni crear workloads.

Qué tomamos de los antecedentes

El incidente de PyTorch-nightly, de diciembre de 2022, involucró una dependencia con el mismo nombre en otro índice. Eso es dependency confusion. Un nombre parecido con una letra de diferencia corresponde a typosquatting: conviene separarlos porque requieren pruebas distintas.

PoisonGPT fue una demostración de investigación de 2023 sobre modificación dirigida y distribución de un modelo. ReversingLabs documentó en febrero de 2025 modelos maliciosos cuyo contenido podía ejecutarse antes de que la deserialización terminara con un error. Un análisis incompleto no equivale a un resultado limpio.

ATLAS v2026.07 registra estos antecedentes como AML.CS0015, AML.CS0019 y AML.CS0031. La secuencia de PhiloCorp reúne decisiones inspiradas en ellos; no afirma que fueran un mismo incidente.

RoE y preparación

Usá catálogos locales, manifiestos y archivos sintéticos sin código ejecutable. Bloqueá red, instalación, carga y despliegue. Registrá presupuesto de intentos y tiempo, namespace lógico, identidad, versiones del verificador y políticas. Incluí una entrada válida como control positivo.

Cada variante negativa debe fallar una sola condición. Si cambiás firma, publicador y digest a la vez, el primer rechazo puede ocultar que las otras dos comprobaciones nunca se ejecutaron.

Arquitectura

Catálogo local -> Resolución -> Manifiesto -> Promoción -> Admisión en dry-run
                                  |             |                |
                            Digest y firma   Aprobación      Política efectiva

La frontera final de carga se revisa por configuración y eventos; este capstone no la cruza.

Material de prueba

Resolución entre orígenes:

resolution_fixture:
  marker: PHILO_TEST_11_B_CONFUSION
  package_name: philocorp-tokenizer
  approved_candidate:
    index: internal-lab-catalog
    version: 1.0.0
    digest: "<sha256_del_archivo_inerte_aprobado>"
  competing_candidate:
    index: unapproved-lab-catalog
    version: 9.9.9
    digest: "<sha256_del_archivo_inerte_alternativo>"
  mode: offline_resolution_only
expected_decision: select_only_explicitly_approved_origin

No se publica ni instala un paquete. El orden visual de índices no basta: comprobá la semántica del resolver. Elegir «el interno primero» no garantiza que la herramienta excluya candidatos de otros índices.

Publicador no autorizado:

model_fixture:
  id: philocorp-lab-classifier-02
  marker: PHILO_TEST_11_B_POISON
  content: inert_model_metadata
  signature: "<firma_de_laboratorio_verificable_sobre_el_digest>"
  signer: philocorp-unapproved-lab-publisher
  other_policy_requirements: valid
expected_decision: reject_unapproved_publisher

Este fixture demuestra una decisión de procedencia. No contiene ni prueba un modelo envenenado. La evaluación del comportamiento dirigido requiere el experimento independiente de data poisoning. Una firma autorizada tampoco certifica que el comportamiento del modelo sea correcto.

Formato no permitido y resultado de inspección:

format_fixture:
  id: philocorp-lab-model-003-format
  marker: PHILO_TEST_11_B_LOADER
  declared_format: pickle-legacy
  declared_loader: torch.load
  origin: approved-lab
  scan_result_fixture: complete
  other_policy_requirements: valid
  deserialization_allowed: false
  expected_decision: reject_forbidden_format_before_load
scan_fixture:
  id: philocorp-lab-model-003-scan
  declared_format: approved_data_only_format
  scan_result_fixture: incomplete
  other_policy_requirements: valid
  deserialization_allowed: false
  expected_decision: reject_unverified_artifact

Son dos corridas independientes: una falla por formato y la otra por inspección incompleta. El resultado de escaneo es simulado. Para verificar el analizador real, prepará otra prueba con un archivo inerte y malformado de origen conocido, sin instrucciones ejecutables. En ambos casos, un resultado incompleto debe quedar como «no verificado».

Aprobación asociada a otros bytes:

promotion_attempt:
  artifact_id: philocorp-lab-classifier-02
  digest: "<sha256_completo_del_fixture_B>"
  attestation_subject_digest: "<sha256_completo_del_fixture_A>"
  signer: philocorp-approved-lab-publisher
  other_policy_requirements: valid
expected_decision: reject_attestation_subject_mismatch

Calculá ambos hashes de archivos inertes distintos y generá firmas con claves exclusivas del laboratorio. Los campos anteriores son una especificación de entradas, no evidencia criptográfica por sí mismos. Probá vigencia o entorno incorrectos como variantes separadas.

Pasos

Un reintento del mismo ID no es necesariamente un replay indebido: una política puede volver a evaluarlo y aprobar una versión corregida. Lo que no debe aceptar es una aprobación fuera de su digest, identidad, entorno o vigencia.

Métrica: independencia de controles

Reportá la matriz entrada × regla × resultado, incluido el control positivo. El número de reglas que producen un deny no mide por sí solo la calidad de una defensa. Lo que importa es comprobar que cada condición declarada se valida y que la prueba llega al control que querés observar.

Un deny de admisión en dry-run demuestra la decisión evaluada, no que una solicitud real atraviese esa misma configuración. Verificá el enlace con la política activa y su auditoría antes de afirmar que el despliegue queda protegido. La ausencia de Pods durante un ensayo que nunca crea Pods no es, por sí sola, evidencia de bloqueo.

Detención y cierre

Abortá ante instalación, descarga no prevista, deserialización, creación de workloads, pérdida de auditoría o presupuesto excedido. El criterio de éxito combina rechazo por el motivo correcto, aprobación de la entrada válida y trazabilidad entre artefacto, identidad y política.

Sumá al Attack Intelligence Brief la matriz y los límites de cada ensayo. El cierre tiene que responder:

• ¿La firma está ligada a los bytes y a un publicador autorizado?
• ¿El SBOM, ML-BOM y las attestations corresponden al mismo release?
• ¿La admisión verifica por sí misma los requisitos de promoción?
• ¿Qué falta observar en ejecución antes de dar por verificado el control?