Revisão de três alertas altos de segredos no n8n
Três alertas altos do n8n mostram por que a revisão analisada e o contexto do código precisam ser verificados antes de declarar um vazamento.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestEm 29 de outubro de 2026, revisamos um conjunto de resultados do Plexicus associado ao repositório n8n. Havia 110 alertas de segredos: três classificados como altos e 107 como médios. Esse resumo poderia parecer uma prova de credenciais vazadas. Os registros detalhados não sustentavam essa conclusão.
Inspecionamos os três registros altos e comparamos suas localizações ao código público no snapshot imutável solicitado. Duas localizações identificam constantes de nome de credencial em módulos simulados. A terceira inicia uma declaração de tipo de credencial. Nenhuma dessas três localizações demonstra um segredo utilizável exposto. A ausência do commit realmente analisado também impede declarar definitivamente falsos positivos do scanner.
O que os três registros demonstram
Os registros tinham o título “Use of Hard-coded Credentials”. Incluíam caminho e linha, mas os campos de código, relatório do scanner e descrição estavam vazios. O indicador de falso positivo era falso. Esse estado armazenado do fluxo não é uma prova independente da existência de uma credencial.
| Localização informada | Código público no snapshot solicitado | Resultado da revisão |
|---|---|---|
| CredentialConfig.test.ts, linha 1002 | Declaração ICredentialType | Metadados não demonstram um valor de credencial |
| Teste de exclusão de página Confluence, linha 14 | CONFLUENCE_CREDENTIAL_NAME em vi.mock | O nome simulado não demonstra um segredo utilizável |
| Teste de exclusão de anexo Confluence, linha 8 | Mesmo tipo de constante simulada | É necessária a correspondência original do scanner |
O teste de configuração, o teste de exclusão de página e o teste de exclusão de anexo são referências públicas e imutáveis. Publicamos apenas os identificadores necessários para explicar a revisão. Valores de credenciais, IDs privados e respostas brutas da API ficam fora deste artigo.
A revisão ausente limita a conclusão
O registro do Open Source Explorer solicitava 447fc866bb0a841decfa5e8a29fba06057bfc5bc. Recuperamos os arquivos upstream nesse SHA exato. Os registros, porém, não identificavam sua execução nem o commit realmente analisado. Totais por repositório podem incluir resultados de outros momentos do histórico.
Quando as linhas mudam, uma declaração inofensiva no snapshot solicitado não prova o que o scanner encontrou antes. A classificação alta também não substitui a evidência ausente. A conclusão limitada é que os três registros e seu contexto não estabelecem exposição de credenciais. Isso não significa que todo o n8n esteja livre de segredos nem que todos os alertas estejam incorretos.
Modelo original de revisão. O diagrama apresenta as provas necessárias, não um vazamento reproduzido.
Um arquivo de teste fornece contexto
Credenciais reais podem aparecer em testes, exemplos e fixtures. Excluir todos esses diretórios poderia ocultar vazamentos verdadeiros. É preciso entender o papel do valor: autenticação, nome de tipo, marcador sintético ou referência a outro objeto.
As duas localizações do Confluence atribuem uma constante de nome em um módulo simulado e substituem a função da API por um dublê de teste. A terceira inicia um objeto de configuração tipado. Antes de pedir rotação ou anunciar um incidente, solicite a correspondência original e a explicação da regra.
Se uma evidência posterior comprovar uma credencial real, sanitize o relatório público e siga a revogação indicada pelo provedor. Não tentamos autenticar com nenhum valor nem enviamos candidatos a serviços externos.
Preserve as provas junto à decisão
Guarde as versões do scanner e da regra, o commit analisado, a faixa de código, a correspondência redigida, a categoria e o raciocínio do revisor. Identifique quem responde pela correção. Uma verificação bloqueada ou um conteúdo ausente permanece sem resolução.
Nosso fluxo Proof-Driven AppSec conecta o alerta a um resultado revisável. O guia de remediação apresenta o caminho até uma alteração revisada. Deep Code Analysis explica o contexto do código.
O Plexicus fornece os metadados examinados. A inspeção descrita foi uma investigação editorial, não uma decisão automática do produto que tenhamos demonstrado. A remediação e o AI Swarm Pentest descrevem outros trabalhos delimitados; não confirmam esses alertas como vazamentos.
Complete o registro
Solicite a correspondência original e a revisão realmente analisada. Reconcilie as linhas antes de confirmar ou descartar os alertas. Preserve os links imutáveis e esta conclusão limitada para outro analista completar o registro. Esta revisão não estabelece patch do n8n, revogação ou exploração bem-sucedida.
Fontes
Precisa transformar alertas em decisões de engenharia? Fale com o Plexicus com a revisão do repositório e evidências sanitizadas.
