Diagnósticos (Pro)

Diagnósticos é um único registro de todas as tentativas que o DefectDojo faz para se comunicar com algo fora dele — e das tentativas que outros sistemas fazem para se comunicar com ele. Quando um ticket nunca aparece, um scan nunca é importado, ou um usuário não consegue fazer login, esta é a página que mostra o que aconteceu, quando, com qual configuração, e quem disparou a tentativa.

Diagnósticos é um recurso do DefectDojo Pro. Encontre-o em Connect > Diagnostics.

O que é registrado#

Uma linha é gravada por tentativa, vinda de todo subsistema que se comunica para fora do DefectDojo:

As linhas são gravadas ao lado do subsistema, nunca em seu lugar. Cada adaptador está vinculado ao registro de origem e é deliberadamente à prova de falhas: se a gravação de uma linha de diagnóstico gerar um erro, esse erro é engolido e a operação original continua normalmente. Por isso, o Diagnósticos nunca pode ser a causa de uma falha em um envio, importação ou login.

Como as linhas são indexadas pelo registro que as originou, salvar novamente um registro de origem atualiza a linha de diagnóstico existente em vez de criar uma duplicata. Uma tentativa é uma linha durante toda a sua existência, desde Queued, passando por Running, até o resultado final.

Campos de uma linha#

As quatro visualizações#

As abas acima da tabela são pontos de partida salvos, não filtros que você precisa reconstruir toda vez:

• Errors — falhas e timeouts. A primeira que você deve abrir.
• Successes — prova de que uma integração que funciona está de fato funcionando, útil quando alguém relata que “nada está sincronizando”.
• Never completed — tentativas ainda em Queued ou Running muito depois do momento em que deveriam ter terminado. São os casos silenciosos: nada falhou, então nada foi relatado, mas também nada chegou.
• All events — tudo, sem filtro.

A visualização ativa faz parte da URL da página, então uma visualização pode ser compartilhada por link e sobrevive a uma atualização da página.

Restringindo a lista#

• Intervalo de tempo — 24 horas, 7 dias, 30 dias ou 90 dias, pelos botões no cabeçalho.
• Contagens por fonte — as contagens coloridas abaixo dos cartões de resumo também funcionam como filtros rápidos. Clique em uma para mostrar apenas aquela fonte; clique novamente (ou em Clear source filter) para voltar. No máximo uma fica ativa por vez.
• Filtros e ordenação por coluna — cada coluna permite filtrar e ordenar, incluindo Severidade e Fonte. A Severidade ordena por gravidade (Critical → Info) em vez de ordem alfabética, e a Fonte ordena pelo rótulo exibido, não pelo valor armazenado internamente.
• Keyword Search — pesquisa em todos os campos de texto ao mesmo tempo.
• Preferências de colunas — o seletor de colunas e os layouts salvos funcionam da mesma forma que em qualquer outra lista do Pro.

Clique na lupa no início de uma linha para abrir a tentativa completa:

As credenciais são removidas antes da linha ser gravada#

Erros de integração citam a requisição que falhou, e essas citações carregam segredos: um cabeçalho Authorization, um token em uma query string, uma senha dentro de uma URL de conexão. O Diagnósticos remove esses valores na entrada, de modo que o valor original nunca chega ao banco de dados e nenhuma mudança de ideia posterior pode expô-lo.

Duas coisas são higienizadas:

• Valores sob chaves com formato de credencial — qualquer coisa cuja chave pareça um segredo (password, token, secret, api_key, authorization, private_key e similares, em qualquer capitalização ou com traços ou espaços). Um pequeno conjunto de chaves é isento, porque só a presença delas importa, nunca o conteúdo.
• Valores que parecem credenciais onde quer que apareçam — cabeçalhos de autorização bearer e basic, JWTs, credenciais embutidas em URLs (https://user:pass@host), prefixos de token reconhecíveis de fornecedores e blocos PEM.

Cada um é substituído por [redacted]. A mensagem ao redor é mantida, para que o erro continue legível:

401 Unauthorized: Authorization: [redacted]
upload rejected: https://svc:[redacted]@sftp.example/out/…

Valores longos são truncados, e contextos profundamente aninhados são achatados, para que um payload enorme não sobrecarregue a tabela.

Quando algo é removido de uma linha, a própria linha indica isso, em vez de deixar você se perguntando se o campo estava vazio ou foi esvaziado.

A redação é, por design, uma tentativa de melhor esforço. O higienizador reconhece formatos de credenciais. Um segredo que se pareça com texto comum, sob uma chave que não pareça sensível, ainda pode ser registrado. Trate o Diagnósticos como um log operacional, não como um lugar onde a ausência de segredos é garantida — e mantenha o detalhe técnico restrito a quem realmente precisa dele.

Quem vê o quê#

O Diagnósticos é dividido por nível de acesso, porque o resumo de uma falha é útil para o dono de um produto, mas a requisição bruta por trás dela não é.

Um usuário que não é superusuário vê que um detalhe existe e está sendo ocultado, em vez de um campo vazio que pareça um dado ausente. As linhas em nível de instância — SSO, SAML, LDAP e outras atividades que não pertencem a nenhum produto — são exclusivas para superusuários, já que não há associação a nenhum produto que pudesse conceder acesso a elas.

Por quanto tempo os registros são mantidos#

Uma tarefa agendada faz a limpeza do registro para que ele não cresça sem limite:

Ambas as janelas são configuráveis com as configurações DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS e DIAGNOSTIC_EVENT_RETENTION_DAYS. A exclusão é feita em lotes, para que uma purga grande não mantenha uma transação longa aberta.

API#

O registro é somente leitura pela API, em /api/v2/diagnostic_events/:

Parâmetros úteis:

As mesmas regras de acesso se aplicam: um usuário que não é superusuário recebe linhas restritas aos seus produtos, com os campos restritos ocultados.

Descobrindo o que deu errado#

• Um ticket nunca apareceu. Filtre a Fonte pelo integrador (ou Jira) e leia o Status. Failed fornece o motivo no Resumo; Queued muito tempo depois do fato indica que o job nunca chegou a rodar, o que é um problema de worker ou de agendamento, e não de credencial.
• Um usuário não consegue fazer login. Filtre a Fonte por SSO, SAML ou LDAP, e leia a falha da tentativa dele — uma assinatura de asserção inválida, um bind rejeitado, um atributo incompatível. Essas linhas são em nível de instância, portanto exclusivas para superusuários.
• Um scan não apareceu. Filtre a Fonte por Import / Reimport. Observe o Gatilho para distinguir um envio agendado e não supervisionado de um envio manual de alguém, e o Acionado por para saber a quem perguntar.
• Algo está tentando novamente sem parar. Ordene por ID de correlação, ou filtre por um valor específico, para ver juntas todas as tentativas da mesma operação lógica.
• “Nada está funcionando.” Abra primeiro o Successes para a mesma janela de tempo. Uma lista saudável ali transforma uma indisponibilidade vaga em algo específico.

Relacionados#

• Feature Flags — ativando e desativando recursos opcionais do Pro
• Connectors — trazendo achados para dentro
• Pro Integrations — enviando achados para fora
• Single Sign-On — os provedores de identidade cujas tentativas de login aparecem aqui