Deploy para decisão executiva · Capítulo 15 de 20 · 40 min
Proveniência prova origem, não inocência
O que o selo de proveniência que o fornecedor exibe realmente garante, e onde exatamente ele para de garantir?
Este capítulo faz parte do curso gratuito Deploy para decisão executiva.
Escrever onde fica o portão humano entre a esteira e a produção, com aprovador, evidência exigida, tempo máximo de espera e o nível de garantia de build cobrado do fornecedor.
- Enunciar em uma frase o que a atestação de proveniência prova e o que ela não prova.
- Distinguir o nível de garantia de build que o mercado entrega do nível que barra este ataque.
- Definir o portão humano na fronteira de publicação, com aprovador, evidência e prazo.
Em linguagem simples
Proveniência é um recibo assinado que acompanha o artefato e diz onde ele foi construído, por qual esteira, a partir de qual código. A assinatura é criptográfica, então adulterar o recibo é inviável. Por isso ele costuma ser vendido, e comprado, como se fosse um selo de segurança.
O recibo é honesto e responde a uma pergunta específica: de onde isto veio. Ele não responde à pergunta que o comitê acha que está comprando, que é se o conteúdo é limpo. Em 2026 houve dois casos em que artefatos maliciosos circularam com recibo perfeitamente válido, porque nasceram dentro da esteira legítima.
- 01O recibo é emitido pela esteira, não pelo conteúdo. Quem assina é a identidade da esteira no momento da construção. Se o atacante controla a esteira ou consegue usar a identidade dela, o recibo sai válido para um artefato envenenado.
- 02Existem níveis de garantia, e o mercado entrega o intermediário. O nível corrente comprova a origem. O nível superior exige isolamento entre construções e que a credencial de assinatura seja inalcançável de dentro da construção. É o superior que barra o ataque de 2026.
- 03Verificar o recibo é obrigatório e insuficiente. Não verificar deixa passar o falsificador amador. Verificar apenas não detém quem sequestrou a esteira legítima. São dois controles diferentes para dois atacantes diferentes.
- 04O freio que falta é humano e custa minutos. Nos incidentes de 2026 a detecção externa levou de vinte a trinta minutos. Um portão de aprovação humana na fronteira de publicação converte um incidente distribuído em um incidente contido.
Glossário rápido
Atestação de proveniência
Documento assinado que registra onde e a partir do quê o artefato foi construído. Prova origem, não qualidade nem inocência do conteúdo.
Nível de garantia de build
Escala que descreve o quanto o processo de construção é resistente a adulteração. O nível intermediário exige registro de origem; o superior exige isolamento entre construções e credencial de assinatura fora do alcance do código construído.
Portão de publicação
Ponto em que a automação para e uma pessoa autorizada aprova a ida para produção, com evidência anexada e segundo fator.
Confusão mais comum: Ler a existência da atestação como resultado de uma auditoria de conteúdo. Ela é o equivalente a um carimbo de origem, não a um laudo de análise. Um produto pode ter origem impecavelmente documentada e conter exatamente aquilo que não deveria conter.
Explique em voz alta: Explique a alguém do jurídico, em duas frases, o que a sua empresa passa a saber quando um artefato traz atestação de proveniência válida e o que continua sem saber.
O recibo é verdadeiro, e responde a outra pergunta
Proveniência de artefato é uma boa ideia, bem executada. A esteira de construção assina um documento que diz de qual código aquele artefato saiu, em qual máquina, sob qual identidade. A assinatura é criptográfica e a verificação é automatizável. Nada disso é marketing.
O problema aparece na tradução para a linguagem do comitê. Entre a frase técnica, este artefato foi construído por esta esteira a partir deste código, e a frase que a diretoria escuta, este artefato é seguro, existe a distância entre origem e conteúdo, e é ela que limita o que a empresa pode afirmar por escrito.
Em 15 de maio de 2026 o projeto que define a escala de garantia de build publicou a análise do ataque ocorrido quatro dias antes e registrou o desconforto sem rodeio: os 84 arquivos maliciosos carregavam atestação criptograficamente válida, porque o atacante assinou com a prova de identidade legítima extraída da memória do processo da máquina de construção. A proveniência funcionou perfeitamente. Ela registrou, com fidelidade, que o malware nasceu no pipeline oficial.
Em 14 de julho de 2026 o padrão se repetiu com outro projeto: nenhum token roubado, publicação pelo workflow legítimo, atestação válida. Dois casos em dois meses. Para quem decide, a conclusão prática é uma frase que precisa entrar no documento com essas palavras: a proveniência prova onde o artefato foi construído e não prova que ele seja limpo.
O carimbo de origem no lacre da caixa
Um frigorífico exporta carne com lacre, número de lote e carimbo de origem. O carimbo é autêntico, o lacre é íntegro e a rastreabilidade é exemplar: em quinze minutos se descobre de qual abatedouro, de qual turno e de qual lote veio cada caixa. Tudo isso continua verdadeiro no dia em que alguém, dentro do abatedouro, coloca na caixa o que não deveria. O lacre vai se fechar sobre o conteúdo errado, com carimbo autêntico e rastreabilidade impecável.
Rastreabilidade e inspeção são controles distintos, contra ameaças distintas. Comprar o primeiro achando que se comprou o segundo é o erro que se paga no dia em que a ameaça vem de dentro.
O que cada nível de garantia de build exige, e qual deles barra o ataque de 2026
Descrição conforme a análise oficial publicada em 15 de maio de 2026. A coluna da direita é o que decide a conversa com o fornecedor: exigir o nível é diferente de exigir a existência da atestação.
| Nível | O que exige | O que prova | Barra o ataque de 11/05/2026 |
|---|---|---|---|
| Sem atestação | Nada | Nada sobre a origem do artefato | Não |
| Nível intermediário, entregue hoje pelo registro de pacotes | Construção em serviço hospedado, com registro de origem assinado e verificável | De qual código e de qual esteira o artefato veio | Não. Não exige isolamento entre construções nem que a credencial de assinatura seja inalcançável de dentro da construção |
| Nível superior | Isolamento entre construções, impossibilidade de uma construção injetar entradas falsas no cache usada por outra e credencial de assinatura fora do alcance do código construído | Que a origem registrada resiste a um atacante com código executando dentro da construção | Sim, nos dois mecanismos que o ataque usou |
Evidência pública
Caso documentado: atestação válida em 84 arquivos maliciosos
Projeto SLSA, análise do incidente de 11 de maio de 2026
A análise oficial publicada em 15 de maio de 2026 examinou o comprometimento de 42 pacotes ocorrido quatro dias antes e concluiu que os 84 arquivos maliciosos carregavam atestação de proveniência criptograficamente válida. O atacante assinou usando a prova de identidade legítima da esteira, extraída da memória do processo da máquina de construção.
- Os 84 arquivos maliciosos passaram na verificação de proveniência.
- A assinatura foi feita com a identidade legítima da esteira, obtida por leitura da memória do processo.
- A proveniência do registro atinge o nível intermediário de garantia de build.
- O nível intermediário não exige isolamento entre construções nem que a credencial de assinatura seja inalcançável de dentro da construção; só o nível superior exige as duas coisas.
Exigir atestação é insuficiente como cláusula de contrato. O que se exige é o nível declarado, com evidência de isolamento de construção, e ainda assim se mantém um freio humano na fronteira de publicação, porque o nível superior reduz a probabilidade e não elimina a categoria.
Análise publicada pelo próprio projeto que define a escala, o que a torna a fonte primária sobre a fronteira de cada nível.
Modelo operacional
O portão humano: quatro campos que precisam estar escritos antes de existir
Portão sem definição escrita vira gargalo ou vira carimbo, e os dois desfechos são ruins. Os quatro campos abaixo transformam a ideia em procedimento com prazo, e é o prazo que impede o portão de ser contornado no primeiro dia de pressa.
- Quem aprova: Pessoa nomeada, com suplente, e segundo fator obrigatório no ato da aprovação. Nunca uma equipe, nunca um papel genérico do repositório. Exemplo: Dois aprovadores designados por produto, com escala publicada, para que a ausência de um não vire justificativa de dispensa.
- Qual evidência precisa estar anexada: O aprovador precisa ter na tela o que sustenta a decisão, ou a aprovação vira carimbo. Sem lista fixa de evidência, o portão gera registro de aprovação sem exame, que é pior do que não ter portão. Exemplo: Diferença entre a versão atual e a anterior, resultado da verificação de proveniência, inventário de componentes do artefato e a lista de dependências que mudaram desde a última publicação.
- Qual o tempo máximo de espera aceito: O prazo protege o portão. Sem ele, a primeira publicação urgente que ficar parada vira o argumento definitivo para desligar o controle inteiro. Exemplo: Duas horas em horário comercial e quatro horas fora dele, com escalonamento automático para o suplente quando o prazo estourar.
- Em que casos o portão pode ser dispensado: A dispensa precisa estar escrita antes de ser necessária, com quem autoriza e qual registro fica. Exceção improvisada sob pressão nunca é registrada, e o que não é registrado não aparece na apuração. Exemplo: Reversão para uma versão anterior já publicada e aprovada dispensa o portão; publicação de versão nova, nunca, inclusive em incidente.
O portão custa minutos e compra a diferença entre um incidente distribuído e um incidente contido: nos casos de 2026 a detecção externa levou de vinte a trinta minutos, prazo dentro do qual um artefato retido não teria alcançado nenhum cliente.
Guardrail
Duas frases do curso legado que precisam sair do vocabulário da empresa
As duas eram boas práticas defensáveis em 2024 e viraram passivo depois dos ataques de 2026. Corrigi-las custa uma conversa e evita que a empresa opere com um mapa que já não descreve o território.
- Automatize tudo, nenhum passo manual entre o envio do código e a produção, passa a ser: automação completa até a fronteira de publicação, com portão humano e segundo fator exatamente nessa fronteira.
- Segredos nunca aparecem nos registros porque o provedor os mascara automaticamente passa a ser: o mascaramento cobre o texto exato do segredo nos registros e é irrelevante diante de leitura direta da memória do processo, que foi o vetor de maio de 2026.
- A verificação de atestação continua obrigatória, e o documento diz por escrito que ela prova origem e não inocência.
- A cláusula com o fornecedor cobra nível de garantia de build declarado, com evidência de isolamento entre construções, e não a mera existência de atestação.
- Existe registro do que o aprovador viu no momento em que aprovou, e não apenas de que aprovou.
Rotina real
A aprovação de publicação numa terça-feira comum
Aprovador designado de publicação do produto principal da Nortis · Duas janelas diárias de aprovação, às 10h e às 16h, com escalonamento automático para o suplente quando o prazo declarado estourar.
Situação: A esteira concluiu a construção de uma versão nova e o artefato está retido na fronteira de publicação, aguardando aprovação humana com segundo fator.
Entradas: Diferença em relação à versão anterior, resultado da verificação de proveniência, inventário de componentes do artefato e a lista de dependências que mudaram desde a última publicação.
Processo: Conferir se alguma dependência entrou dentro da janela de quarentena; verificar se a diferença corresponde ao que foi revisado; confirmar que a origem registrada aponta para o ramo esperado; aprovar com segundo fator ou recusar com motivo escrito.
Saída: Publicação liberada ou recusada, com registro do que estava na tela no momento da decisão, não apenas de que houve decisão.
Verificação humana: A recusa precisa ser tão barata quanto a aprovação. Se recusar custar uma reunião e uma justificativa longa, o portão vira carimbo em duas semanas, e ninguém vai perceber que virou.
Como se mede: Tempo mediano de espera no portão e número de recusas por trimestre. Zero recusa em trimestres seguidos é sinal de carimbo, não de qualidade.
Onde o freio existe hoje: estágio de publicação e ambiente com aprovador
Para quem decide
Camada de execução · Para quem configura a esteira. Quem decide precisa saber apenas que o freio existe, custa minutos e é configurável nos dois lugares. · opcional para quem só decide
O portão humano deixou de ser desenho conceitual e virou recurso disponível em dois pontos do stack. No registro de pacotes existe publicação em estágio desde a atualização de documentação de 20 de maio de 2026, e na esteira existe ambiente protegido com revisores obrigatórios. Configurar os dois é trabalho de minutos e não exige ferramenta de terceiro.
Para quem executa
- 01No registro de pacotes, npm stage publish envia a versão para uma área de espera e não exige segundo fator. O identificador do estágio sai de npm stage list, a inspeção que sustenta a evidência do aprovador sai de npm stage view, e a liberação exige npm stage approve com o identificador e com segundo fator. Requer interface de linha de comando 11.15.0 ou superior e ambiente de execução 22.14.0 ou superior, e o pacote já precisa existir no registro.
- 02Na esteira, o ambiente protegido com revisores obrigatórios retém o trabalho de publicação até que uma pessoa autorizada aprove, com registro de quem aprovou e quando.
- 03O prazo máximo de espera precisa existir como escalonamento operacional, com suplente acionado, e não como configuração que libera sozinha ao expirar.
- 04Desde 26 de junho de 2026 o provedor emite credencial de cache somente leitura para eventos que podem ser disparados sem permissão de escrita, o que fecha na plataforma o vetor usado em maio. O efeito colateral é perda de aproveitamento de cache e mais minuto de máquina pago, e a correção é separar o trabalho que grava cache para um gatilho confiável.
Trabalho de publicação retido em ambiente com revisores obrigatórios. Recurso de plataforma verificado em 24/07/2026.
# .github/workflows/publicar.yml (trecho)
jobs:
publicar:
needs: [construir, testar]
runs-on: ubuntu-latest
# O ambiente concentra o portão: revisores obrigatórios e segredos
# de produção ficam ligados a ele, e não ao repositório inteiro.
environment:
name: producao
url: https://exemplo.com.br
permissions:
contents: read
# Nenhuma permissão de escrita concedida por padrão.
steps:
- name: Publicar em produção
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
run: vercel deploy --prod --token "$VERCEL_TOKEN"
# Publicação de pacote com portão no próprio registro:
# npm stage publish # envia para a área de espera, sem segundo fator
# npm stage list <pacote> # devolve o identificador do estágio
# npm stage view <stage-id> # inspeção que sustenta a evidência do aprovador
# npm stage approve <stage-id> # aprovação, esta sim com segundo fator
# Requisitos verificados em 24/07/2026:
# interface de linha de comando 11.15.0 ou superior
# ambiente de execução 22.14.0 ou superior
# o pacote já precisa existir no registroConfigurar o ambiente protegido e deixar os segredos de produção também no nível do repositório anula o controle: qualquer trabalho, em qualquer ramo, continua conseguindo ler a credencial sem passar pelo portão. Os segredos de produção precisam existir apenas no ambiente que exige aprovação.
Caso Nortis · Semana 10
O fornecedor exibe atestação de proveniência para cada artefato publicado. O time trata isso como prova de que o artefato é limpo.
Nos dois incidentes mais graves de 2026, de 11 de maio e de 14 de julho, os artefatos maliciosos saíram com atestação criptograficamente válida, porque foram assinados pelo pipeline legítimo. A proveniência prova a origem, não a inocência.
Escrever onde fica o portão humano entre o pipeline e a produção: quem aprova, qual evidência precisa estar anexada, tempo máximo de espera aceito e em que casos o portão pode ser dispensado.
Exemplo trabalhado
O selo que o fornecedor exibiu, e a pergunta que faltava
CISO da Nortis, revisando a proposta do time de plataforma
A proposta do time era substituir a revisão manual de dependências pela verificação automática de atestação de proveniência. O argumento parecia forte: assinatura criptográfica, verificação automatizada, nenhum passo humano.
Passo a passo do exemplo
Passo 1: Perguntar qual nível de garantia está sendo entregue
A pergunta que muda a conversa é qual nível de garantia de construção a atestação representa. A proveniência do registro de pacotes atinge o nível intermediário, que registra a origem de forma confiável e explicitamente não exige isolamento entre construções nem que a credencial de assinatura seja inalcançável de dentro da construção.
Passo 2: Confrontar com o que aconteceu em maio
Na análise oficial publicada em 15 de maio de 2026 sobre o ataque de 11 de maio, os 84 arquivos maliciosos carregavam atestação criptograficamente válida. O atacante assinou com a prova de identidade legítima extraída da memória do processo da máquina de construção. O controle proposto teria aprovado todos eles, um por um, com sinal verde.
Passo 3: Repetir o teste com o caso de julho
Em 14 de julho de 2026, no caso do projeto de especificação de APIs, nenhum token foi roubado e os pacotes saíram pelo pipeline legítimo, também com atestação válida. Dois casos em dois meses com o mesmo padrão descartam a hipótese de acidente isolado.
Passo 4: Definir o que fica no lugar
A verificação de atestação continua, porque barra o falsificador amador e custa pouco. Ao lado dela entram duas coisas que ela não faz: exigir do fornecedor o nível superior de garantia, com evidência de isolamento, e colocar um portão humano com segundo fator na fronteira de publicação, com tempo máximo de espera declarado para não virar gargalo.
Resultado: A proposta original é aprovada com dois acréscimos e uma correção de expectativa por escrito. A frase que entra no documento é curta: a atestação prova onde o artefato nasceu e não prova que ele seja limpo.
Continua sob responsabilidade humana: O portão humano não é infalível e depende de quem aprova ter evidência útil na tela. Aprovar sem olhar é pior que não ter portão, porque cria registro de aprovação sem exame. A definição precisa dizer qual evidência é obrigatória e o que autoriza recusar, e o comitê precisa aceitar que às vezes a publicação vai esperar.
Exercício: escreva o portão antes de precisar dele
Exercício · 25 min
Passo 1: Nomeie dois aprovadores por produto, com escala publicada, e confirme que ambos têm segundo fator ativo.
Passo 2: Liste a evidência obrigatória que precisa estar na tela do aprovador, em no máximo quatro itens.
Passo 3: Defina o tempo máximo de espera em horário comercial e fora dele, e para quem o caso escala quando o prazo estourar.
Passo 4: Escreva a única hipótese de dispensa e quem autoriza, com o registro que fica.
Passo 5: Redija em uma frase, para o documento, o que a atestação de proveniência prova e o que ela não prova.
Passo 6: Escreva a cláusula que será levada ao fornecedor: nível de garantia de build declarado, com evidência de isolamento entre construções.
No fim você tem: Entregável: Definição escrita do portão de publicação com aprovadores nomeados, evidência obrigatória, prazo máximo, hipótese única de dispensa e a cláusula de nível de garantia a ser cobrada do fornecedor.
Laboratório de decisão
O time propõe trocar a revisão humana pela verificação automática de proveniência
A proposta chega bem construída: verificação automática de atestação em todo artefato, sem nenhum passo humano, com o argumento de que a assinatura criptográfica é mais confiável do que a atenção de uma pessoa às 18h de sexta.
A verificação automática de proveniência pode substituir o portão humano na fronteira de publicação?
- A. Sim. Assinatura criptográfica é objetiva e a revisão humana é falível e cara.: Adota um controle que teria aprovado, com sinal verde, os 84 arquivos maliciosos de 11 de maio de 2026 e os quatro pacotes de 14 de julho de 2026. Troca um controle falível por um controle que a ameaça corrente já contorna por desenho.
- B. Não. Manter apenas a revisão humana e dispensar a verificação automática por ser um selo enganoso.: Descarta um controle barato que barra o falsificador que não controla a esteira. A atestação é útil contra uma classe de atacante e inútil contra outra, e abandoná-la por decepção é jogar fora a parte que funciona.
- C. Manter os dois, com papéis declarados: verificação automática contra artefato de origem falsa, portão humano com segundo fator contra artefato de origem legítima e conteúdo comprometido.: Cobre as duas classes de atacante, com custo de minutos por publicação. Exige escrever a evidência obrigatória e o prazo máximo, sem os quais o portão degrada para carimbo em poucas semanas.
Recomendação: A terceira opção, com a frase sobre o limite da proveniência escrita no documento e o prazo de espera declarado.
A proposta do time está certa no diagnóstico e errada no escopo. A verificação automática é objetiva, barata e deve entrar, porque elimina uma classe inteira de atacante sem consumir atenção humana. O que ela não faz, e a análise oficial de 15 de maio de 2026 diz isso com todas as letras, é detectar artefato malicioso produzido pela esteira legítima, que foi o padrão dos dois piores casos do ano. Manter os dois controles com papéis explicitamente declarados evita a armadilha mais comum em segurança, que é substituir um controle por outro em vez de somar, com a justificativa de que o novo é mais moderno. O custo dessa decisão é medido em minutos por publicação, e o risco que ela endereça foi medido em milhões de descargas semanais.
Entregável do módulo: Definição escrita do portão humano entre a esteira e a produção: quem aprova com segundo fator, qual evidência precisa estar anexada, qual o tempo máximo de espera aceito, em que caso único o portão pode ser dispensado e qual nível de garantia de build será exigido do fornecedor, com evidência de isolamento entre construções.
- Eu digo em uma frase o que a atestação de proveniência prova e o que ela deixa de fora.
- Eu sei qual nível de garantia de construção o meu fornecedor entrega hoje e qual eu preciso exigir em contrato.
- Eu tenho aprovador nomeado, evidência obrigatória e prazo máximo escritos antes do próximo incidente.
Definido o portão, falta a pergunta mais desconfortável: quem, hoje, consegue abri-lo.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- CursoNode.js: JavaScript no Servidorsugerido pelo grafo4 capítulos de “Deploy para decisão executiva” usam conceitos apresentados em “Node.js: JavaScript no Servidor”.
- CursoGitHub: Controle de Versão do Zerosugerido pelo grafo3 capítulos de “Deploy para decisão executiva” usam conceitos apresentados em “GitHub: Controle de Versão do Zero”.
Depois, siga para
Conceitos deste capítulo
O mesmo assunto em outros cursos
- MCP para quem decideTirar lição dos incidentes que já aconteceramExaminar conexões de Tirar lição dos incidentes que já aconteceram
- Software e IA para executivosEvitar que a chave secreta vaze pelo código gerado por IAExaminar conexões de Evitar que a chave secreta vaze pelo código gerado por IA
- RAG em produçãoO documento que dá ordens ao seu sistemaExaminar conexões de O documento que dá ordens ao seu sistema
- Engenharia de Software para ExecutivosBlindar a cadeia de fornecedores do códigoExaminar conexões de Blindar a cadeia de fornecedores do código
Voltar ao capítulo anterior: Cada pacote instalado é um fornecedor sem contrato
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.
Capítulos vizinhos em Deploy para decisão executiva
- 13O segredo de vida longa que ainda não tem substituto
- 14Cada pacote instalado é um fornecedor sem contrato
- 15Proveniência prova origem, não inocência
- 16Quem aperta o botão, e onde fica o freio
- 17Reverter sem depender do painel que também caiu