Inicio/Blog/Procedencia digital Supply Chain de SoftwareProcedencia digital, SBOMs y código generado por IA firmado
Los agentes de IA ya pueden escribir código, actualizar dependencias, generar contenedores y tocar archivos de deploy en minutos. Esa velocidad solo sirve si producción puede responder una pregunta aburrida y crítica: quién produjo este artefacto, desde qué fuente, con qué dependencias, bajo qué workflow, y si cambió desde entonces.
Publicado el 1 de junio de 202612 min de lecturaSeguridad de supply chain
Procedencia convierte output de IA en evidencia
El código generado no es especial solo porque vino de un modelo. Es especial porque puede cambiar más rutas de código, más rápido y con menos escritura humana. Eso vuelve más importante la evidencia de supply chain. Un comentario en el PR diciendo "lo escribió el agente" no es procedencia. Una attestation firmada que conecta el artefacto con fuente, commit, workflow, builder, dependencias y digest es algo que un gate de deploy puede verificar.
SLSA se enfoca en provenance para integridad de build. Sigstore ofrece firma y transparencia para artefactos. CycloneDX cubre SBOMs y ML-BOMs para representar software, modelos, datasets y dependencias. Juntos dan al código de IA una pista verificable.
Pipeline de verificación de código IACambio del agenteCódigo, tests, prompts, dependencias o deploy son modificados.
ReviewHumano aprueba comportamiento, riesgo e impacto arquitectural.
BuildCI produce artefacto desde fuente e identidad de workflow.
DocumentarSBOM, ML-BOM, licencias, modelos, datasets y grafo de dependencias.
FirmarArtefacto y attestations son firmados y registrados.
VerificarPolicy revisa digest, provenance, signer y riesgo antes del deploy.
SBOM es la lista de ingredientes, provenance es el recibo
Un SBOM dice qué hay dentro. Provenance dice cómo fue producido. Una firma dice si lo que estás desplegando todavía coincide con lo que fue firmado. La entrega en la era de IA necesita los tres, porque cambios generados suelen tocar glue code, dependencias transitivas, prompts, SDKs generados y capas de contenedor al mismo tiempo.
Para sistemas de IA, el inventario se expande. No basta listar dependencias npm o Python. También entran nombre y versión del modelo, linaje de dataset, modelo de embedding, versión de prompt, suite de eval, permisos de herramientas y política runtime.
SBOMQué paquetes, licencias, archivos y componentes existen?
ML-BOMQué modelos, datasets, frameworks y metadatos importan?
AttestationQuién construyó, desde qué fuente, usando cuál workflow?
FirmaProducción puede verificar identidad antes de ejecutar?
Qué debería firmarse
El error es firmar solo el contenedor final y decir que ya está. Una supply chain útil para IA firma la imagen, el SBOM, el artefacto de modelo, el reporte de eval, el manifiesto de deploy y la declaración de provenance. La firma permite que un admission controller o script de deploy rechace artefactos desconocidos antes de producción.
| Artefacto | Qué prueba | Gate de política |
|---|
| Commit fuente | Qué revisión introdujo el cambio, incluidos archivos del agente. | Exigir branch protegida, review e identidad de workflow. |
| Build provenance | Qué builder, workflow, inputs y digest produjeron el artefacto. | Aceptar solo builders confiables y paths esperados. |
| SBOM | Qué dependencias, licencias y componentes están incluidos. | Bloquear licencias prohibidas, paquetes vulnerables y registries desconocidos. |
| ML-BOM | Qué modelos, datasets, embeddings, frameworks y evals participan. | Bloquear modelos no aprobados o linaje ausente. |
| Firma del contenedor | Si el digest de imagen coincide con una firma confiable. | Desplegar solo digests firmados, nunca tags mutables solas. |
| Attestation de eval | Qué tests, scans y evals pasaron para este artefacto exacto. | Exigir cobertura, scan de seguridad y threshold de eval. |
Los agentes de IA necesitan identidad en la pista
Cuando un agente hace un cambio, la pista de provenance no debería fingir que un humano escribió cada línea. Commit y PR deberían mostrar aprobador humano, identidad del agente o workflow, herramientas usadas y archivos tocados. El objetivo no es culpar; es replay. Si un upgrade de modelo o política de agente produce mala salida, necesitas encontrar todo artefacto construido bajo ese contexto.
Aquí gobernanza de IA se encuentra con DevSecOps. El output de agente debe entrar en la misma malla de verificación que el código humano: branch protection, tests, SBOM, provenance firmada, verificación de artefacto y monitoreo runtime.
Lo que yo construiría
Construiría un "pasaporte de artefacto IA" para cada servicio desplegable. El pasaporte uniría commit fuente, revisor humano, identidad del agente, referencia de prompt o tarea, SBOM, ML-BOM, SLSA provenance, firma cosign, resultados de eval, scan de vulnerabilidades y ambiente de deploy. Producción rechazaría releases sin pasaporte válido.
La mejor versión sería aburrida en el buen sentido: un workflow reutilizable de CI emite evidencias, un motor de política verifica todo y un dashboard muestra qué es confiable, qué expiró y qué no puede reproducirse.
El principio de diseño
El código generado por IA no necesita un universo separado de confianza. Necesita evidencia más fuerte dentro de la supply chain que ya tenemos. Si un sistema no prueba de dónde vino un artefacto, qué contiene, quién aprobó y por qué producción lo aceptó, la velocidad superó la accountability.