Scan ativo
Sair do que um navegador enxerga e testar de fato o alvo, com autorização registrada. Hoje a varredura da plataforma é só passiva.
Este módulo ainda não existe
O que segue descreve a intenção, não o que está entregue. Nenhuma parte disto está disponível para contratação hoje. Se o seu caso depende deste módulo, diga — a ordem do roadmap responde a demanda real, e é assim que ela muda.
O JustCyber Scan que está no ar é passivo por construção: cabeçalhos HTTP de segurança, TLS e certificado, DNS de e-mail (SPF/DMARC) e exposição de arquivos óbvios. Sem fuzzing, sem brute force, sem port scan. Antes de qualquer pacote, o host é resolvido uma vez, todos os IPs são checados contra faixas privadas, loopback, link-local, CGNAT e metadata (incluindo o IMDS e o equivalente IPv6 mapeado), e a conexão é pinada ao IP validado. Cada salto de redirecionamento revalida o destino. Em produção isso soma-se ao egress-broker e à NetworkPolicy da fila isolada de varredura.
O Scan ativo seria a camada intrusiva — Nuclei, nmap, ZAP e afins, sob autorização registrada. Nenhuma dessas ferramentas aparece no código da aplicação. Não há binário, wrapper, template nem fila dedicada. Os dois motores existentes são o passivo e um cliente HTTP que dirige um agente de recon também passivo num processo externo, com o mesmo guarda de SSRF aplicado antes.
Há uma dívida ligada a isso que o comprador precisa saber. O campo scan_level (basic, intermediate, advanced, ultra) é aceito pela API, gravado no job e propagado até o contexto de execução — mas o motor padrão o ignora: ele chama as checagens passivas passando só o alvo, e a função de checagem nem tem parâmetro de nível. Pedir 'ultra' executa exatamente as mesmas checagens de 'basic'. Os quatro níveis são rótulo, não profundidade, e não devem ser vendidos como se fossem.
Capacidades previstas
Descrição da intenção. Nada aqui está construído.
-
Guarda de SSRF antes de qualquer pacote (já construído, e passivo)
É a camada de aplicação da defesa em profundidade. A defesa complementar — egress-broker e NetworkPolicy deny-all para a fila isolada de varredura — está escrita como manifesto de Kubernetes no repositório, mas não está em uso: o kit de deploy atual é docker-compose em VPS single-node e nem sequer roda a fila `scanning`. Hoje, na prática, quem barra o alvo interno é o guard de SSRF da aplicação.
-
Motor selecionável e fail-closed
A resolução do motor lê a configuração (padrão: passivo). Nome desconhecido levanta erro claro em vez de cair silenciosamente noutro motor. É exatamente a costura onde um motor ativo entraria — a costura existe, o motor não.
-
Ciclo de job já pronto de ponta a ponta
Criar job grava a linha e emite o evento na mesma transação; o relay despacha para a fila isolada; o worker faz idempotência de entrega com SELECT FOR UPDATE, revalida a propriedade do alvo em execução, faz upsert de achado por fingerprint e promove severidade a partir de baixa para o inventário de vulnerabilidades do portal.
-
Checagens passivas reais, com evidência redigida
TLS e certificado, cabeçalhos de segurança, DNS de e-mail e exposição de caminho. O corpo bruto de /.env, /.git/config ou /server-status nunca é gravado: fica só a presença e um trecho redigido, no máximo 256 bytes.
O que este módulo não faz
Não existe varredura ativa. Não há nenhuma referência a Nuclei, nmap ou ZAP no código da aplicação. O motor padrão é passivo e o único motor alternativo dirige um agente de recon também passivo. Sem exploração, sem fuzzing, sem brute force, sem port scan — o módulo afirma isso explicitamente. Os níveis basic, intermediate, advanced e ultra são aceitos, gravados e ecoados pela API, mas o motor padrão não os usa: PassiveEngine.run chama run_passive_checks(job.target) e essa função não tem parâmetro de nível. Não existe fluxo de autorização por janela, escopo de IP ou contrato de teste intrusivo; a autorização hoje é a verificação de propriedade do ativo. As portas alcançadas são as configuradas por padrão em 80 e 443.
Declaramos o limite porque software de segurança que promete tudo não é auditável. Se o que falta aqui é o que você precisa, o serviço consultivo cobre — ou dizemos que não cobre.
Conecta com
- Outbox transacional e fila isolada de varredura
- Inventário de vulnerabilidades do portal (promoção de achado a partir de severidade baixa)
- Egress-broker e NetworkPolicy do pool de varredura
- Motor opencode: agente de recon passivo em processo externo, com Basic auth injetado e budget de tempo
- Orquestrador de casos, que dispara scan com scan_level validado
Controle de acesso
O acesso é concedido por escopo, não por perfil genérico. Quem só precisa ler não recebe permissão de escrita, e a barreira é o banco de dados, não a interface.
- scan:asset:read
- scan:asset:write
- scan:job:read
- scan:job:write
- scan:finding:read
- scan:finding:write
Precisa disto? Diga.
A ordem do roadmap responde a demanda real de cliente. Se este módulo resolve o seu problema, isso muda a prioridade.