APRENDER. PRATICAR. EVOLUIR.Definir o que a verificação tem de demonstrar
Uma entrega pode ter uma assinatura válida e continuar a falhar a política da organização. Começa por escrever os requisitos: qual o artefacto, qual a origem permitida, que testes são necessários e quem decide sobre exceções. Uma attestation liga um sujeito a afirmações assinadas sobre a sua produção. Não demonstra, por si, ausência de vulnerabilidades nem aprovação de risco. No exercício, a origem é confirmada, mas existe uma falha crítica que a política proíbe. O relatório deve conservar ambos os resultados, sem transformar o scanner num teste de assinatura ou a assinatura numa exceção. Esta separação ajuda APS a comunicar exatamente o que está confirmado e o que impede a entrega. Evita um único indicador verde que esconda critérios diferentes ou evidência ainda em falta.
Verificar o conteúdo que será consumido
A verificação deve incidir sobre os bytes que serão entregues. Se payment.tar é alterado depois da verificação, manter o nome não conserva a ligação à attestation anterior. Planeia a ordem dos passos para verificar o candidato final e impedir substituições posteriores não avaliadas. Para imagens, o nome completo identifica o repositório no registry e o digest identifica o conteúdo. Uma tag como release pode mudar e não substitui o digest produzido pelo build. Também não uses o commit Git como se fosse o digest da imagem: são objetos diferentes. Regista a relação entre código, build e sujeito entregue, com identificadores suficientes para investigação. Uma falha de correspondência não se resolve copiando o ficheiro de attestation para outra pasta ou renomeando o pacote.
Separar repositório chamador e workflow signatário
Quando um workflow reutilizável constrói e assina, o repositório ligado ao artefacto pode ser o chamador e o signatário pode estar noutro repositório. Uma política que permite apenas release.yml precisa de verificar essa identidade, além do âmbito de pesquisa. O exemplo de comando mantém dr-lab/funds como repositório associado e restringe o signatário ao workflow indicado em dr-lab/builders. Estes nomes são fictícios e devem ser substituídos por identidades autorizadas num ensaio real. Produzir JSON facilita inspeção, mas não acrescenta automaticamente a restrição de identidade. Um controlo só cumpre a política se comparar os campos adequados com valores esperados de uma fonte confiável. Não obtenhas o valor permitido do próprio artefacto que está a ser avaliado, pois isso faria qualquer origem apresentada parecer aceite.
Avaliar o tipo e a origem das afirmações
A verificação predefinida de proveniência não satisfaz automaticamente um requisito de SBOM assinado. Identifica o predicate esperado, verifica a ligação ao mesmo sujeito e avalia o inventário produzido. Mesmo dentro de uma attestation válida, nem todos os campos têm a mesma origem. O manual distingue dados certificados e timestamps verificados de metadata que pode ser controlada pelo workflow. Se testsPassed=true é um input livre do chamador, assinar esse valor não demonstra que houve testes. Revê como o produtor obtém os resultados, que inputs aceita e onde estão os relatórios. Um workflow reutilizável aprovado pode apoiar o controlo, mas o seu nome não substitui análise do comportamento. A pergunta operacional é se a evidência sustenta o critério concreto, com o âmbito e as limitações identificados.
Não inferir remediação a partir de um push aceite
Push protection e secret scanning têm finalidades relacionadas, mas a cobertura não é idêntica. Um segredo já detetado com alerta existente pode não voltar a ser bloqueado num novo push. O sucesso da operação não prova revogação da credencial nem fecho do incidente. Da mesma forma, deteção de passwords por AI não implica bloqueio no push ou verificação de validade para essa categoria. Consulta as capacidades aplicáveis e mantém controlos adequados à informação em causa. Durante triagem, usa identificadores do alerta, localização e responsável sem copiar o segredo para tickets ou logs. Se houve exposição real, trata a credencial com o responsável e confirma o resultado. Não uses a ausência de um novo bloqueio como evidência de que o risco desapareceu.
Resolver incerteza e respeitar a revisão de exceções
O estado unknown significa que a validade não está confirmada; não é sinónimo de inactive nem prova de falso positivo. Identifica o responsável e o mecanismo autorizado para esclarecer o estado sem aumentar exposição. A investigação deve registar o que foi confirmado e o que continua incerto. Quando delegated bypass está ativo, uma pessoa sem privilégio de bypass precisa de revisão dos responsáveis designados. Ter write access permite outras operações no repositório, mas não converte um pedido de exceção em aprovação. A justificação de falso positivo deve ser avaliada, não tomada como decisão automática. Também não uses atraso ou proximidade da janela como consentimento. Num contexto de gestão de projeto, apresenta a dependência e o impacto no prazo para que a decisão seja feita pela autoridade prevista.
Controlar obtenção e ciclo de vida dos ficheiros seguros
DownloadSecureFile executa no início do stage, independentemente da posição dentro do job. Um script colocado antes na lista não demonstra que validou o candidato antes do download. Usa fronteiras e controlos adequados ao requisito de acesso, incluindo os controlos do recurso quando aplicáveis. O caminho devolvido é local ao agente; transmiti-lo como texto para outro job não transporta o ficheiro. No fim do job, a tarefa elimina o download, mas isso não prova eliminação de cópias criadas pelo script ou de certificados importados num keystore. Identifica cada estado persistente e o seu ciclo de vida. Durante rotação, o conteúdo carregado não é editável no objeto existente. Planeia a transição para o novo recurso, confirmando referências, permissões e checks antes de retirar a versão anterior segundo o processo aprovado.
Decidir sobre um pacote assinado fora do processo aprovado
No caso final, debug.yml produziu uma attestation válida, mas a política aceita apenas release.yml e testes executados. O predicate contém uma afirmação do chamador sem relatório. A decisão é reter o candidato até obter evidência compatível com o critério. Uma reconstrução pelo processo aprovado é uma opção; um candidato existente também pode servir se cumprir identidade, bytes e testes. Escreve o que precisas de verificar antes de aceitar qualquer alternativa. O comando abaixo é um exemplo não executado e não fornece, sozinho, toda a evidência exigida. Não usa credenciais reais nem demonstra comportamento de uma conta cloud. Num ensaio autorizado, guarda versão da ferramenta, política aplicada, identificador do sujeito e resultados, distinguindo verificação criptográfica, avaliação de conteúdo e aprovação de entrega.
# Fictional identities and local artifact; example only, not executed.
# Verify the artifact before consuming it; do not modify it afterward.
gh attestation verify ./funds.tar \
--repo dr-lab/funds \
--signer-workflow dr-lab/builders/.github/workflows/release.yml \
--format json
# Assess required test/security evidence separately under the release policy.
Um pacote tem assinatura válida de debug.yml, mas a entrega exige release.yml e um relatório de testes ligado ao candidato. A assinatura confirma uma origem que ainda não cumpre a política.
Armadilhas comuns
Confundir assinatura com segurança, metadata declarada com testes, push aceite com segredo revogado e limpeza do download com eliminação de todas as cópias.
Tópicos relacionados: Identidade de artefactos e pipelines reutilizáveis · Resposta a exposição de credenciais · Permissões e controlos de recursos de deployment
Verifica o sujeito consumido, a origem exigida e o conteúdo da evidência. Trata incerteza e exceções explicitamente e controla cada cópia de material sensível.
Referência: Artifact attestations · AZ-400 objectives 2026-07-27