Amostra de laboratório: o que o relatório mostra
Como usamos labs públicos intencionalmente vulneráveis para mostrar o formato do entregável, sem misturar isso com pesquisa independente.
João Edgar1 min de leitura
Antes de falar com um cliente real, rodamos o mesmo pipeline em dois repositórios públicos feitos para treino: DVNA (appsecco, MIT) e OWASP NodeGoat (Apache-2.0).
Por que labs, e não alvos reais
Esses projetos já nascem com falhas de propósito. Servem para validar método, evidência e formato do relatório sem risco a terceiros e sem violar regras de divulgação responsável.
O que confirmamos (resumo, sem prova de conceito)
Sete achados classificados como críticos: desserialização insegura, token de reset previsível, escape de sandbox em avaliação de expressão, SQL injection por concatenação, injeção de comando do sistema (OS command injection), injeção de JavaScript no servidor via eval, e NoSQL injection via $where. Cada um foi verificado no código; os mais fortes ganharam prova isolada em laboratório.
Também analisamos alvos OSS reais (axios e express) na mesma rodada e não confirmamos nenhum achado inédito. Uma hipótese fraca foi rejeitada com prova empírica. Isso faz parte da honestidade do método: alarme falso não entra no relatório.
Onde ver a amostra
A home do site traz a seção de achados com a mesma linguagem do entregável. Este post é o contexto editorial: o que é demo, o que não é, e por que a distinção importa.