1. Identificar exatamente o que vai executar
Uma release precisa de uma identidade de artefacto, não apenas de um nome legível. No exemplo fictício de um processador de ficheiros, regista o digest da imagem, a versão em produção, o relatório de análise e a decisão de promoção. Uma tag pode apontar para outro conteúdo quando a configuração permite alterações. Em ECR configurado como IMMUTABLE sem exclusões, tentar reutilizar uma tag existente falha. A solução operacional proposta é produzir um novo artefacto identificado e promover essa versão pelo processo aprovado. Não alteres a configuração global de tags só para ultrapassar uma falha pontual no pipeline. Ao investigar um incidente, confirma que o relatório citado corresponde ao artefacto realmente executado, incluindo diferenças entre ambientes e versões mantidas para rollback.
2. Delimitar análise de imagens
Enhanced scanning inclui pacotes suportados do sistema operativo e das linguagens. Continuous scanning permite nova análise quando surgem CVEs relevantes, enquanto scan on push corresponde à modalidade de análise no envio. Se filtros das duas modalidades abrangem o mesmo repositório, continuous prevalece. Um repositório sem correspondência não fica automaticamente coberto; scans manuais enhanced não são um atalho para corrigir essa exclusão. No handover, apresenta o conjunto de repositórios esperado e a configuração efetiva de cada um. Quando faltam findings, distingue ausência de vulnerabilidades identificadas de ausência de execução. A proposta de comparar o inventário de produção com o inventário analisado é um controlo operacional original, que deve ter responsável e frequência adequados ao risco da aplicação.
3. Investigar perda de cobertura
SCAN_ELIGIBILITY_EXPIRED não significa que uma vulnerabilidade foi corrigida. Verifica o motivo de perda de elegibilidade e o que é necessário para obter evidência atual do artefacto relevante. Imagens ARCHIVED não são analisadas; regressar a ACTIVE desencadeia nova análise. Nas durações de rescan, identifica explicitamente se foi escolhido last pull ou last in use e considera também a janela de push. Um relatório de utilização não substitui automaticamente a condição de pull de uma configuração que usa esse modo. Evita pressupor o mesmo default para todas as contas. O exercício local distingue cobertura desconhecida, análise atual com findings e ausência de findings no âmbito analisado. Nenhum desses resultados constitui autorização automática de release; a aceitação continua a exigir contexto e responsabilidade.
4. Escolher o efeito da assinatura
A assinatura Lambda verifica integridade e confiança no deployment. Adicionar a configuração não interrompe retroativamente código antigo sem assinatura. As layers adicionadas também precisam de um perfil permitido, e esta funcionalidade não se aplica a funções empacotadas como container images. Para falhas de validade temporal, perfil ou revogação, Warn permite deployment com aviso; Enforce bloqueia. O teste de integridade compara o pacote com a assinatura. Não estendas a regra de Warn a qualquer falha sem confirmar o contrato. No projeto, separa o responsável por assinar, a decisão de política e a aprovação de exceções. Uma assinatura válida demonstra propriedades diferentes de uma análise de dependências: o pacote aprovado ainda pode conter uma biblioteca vulnerável.
5. Comparar cobertura Lambda com produção
Inspector standard scanning procura vulnerabilidades nas dependências; code scanning acrescenta análise do código próprio e requer standard ativo. Confirma suporte do runtime, exclusões e atividade recente. A análise documentada abrange $LATEST, pelo que um resultado limpo nessa versão não demonstra o estado de outra versão publicada usada pelo alias de produção. Funções sem invocação ou alteração nos últimos 90 dias ficam automaticamente excluídas. Não invoques uma função desconhecida só para alterar esse indicador; primeiro compreende os seus efeitos e define um ensaio autorizado. Pede ao responsável da aplicação uma correspondência entre o artefacto analisado e o promovido. A lacuna de cobertura deve aparecer no reporting com uma ação concreta, não escondida num total agregado de zero findings.
6. Tratar findings e entregar evidência utilizável
Um finding de código pode incluir um trecho com credenciais incorporadas. Antes de o colar num ticket partilhado, limita acesso e remove dados sensíveis; preserva evidência suficiente no local adequado à investigação. Uma sugestão de correção gerada pelo serviço também precisa de revisão e testes funcionais. Compilar não demonstra que pagamentos, reconciliação ou tratamento de erros continuam corretos. Prepara uma decisão que identifique artefacto, cobertura, findings relevantes, tratamento, responsável e prazo. Num release meeting, explica separadamente confiança da assinatura, análise de vulnerabilidades e comportamento funcional. O resumo da aula é uma cadeia de evidência com limites declarados. Se uma etapa não foi demonstrada, documenta a lacuna e a decisão de risco sem inventar uma certificação automática de segurança do pacote.
# Original fictional evidence triage, not an Inspector eligibility engine.
# No credentials, network calls, or deployments.
def evidence(scan_digest, running_digest, covered, findings):
if scan_digest != running_digest:
return "artifact-mismatch"
if not covered:
return "coverage-unknown"
if findings:
return "findings-need-treatment"
return "no-findings-in-analyzed-scope"
assert evidence("a", "b", True, []) == "artifact-mismatch"
assert evidence("a", "a", False, []) == "coverage-unknown"
assert evidence("a", "a", True, ["CVE-example"]) == "findings-need-treatment"
assert evidence("a", "a", True, []) == "no-findings-in-analyzed-scope"
assert evidence("a", "b", False, []) == "artifact-mismatch"
print("five artifact-evidence cases passed; no release was authorized")
Uma imagem em produção perdeu elegibilidade de scanning. O gestor pede evidência atual para esse digest antes de encerrar o risco.
Armadilhas comuns
Assinatura como ausência de CVEs; Warn como bloqueio; zero findings como cobertura; $LATEST como qualquer versão de produção.
Tópicos relacionados: Resposta a incidentes · Aceitação e passagem a RUN
Confirma identidade, cobertura e efeito dos controlos antes de usar um indicador para aceitar a release.
Referência: ECR enhanced scanning · SCS-C03