JustCyber

CyberScore

Uma nota A–F do que o seu domínio mostra publicamente, sem login, em troca de um e-mail com consentimento.

O CyberScore é a porta de entrada comercial. O visitante informa domínio, e-mail e consentimento, e recebe uma nota A–F global e por dimensão (TLS, cabeçalhos HTTP, DNS) com a lista dos itens que puxaram a nota para baixo. Não há cadastro, não há login, não há tenant. O relatório fica acessível por um `public_id` opaco — a capability é o próprio link.

O motor é o mesmo do Scan, reusado literalmente: run_passive_checks com include_exposure=False. O scoring é uma função pura, sem IA e sem I/O, versionada em SCORING_VERSION: cada dimensão parte de 100 e perde 25 por achado high, 12 por medium e 5 por low; a nota global é a média ponderada (TLS 0,40, cabeçalhos 0,35, DNS 0,25); as faixas são fixas (A a partir de 90, B de 80, C de 70, D de 60, E de 50, F abaixo). Mesmo domínio, mesmos achados, mesma nota — auditável e recomputável.

A postura é conservadora porque é um endpoint público que dispara saída de rede em nome de um desconhecido. O consentimento é pré-condição LGPD; o e-mail vira hash mais cifra em envelope e nunca sai em resposta de API (o SELECT do relatório nem projeta a coluna); o IP só vira hash. O rate-limit é duro e em duas dimensões independentes — por IP e por (IP, domínio) — para barrar quem quer varrer cem domínios do mesmo lugar. Alvo que resolve para IP interno devolve um 422 opaco, 'não elegível', sem revelar por quê. A tabela cyberscore_leads é global e só é tocada pelo control-plane.

O que faz hoje

Capacidades em operação

Cada item corresponde a funcionalidade que existe no código e é alcançável por um usuário com o escopo correto.

  • Nota A–F determinística e versionada

    Motor de scoring puro, sem IA: deduções por severidade, pesos por dimensão e faixas fixas. A versão do algoritmo é persistida junto ao lead, então dá para recomputar e auditar.

  • Só passivo, sem sondar domínio de terceiro

    Cabeçalhos HTTP, TLS/certificado e DNS. Os caminhos sensíveis (/.env, /.git/config, /server-status) NÃO são consultados: sondar caminho em domínio que não é do solicitante seria sondagem não autorizada.

  • Consentimento e minimização de dados

    Sem consent=true não há relatório (422). O e-mail é guardado só como hash e cifra, o IP só como hash, e o consentimento é carimbado com data.

  • Dedup na janela

    Mesmo par (hash do e-mail, domínio) dentro da janela configurável devolve o relatório já persistido, em vez de recomputar e multiplicar leads.

  • Link permanente por capability opaca

    O public_id é gerado com secrets, não é enumerável, e o GET por ele nunca expõe o e-mail do lead.

  • Rate-limit em duas dimensões

    3 por minuto por IP e 3 por minuto por (IP, domínio) na criação; 30 por minuto na leitura. A chave de (IP,domínio) é hasheada — o domínio não fica em claro no Redis.

  • Feed para o CRM interno

    O staff dispara sync_from_cyberscore, que leva os leads de cyberscore_leads para crm_leads copiando só o hash do e-mail — nunca o e-mail.

O que fica com você

Entregáveis

  • Página pública /cyberscore com formulário e relatório renderizado
  • Relatório com nota global, nota por dimensão e itens redigidos (severidade + título, sem evidência bruta)
  • public_id opaco como link permanente do relatório
  • Linha em cyberscore_leads (control-plane) com consentimento carimbado
  • Lead em crm_leads com origem 'cyberscore' após o sync do staff

O que este módulo não faz

Nasce desligado: JC_CYBERSCORE_ENABLED tem default False e, com a flag off, as duas rotas devolvem 404 sem revelar que o produto existe. Não sonda caminhos — a dimensão 'exposure' não existe no relatório, por decisão ética, então um /.env exposto não aparece aqui (aparece no Scan, que exige propriedade provada). Ausência de sinal não penaliza: um domínio sem 443 pontua 100 em TLS e o peso permanece, ou seja, um 'A' pode significar 'nada foi observado', não 'está seguro'. Não envia e-mail: não há disparo do relatório, nurture ou notificação — o e-mail é capturado e o feed para o CRM é acionado manualmente pelo staff. Não há verificação de propriedade do domínio, e é justamente por isso que o escopo é limitado ao que um navegador vê. Não há histórico nem evolução: cada relatório é um retrato, e dentro da janela de dedup o sistema devolve o retrato antigo em vez de tirar outro. Sob queda do Redis a rota é fail-open (decisão consciente: um blip não deve derrubar o funil), com log de alta severidade.

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

  • app/scan/passive.py (run_passive_checks, mesmo guard de SSRF)
  • app/auth/pii (hash + cifra em envelope)
  • platform_session / control-plane (tabela global cyberscore_leads)
  • Plataforma interna do staff (sync_from_cyberscore → crm_leads)
CyberScore

Quer ver funcionando?

Demonstração com dado do seu ambiente, não com base de exemplo. É a única forma de saber se serve.