Um artefato assinado prova qual workflow construiu um commit. Sozinho, não explica por que um agente criou aquele commit, qual autoridade iniciou a tarefa, quais tools influenciaram o diff ou qual humano aceitou o resultado.
SLSA define proveniência como informação verificável sobre onde, quando e como um artefato foi produzido. Artifact attestations do GitHub conectam artefato a repositório, commit SHA, workflow e ambiente de build. Esses controles são essenciais, mas um PR gerado por IA adiciona outra pergunta: como a mudança de source foi produzida?
A resposta não deve ser um rótulo vago “AI-assisted”. Um registro útil conecta tarefa aprovada, principal responsável, identidade do agente, modelo e tools, contexto recuperado, arquivos gerados, tentativas, testes, reviews e commit final. A proveniência de build continua a cadeia até o artefato.
Rótulos de IA devem ajudar review e incident response, não criar binário falso entre “código humano” e “código de IA”. Humanos usam autocomplete, clientes gerados, migrations, templates e agentes no mesmo PR. Registre quais arquivos ou hunks foram gerados ou transformados, qual sistema fez isso e qual humano assumiu responsabilidade.
O manifest também captura dependências e contexto externo introduzidos. Se o código copiou padrão inseguro de documentação ou adicionou pacote comprometido, investigadores precisam reconstruir a influência sem armazenar prompts sensíveis para sempre.
SBOM descreve componentes. Proveniência descreve como artefato foi produzido. Assinatura liga identidade a digest ou attestation. Review explica por que source foi aceito. Deployment metadata diz onde roda. Nenhum substitui os demais.
GitHub gera attestations de build e SBOM. Sigstore suporta assinatura baseada em identidade com certificados curtos, e Cosign verifica attestations in-toto contra políticas. Assim, o gate pergunta não apenas “esta imagem está assinada?”, mas “este digest veio do commit aprovado, pelo workflow permitido, com SBOM e review exigidos?”
| Evidência | O que prova | O que não prova | Gate de verificação |
|---|---|---|---|
| Registro da tarefa | Por que começou, quem delegou e o que o agente podia fazer. | Que o código é correto ou seguro. | Exigir tarefa aprovada, permissões limitadas e owner. |
| Manifest de código gerado | Quais superfícies e tools envolveram geração. | Que toda influência é conhecida. | Exigir disclosure em arquivos e dependências de alto risco. |
| Review do PR | Quais humanos e checks aceitaram source. | Que o artefato posterior corresponde ao source. | Protected branches, required checks, CODEOWNERS e exceções. |
| Proveniência SLSA | Onde, quando e como artefato foi construído. | Por que source foi criado ou aprovado. | Verificar builder, source SHA, parâmetros e digest. |
| Attestation SBOM | Quais componentes declarados estão no artefato. | Que componentes são seguros ou completos. | Licença, vulnerabilidade, política e allowlist. |
| Assinatura e deployment | Identidade ligada ao artefato e onde foi implantado. | Que runtime continua seguro. | Admission policy, digest pinning, aprovação e monitoramento. |
Evidência que ninguém verifica é documentação, não controle. Regras de PR exigem evidência de source. Builders confiáveis emitem proveniência e SBOM. Registries preservam digests e assinaturas. Admission rejeita artefatos sem cadeia aprovada ou com exceções expiradas.
A verificação também precisa de failure modes. Se storage de proveniência cair, produção para? Qual caminho emergencial existe? Quem aprova, por quanto tempo e qual evidência será preenchida depois? O caminho de exceção faz parte da supply chain.
Eu construiria um ledger de proveniência indexado por PR, commit e artifact digest. Ele uniria tarefa e agente, manifest, reviews, checks, SBOM, SLSA, assinaturas, storage, deployments e incidentes runtime.
A visão principal responderia nos dois sentidos: partindo do artefato em produção, voltar à tarefa e sessão do agente; partindo de um agente ou tool comprometida, encontrar todos os PRs, artefatos e deployments afetados.
Geração por IA não enfraquece o valor da proveniência; estende a cadeia que deve ser provada. Preserve intenção e evidência de geração antes do commit, depois use builds confiáveis, SBOMs, attestations, assinaturas e deployments para manter essa evidência ligada à produção.
Artigo sobre proveniência da software supply chain para pull requests gerados por IA, conectando tarefa, agente, modelo, tools, diff, review, commit, SBOM, SLSA, assinaturas, artefato e deployment.