⚠ Em construção — a documentação está pronta; o código está em migração e será publicado em breve.
Template de repositório com segurança rodando no pull request: se a mudança introduz segredo, dependência com CVE conhecida ou padrão inseguro, o merge trava antes da revisão humana.
| Etapa | Ferramenta | Bloqueia o PR? |
|---|---|---|
| Análise estática | Semgrep | sim, em severidade alta |
| Segredos versionados | Gitleaks | sim, sempre |
| Dependências e imagem | Trivy | sim, em CRITICAL |
| Dependências novas no PR | Dependency Review | sim, em alta |
| Infraestrutura como código | Checkov | alerta |
Todos publicam SARIF, então os achados aparecem na aba Security do repositório em vez de ficarem enterrados no log.
- Copie
.github/workflows/security.ymlpara o seu repositório - Ajuste os limiares em
.semgrep.ymletrivy.yaml - Ative Require status checks to pass na proteção do branch principal
Por que bloquear só em alta e crítica. Pipeline que reprova tudo é desligado na segunda semana. O objetivo é que a trava seja rara e sempre justificada.
Por que SARIF em vez de comentário no PR. O comentário se perde; o SARIF vira histórico, permite marcar falso positivo e some quando a falha é corrigida.
Por que Gitleaks bloqueia sempre. Segredo versionado não tem severidade baixa — depois de entrar no histórico, precisa ser rotacionado de qualquer forma.
Regra que não se aplica ao seu contexto entra em .semgrep.yml com justificativa escrita. Supressão sem motivo documentado é dívida de segurança.