Supply chain: SBOM, sigstore e dependency confusion

• Fora da AWS
• Rede e entrega
• Gestão e governança
• Conceito de arquitetura
• Segurança e identidade
• Compute

Repare que as três setas de ataque apontam para a construção, e não para o código que você escreve. É por isso que a defesa é sobre PROCEDÊNCIA — saber o que entrou e provar de onde veio — e não sobre revisar mais o próprio código.

1. 1 · O ataque entra pelo que você não escreveu. A maior parte do código publicado veio de dependências. Comprometer uma dependência popular alcança milhares de projetos sem tocar em nenhum deles.
2. 2 · Travar versão barata o suficiente para não ter desculpa. Instalar reproduzível — com arquivo de trava e resolução verificada — elimina a maior parte da confusão de nome e do pacote de nome parecido.
3. 3 · O inventário responde "eu uso isso?". Quando sai um aviso de vulnerabilidade, a diferença entre responder em minutos e em dias é ter a lista do que entrou em cada artefato.
4. 4 · Assinar prova origem, não qualidade. A assinatura garante que o artefato saiu da sua esteira e não foi alterado. Ela não diz que o código é bom — são perguntas diferentes.
5. 5 · Verificar na admissão é o que dá sentido a assinar. Assinar sem verificar é cerimônia. A verificação no momento de implantar é o ponto em que a assinatura vira controle.
6. 6 · Para time pequeno, três medidas cobrem muito. Arquivo de trava respeitado no CI, atualização automatizada com testes, e inventário gerado a cada construção. Nada disso exige plataforma nova.