Un artefacto firmado prueba qué workflow construyó un commit. Por sí solo no explica por qué un agente creó ese commit, qué autoridad inició la tarea, qué tools influyeron el diff o qué humano aceptó el resultado.
SLSA define procedencia como información verificable sobre dónde, cuándo y cómo un artefacto fue producido. Artifact attestations de GitHub conectan artefacto con repositorio, commit SHA, workflow y entorno de build. Esos controles son esenciales, pero un PR generado con IA agrega otra pregunta: ¿cómo se produjo el cambio de source?
La respuesta no debe ser una etiqueta vaga “AI-assisted”. Un registro útil conecta tarea aprobada, principal responsable, identidad del agente, modelo y tools, contexto recuperado, archivos generados, intentos, pruebas, reviews y commit final. La procedencia de build continúa la cadena hasta el artefacto.
Las etiquetas de IA deben ayudar review e incident response, no crear un falso binario entre “código humano” y “código de IA”. Los humanos usan autocomplete, clientes generados, migrations, templates y agentes en el mismo PR. Registra qué archivos o hunks fueron generados o transformados, qué sistema lo hizo y qué humano asumió responsabilidad.
El manifest también captura dependencias y contexto externo introducidos. Si el código copió un patrón inseguro de documentación o agregó paquete comprometido, investigadores necesitan reconstruir la influencia sin guardar prompts sensibles para siempre.
SBOM describe componentes. Procedencia describe cómo se produjo un artefacto. Firma liga identidad a digest o attestation. Review explica por qué source fue aceptado. Deployment metadata dice dónde corre. Ninguno sustituye a los demás.
GitHub genera attestations de build y SBOM. Sigstore soporta firma basada en identidad con certificados cortos, y Cosign verifica attestations in-toto contra políticas. Así, el gate pregunta no solo “¿esta imagen está firmada?”, sino “¿este digest vino del commit aprobado, por workflow permitido, con SBOM y review exigidos?”
| Evidencia | Qué prueba | Qué no prueba | Gate de verificación |
|---|---|---|---|
| Registro de tarea | Por qué comenzó, quién delegó y qué podía hacer el agente. | Que el código es correcto o seguro. | Exigir tarea aprobada, permisos limitados y owner. |
| Manifest de código generado | Qué superficies y tools involucraron generación. | Que toda influencia es conocida. | Exigir disclosure en archivos y dependencias de alto riesgo. |
| Review del PR | Qué humanos y checks aceptaron source. | Que el artefacto posterior coincide con source. | Protected branches, required checks, CODEOWNERS y excepciones. |
| Procedencia SLSA | Dónde, cuándo y cómo se construyó el artefacto. | Por qué source fue creado o aprobado. | Verificar builder, source SHA, parámetros y digest. |
| Attestation SBOM | Qué componentes declarados están en el artefacto. | Que los componentes sean seguros o completos. | Licencia, vulnerabilidad, política y allowlist. |
| Firma y deployment | Identidad ligada al artefacto y dónde se desplegó. | Que runtime siga seguro. | Admission policy, digest pinning, aprobación y monitoreo. |
Evidencia que nadie verifica es documentación, no control. Reglas de PR exigen evidencia de source. Builders confiables emiten procedencia y SBOM. Registries preservan digests y firmas. Admission rechaza artefactos sin cadena aprobada o con excepciones vencidas.
La verificación también necesita failure modes. Si storage de procedencia cae, ¿producción para? ¿Qué ruta de emergencia existe? ¿Quién aprueba, por cuánto tiempo y qué evidencia se completa después? La ruta de excepción forma parte de la supply chain.
Construiría un ledger de procedencia indexado por PR, commit y artifact digest. Uniría tarea y agente, manifest, reviews, checks, SBOM, SLSA, firmas, storage, deployments e incidentes runtime.
La vista principal respondería en ambos sentidos: desde artefacto en producción, volver a tarea y sesión del agente; desde agente o tool comprometida, encontrar todos los PRs, artefactos y deployments afectados.
La generación con IA no debilita el valor de la procedencia; extiende la cadena que debe probarse. Preserva intención y evidencia de generación antes del commit, luego usa builds confiables, SBOMs, attestations, firmas y deployments para mantener esa evidencia ligada a producción.
Artículo sobre procedencia de software supply chain para pull requests generados con IA, conectando tarea, agente, modelo, tools, diff, review, commit, SBOM, SLSA, firmas, artefacto y deployment.