← Back to list

DefectDojo: centralizando achados de segurança e mantendo histórico entre releases

No dia a dia, é comum a empresa rodar várias análises de segurança: pentest, SAST, SCA, scan de containers, IaC, infraestrutura, secrets… O…

Wallace Maia in nddtech · 2026-02-24 11:24 · 0 claps · 2.9 min read
#security #cloud-security #code-security #semgrep #tecnologia
Open on Medium ↗
Wiki topics: ☁️ · DevOps & Cloud 🔒 · Cybersecurity

DefectDojo: centralizando achados de segurança e mantendo histórico entre releases

No dia a dia, é comum a empresa rodar várias análises de segurança: pentest, SAST, SCA, scan de containers, IaC, infraestrutura, secrets… O problema é que cada ferramenta fala um “idioma” e entrega um relatório diferente. No fim, as vulnerabilidades ficam espalhadas em PDFs, dashboards e artefatos de pipeline, muitas vezes se repetem e viram um volume difícil de priorizar, acompanhar e comprovar evolução.

E é aí que surge um tipo de dúvida que parece simples, mas costuma ser bem trabalhosa de responder:

Quando não existe um lugar único para consolidar tudo, o histórico se perde, o time perde tempo comparando saídas de scanners e a confiança no processo cai.

Onde o DefectDojo entra

Uma das opções mais sólidas para endereçar esse cenário é o DefectDojo. Pense nele como um painel único para centralizar achados: em vez de cada scanner gerar um relatório isolado (e ninguém saber por onde começar), você consolida tudo em um lugar só.

Na prática, o DefectDojo:

  • importa resultados de várias fontes (SAST, DAST, SCA, container, IaC, secrets etc.)
  • organiza e reduz o ruído (duplicidades)

O ganho principal é visibilidade: fica mais fácil enxergar o que é mais crítico, quem é o responsável, em qual produto/ambiente está o risco e o que já foi resolvido.

O que você ganha na prática

Com isso, podemos:

  • Centralizar tudo em um único lugar, em vez de ficar analisando relatório por relatório;
  • Reduzir duplicidade e ruído, evitando que o mesmo problema apareça várias vezes como se fossem achados diferentes;
  • Priorizar com clareza, separando o que é crítico do que pode esperar;
  • Manter histórico por projeto e por versão, para saber o que entrou, o que foi tratado e o que continua pendente.

E, no dia a dia, isso se traduz em:

  • Visão única de vulnerabilidades por projeto/repositório;
  • Menos retrabalho com planilhas, PDFs e relatórios espalhados;
  • Correções mais certeiras, porque fica claro o que realmente importa e o que foi resolvido entre releases.

Relatórios de quais ferramentas eu consigo importar?

O DefectDojo suporta diversas integrações e formatos de importação. A lista oficial (mantida pela comunidade) está aqui:

DefectDojo — Ferramentas Suportadas

Como o DefectDojo é usado na prática

A forma mais comum de usar o DefectDojo no dia a dia é padronizar uma hierarquia e automatizar a entrada dos scans via CI/CD. Isso evita que o uso vire “manual demais” e garante consistência entre times.

1) Estrutura inicial (uma vez por organização/produto)

  1. Criar o Product Type Uma categoria que agrupa produtos por domínio/vertical (ex.: Cargo​, Elog​, IP​). Aqui, um padrão bem prático é usar o nome da vertical como Product Type, já que cada vertical pode ter vários repositórios.
  2. Criar o Product Aqui é o “alvo” real que você quer gerenciar (ex.: nddCargo​, nddElog​, nddIP​). Um padrão que costuma facilitar muito é definir o nome do Product igual ao nome do repositório no TFS/Azure DevOps (ou Git), porque a busca e o vínculo com o projeto ficam óbvios.

2) Ciclo de trabalho (por release, sprint ou período)

Como isso entra no CI/CD

O fluxo mais comum fica bem objetivo:

Considerações finais

O DefectDojo não “resolve segurança” sozinho, ele resolve um problema bem específico e muito comum: falta de centralização e rastreabilidade. Quando cada ferramenta gera um relatório isolado, o time perde tempo correlacionando achados, lidando com duplicidade e tentando provar evolução entre releases. Ao consolidar tudo em um único lugar, você transforma resultados soltos em dados concretos.

O maior ganho aparece quando o uso é consistente e automatizado. Padronizar a hierarquia (Product Type -> Product -> Engagement) e enviar os scans pelo CI/CD faz com que o histórico deixe de depender de memória, planilha ou artefatos de pipelines.

No fim, a ferramenta vira mais valiosa quando é tratada como parte do processo: menos ruído, mais previsibilidade e um backlog de segurança mais claro, alinhado com a realidade do desenvolvimento e com o ritmo de entregas do time.


메타데이터
post_id
b24ebeaa6899
slug
defectdojo-centralizando-achados-de-segurança-e-mantendo-histórico-entre-releases-b24ebeaa6899
url
https://making.ndd.tech/defectdojo-centralizando-achados-de-seguran%C3%A7a-e-mantendo-hist%C3%B3rico-entre-releases-b24ebeaa6899
canonical_url
https://making.ndd.tech/defectdojo-centralizando-achados-de-seguran%C3%A7a-e-mantendo-hist%C3%B3rico-entre-releases-b24ebeaa6899
author_url
https://medium.com/@wallacemaiadev
status
ok
fetched_at
2026-06-10 08:17:25