APRENDER. PRATICAR. EVOLUIR.1. Definir o que precisa de ser analisado
Numa release fictícia de uma API de fundos, a equipa exige análise de código, dependências, segredos e imagem de contentor. Começa por ligar cada requisito a um artefacto e a uma execução verificável. O código pode ser identificado pelo commit; a imagem pelo digest que será entregue. Um scan da branch por defeito não representa automaticamente o head de um PR ainda não integrado. O inventário de dependências também não substitui análise de código. Desenha uma pequena matriz com tipo de análise, candidato, ferramenta, configuração, resultado e decisão. Se um campo falta, regista a lacuna antes de resumir o estado. O comité precisa de compreender quais riscos foram avaliados e quais dependem de evidência adicional. Uma contagem elevada de verificações verdes não responde a essa pergunta sem informação sobre o respetivo âmbito.
2. Preservar a identidade dos resultados SARIF
Um monorepo pode analisar pagamentos e reporting separadamente com a mesma ferramenta. Dá uma identidade estável a cada conjunto de resultados, para não confundir substituição de uma análise com agregação de âmbitos distintos. A mesma ferramenta e categoria podem substituir resultados anteriores do commit; vários ficheiros com essa identidade numa única execução Actions constituem uma configuração inválida. Investiga também alertas que fecham e reaparecem sem alteração do código. Caminhos temporários diferentes e fingerprints ausentes podem impedir a ligação entre o mesmo problema em execuções sucessivas. Não resolvas isso mudando aleatoriamente ruleId ou categoria a cada run. Normaliza o mapeamento para a origem e mantém identidade consistente. Antes de concluir que o backlog cresceu, distingue novas falhas de duplicação na forma como os resultados são apresentados e acompanhados.
3. Separar ingestão, apresentação e completude
Receber um ficheiro não significa apresentar todos os seus resultados. Os limites SARIF incluem rejeição por excesso de dados e truncagem de conjuntos aceites. No exercício, o relatório original contém 6 000 resultados e a vista inclui apenas 5 000. A diferença de 1 000 requer reconciliação com a política de triagem, sem assumir que os omitidos são falsos positivos. Conserva o original e a ligação ao candidato; decide como tratar o volume e a qualidade dos resultados. Se o upload falha por esquemas de URI incompatíveis com a raiz da origem, falta evidência publicada, não há um resultado limpo. Corrige o mapeamento e confirma processamento. Uma anotação ausente no diff do PR também pode refletir regras de apresentação de localizações, pelo que a revisão deve consultar o conjunto de evidência adequado ao requisito.
4. Rever a árvore efetiva de dependências
Atualizar uma biblioteca direta pode alterar várias dependências transitivas. Revê o lockfile e a árvore resolvida, não apenas a linha modificada no manifesto. Confirma que os dados submetidos correspondem à revisão que estás a comparar. Se a submissão demora mais do que a revisão, pode surgir uma corrida com snapshots ausentes. Coordena a ordem das operações ou usa retries suportados, com limite e confirmação de completude. Uma espera fixa não demonstra que a submissão terminou. Define ainda quais âmbitos entram na política: ferramentas usadas apenas no build podem influenciar o artefacto produzido. Se a configuração só faz falhar runtime, o sucesso não demonstra a política sobre development. No handover, regista versões, origem dos dados e exclusões relevantes, para que a equipa seguinte saiba o que foi efetivamente analisado.
5. Interpretar os controlos de falha e licença
Um check obrigatório só impõe o resultado que a sua configuração produz. Se warn-only estiver ativo, uma vulnerabilidade acima do limiar pode continuar a produzir sucesso. Revê os inputs da action antes de atribuir o resultado a uma falha da proteção da branch. Mantém também separadas as condições de vulnerabilidade e licença. Na política fictícia desta aula, uma licença tem de estar identificada e aprovada. A action pode informar sobre licença desconhecida sem falhar, mas isso não satisfaz essa regra. Não preenchas a lacuna excluindo o pacote da análise. Encaminha a identificação e decisão para o responsável adequado. Tem em conta diferenças de versão e plataforma: os exemplos de configuração consultados mostram versões diferentes, e capacidades de licença em GitHub.com não devem ser assumidas em GitHub Enterprise Server.
6. Tratar segredos e exceções como decisões operacionais
Um segredo removido do ficheiro pode continuar válido no serviço que o aceita. Coordena substituição ou revogação, atualiza consumidores e procura utilização indevida nos registos relevantes. Evita prometer que fechar qualquer alerta revoga automaticamente qualquer credencial externa. Preserva evidência suficiente para distinguir recuperação do acesso, limpeza do código e fecho administrativo do alerta. As exceções precisam de separação semelhante: uma supressão técnica não é uma autorização sem prazo. No exemplo, uma exceção termina em setembro, mas o filtro permanece em outubro. A nova release exige reavaliação do componente, mitigação, responsável e prazo. Não alargues uma exceção específica a todos os componentes com a mesma severidade. A decisão deve permitir ao suporte saber o risco aceite, os limites e quando voltar a avaliar.
7. Confirmar cobertura antes de interpretar dashboards
Um conector saudável mostra que uma integração funciona dentro do seu âmbito; não demonstra que todos os candidatos, linguagens e tipos de análise estejam cobertos. Na funcionalidade agentless em preview documentada para Defender for Cloud, a branch por defeito é um limite importante. Confirma suporte e configuração antes de usar o resultado numa decisão sobre outro candidato. Em Azure DevOps, ativar uma funcionalidade também não substitui a execução da pipeline configurada. Com Advanced Security desativado, uma task pode não falhar enquanto os resultados ficam indisponíveis e não são retidos. Define verificações de presença, data e revisão dos resultados. Se falta uma delas, apresenta a lacuna no relatório em vez de preencher a célula com zero vulnerabilidades. Zero observado e ausência de observação sustentam decisões diferentes.
8. Aplicar uma revisão reproduzível à release
Usa os registos fictícios apresentados abaixo como exercício, não como um relatório real de scanner. Identifica três lacunas: revisão diferente, resultados por reconciliar e licença por identificar. Escreve a ação necessária, o responsável e a evidência que permitiria fechar cada uma. A solução não é concluir que o candidato é vulnerável só porque faltam dados; é reconhecer que as condições de aceitação ainda não foram demonstradas. Podes adiar a decisão ou obter a evidência em falta dentro da janela disponível. Na passagem para RUN, entrega ligações para relatórios integrais, identidade dos artefactos, configurações, limitações e exceções atuais. O resumo final deve ser curto mas rastreável. Uma pessoa que não acompanhou a pipeline deve conseguir compreender por que razão a equipa aprovou ou manteve pendente a release.
{
"fictional": true,
"candidateCommit": "candidate-8",
"requirements": [
"candidate-specific analysis",
"all findings accounted for",
"identified approved license"
],
"codeScan": {
"commit": "candidate-7",
"completed": true
},
"sarif": {
"commit": "candidate-8",
"rawResults": 6000,
"includedResults": 5000
},
"dependency": {
"commit": "candidate-8",
"package": "fictional-funds-parser",
"license": "unknown",
"actionSucceeded": true
}
}Um comité recebe um resumo verde de outra revisão, uma vista truncada e uma licença desconhecida. O exercício obriga a identificar a evidência concreta que falta antes de aceitar a release.
Armadilhas comuns
Confundir upload com análise; ignorar resultados truncados; usar evidência de outra revisão; prolongar exceções por supressão; tratar licença desconhecida como aprovada.
Tópicos relacionados: Rastreabilidade de artefactos e SBOM · Gestão de vulnerabilidades e exceções · Resposta a exposição de credenciais · Governance de release e handover
Uma decisão de segurança liga candidato, cobertura, resultados e tratamento do risco. O sucesso de uma ferramenta só é útil quando se compreende exatamente o que verificou.
Referência: SARIF support for code scanning · AZ-400 objectives 2026-07-27