ATALAIAPasso 1Escolher os scanners
À medida da sua stack, open source primeiro quando é suficientemente bom.
ATALAIATypeScript e Terraform. Scanners open source cobrem a maior parte.
DEV LEADJá pagamos um. Ninguém olha para ele.
Sai da salaSAST, SCA, segredos, IaC, contentores
Passo 2Ligá-los ao tapete
No PR e no pipeline, com resultados onde os devs já olham.
ATALAIAOs resultados vão para o PR, onde já olham. Não para um portal à parte.
PROGRAMADORAssim vejo-o antes da revisão, não uma semana depois do merge.
Sai da salaResultados no PR, não num portal
Passo 3Afinar o ruído
Suprimir o que não se aplica, escrever regras para o que se aplica.
PROGRAMADORHá 4,812 findings abertos. Parei de ler ao vigésimo.
ATALAIAA maioria são ficheiros de teste e uma regra que não encaixa na vossa framework. Saem.
ATALAIASobram 74, e todos são reais.
Sai da sala4,812 findings → 74 que se aplicam
Passo 4Decidir o que bloqueia
Uma lista curta e acordada de findings que param um build.
DEV LEADO que é que realmente para um merge?
ATALAIASegredos ativos, CVEs críticos com correção, e quatro regras que acordámos. O resto avisa.
PROGRAMADORUm segredo apanhado antes do merge. Desse gosto.
Sai da salaLista de bloqueio: 6 regras
- ATALAIA
- PLATAFORMA
- DEV LEAD
- PROGRAMADOR