Como o produto funciona por dentro.

Cada ciclo do Security Radar começa com o Subfinder — enumerador passivo de subdomínios mantido pela ProjectDiscovery sob licença MIT. Subfinder consulta dezenas de fontes OSINT (Censys, Chaos, VirusTotal, SecurityTrails, Certificate Transparency logs, entre outras) sem nunca tocar o alvo — toda descoberta vem de registros públicos já indexados. Em um domínio SaaS B2B típico, 127 subdomínios são mapeados em ~45 s, sem gerar uma única requisição HTTP contra a infraestrutura do cliente. A escolha por Subfinder (vs alternativas comerciais fechadas) é deliberada: código auditável, histórico de commits público e conformidade com as licenças das fontes passivas. Zero tráfego ativo significa zero risco de WAF-trigger no estágio de descoberta.

Descoberto o perímetro, o httpx (também ProjectDiscovery, MIT) sonda cada host com requisições HTTP mínimas via a biblioteca retryablehttp. Retorna status, título, tecnologia (Wappalyzer embutido), hash JARM do TLS e detecção de CDN/WAF — tudo em um único pass. ~412 endpoints são caracterizados em ~1 min com rate-limit de 2 req/s, respeitando robots.txt e recuando em 5xx consecutivos. Quando o httpx detecta Cloudflare, Akamai ou AWS WAF na frente de um host, o Security Radar marca o finding downstream com o atenuante Environmental correspondente no score CVSS — evidência ativa só conta se o atacante tiver o mesmo caminho do scanner. Sem httpx, os testes DAST rodariam contra endpoints mortos ou protegidos por WAF e gerariam ruído em vez de prova.

A engine DAST da Indícia executa testes ativos alinhados ao OWASP Top 10:2025 contra cada endpoint vivo retornado pelo httpx — SQLi, XSS refletido e DOM, IDOR, CSRF, session fixation, exposição de arquivos sensíveis, GraphQL introspection, client-side secrets e cookie flags. Cada teste produz evidence estruturada com request/response capturado, severidade CVSS v3.1 e dedup por fingerprint tipo+endpoint. A integração com Nuclei (6.500+ templates da comunidade ProjectDiscovery) está prevista no roadmap Q3 2026 — ampliará cobertura de CVEs e misconfigurations mantendo o mesmo contrato de evidência forense.

Cada finding recebe score CVSS v3.1 conforme especificação da FIRST.org — padrão que permanece dominante em NVD, Red Hat, Microsoft e Cisco em 2026, apesar do lançamento da v4.0 em novembro de 2023. A escala 0-10 é decomposta em 8 métricas Base (AV, AC, PR, UI, S, C, I, A) visíveis no export, nunca apenas o score final — um auditor que discordar da severidade pode recalcular. Quando o httpx detecta WAF ou CDN na frente do alvo, o Security Radar sugere ajustes Environmental (MAV, MAC) mas nunca recalcula silenciosamente: a decisão fica com o operador. V4.0 entra como score suplementar quando a template upstream já publica — jamais como substituição ao v3.1 de referência.

O Security Radar aplica validação LGPD-BR proprietária mantida pela Indícia — cobertura em expansão contínua. As verificações atuais detectam: exposição de CPF/CNPJ em respostas públicas, cookies sem consentimento (Art. 8º LGPD), endpoints /api/users?id= vulneráveis a IDOR com dados de titulares (Art. 6º IV), banner de privacidade ausente e política de cookies fora de conformidade com a Res. CD/ANPD 4/2023. Cada verificação mapeia pra artigo específico da LGPD e referencia a Resolução ANPD aplicável — evidência que um assessor jurídico consegue defender numa fiscalização. Nenhum scanner internacional genérico tem esta camada: a LGPD é primeira-classe, não GDPR traduzido.

Cada finding, cada export e cada ciclo de scan é selado com hash SHA-256 conforme NIST FIPS 180-4 — o Secure Hash Standard federal que especifica SHA-256 como função determinística produzindo digest de 256 bits. Um finding alterado depois do selo produz hash diferente — divergência detectável em milissegundos comparando o valor publicado contra o cache do cliente. SHA-256 foi escolhido (vs MD5, SHA-1, BLAKE3) por três razões: é homologado em jurisdições que importam pra LGPD (Res. CD/ANPD 15/2024 menciona "medidas técnicas prévias"), é o mesmo hash usado em Certificate Transparency (RFC 6962) e em Git — um engenheiro não precisa aprender nada novo pra validar. Zero edição silenciosa: erros viram errata com novo hash.

Cada finding recebe hash SHA-256 individual — selado no momento da detecção, imutável após o ciclo. A estrutura de Merkle tree (RFC 6962, Certificate Transparency) que encadeia esses hashes numa raiz auditável está prevista no roadmap Q3 2026: permitirá prova de inclusão em O(log n) pra qualquer finding sem expor os demais, mesma garantia que sustenta Git e autoridades certificadoras. Hoje: SHA-256 por finding é gerado e exportado junto com o relatório — qualquer alteração posterior é detectável comparando o hash publicado contra o valor original.

Publicação final do ciclo sai por webhooks HTTP POST assinados com HMAC-SHA-256 pros endpoints configurados pelo cliente (integrações nativas Slack, Jira e PagerDuty no roadmap Q3 2026). A semântica de retry segue o padrão da indústria: 3 tentativas com exponential backoff base 2 (1s, 2s, 4s) mais jitter aleatório pra evitar thundering herd, respeitando o header Retry-After quando o endpoint responder 429, e encaminhando pra dead-letter queue se exaurir. Eventos 2xx confirmam entrega; 4xx não-retriáveis (400, 401, 422) falham imediatamente com log; 5xx e timeouts retentam. O scheduler retryFailedEvents do backend roda a cada 30 min drenando a DLQ. Webhook foi escolhido (vs polling ou fila dedicada) porque é zero-infra do lado do cliente: um URL, um secret HMAC, e o ciclo do Security Radar vira trigger no pipeline.