§ III · Anatomia do Radar

Como o produto funciona por dentro.

Oito órgãos. Um núcleo. Cada linha rotulada com o que flui entre eles. Nada é caixa-preta — se quiser auditar, tudo está nomeado, versionado e documentado. Esta página vale uma demo.

FIG. 1 · CUTAWAY DO MOTOR DE RADAR · ESCALA 1:1
NÚCLEO · SECURITY SCORE
72
+4 · 30D
CUTAWAY · v2.4.1
I
Subfinder
OSS · descoberta passiva
~45s · 127 subdom
II
httpx
fingerprint + WAF detect
~1min · 412 endpoints
III
Nuclei
OWASP Top 10:2025 · 6.500+ templates
~2min · comunidade
IV
CVSS v3.1
scoring padronizado · FIRST.org
0-10 · padrão dominante 2026
V
Templates LGPD-BR
CPF · CNPJ · cookies · retenção
187 regras · BR nativas
VI
SHA-256
evidência versionada · chain
cada finding assinado
VII
Merkle tree
árvore raiz auditável
export para S3 · imutável
VIII
Webhooks
slack · jira · pagerduty
SLA inline · retry 3×
§ III.b · Dossiê dos órgãos

Cada órgão tem nome, versão e porquê.

Oito peças do stack Indícia explicadas em detalhe — o que cada uma resolve, qual licença OSS carrega, qual versão roda em produção e pra qual upstream apontar quando precisar auditar.

§ Descoberta
I Subfinder

Subfinder

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.

Licença MIT Versão 2.6.6 Métrica ~45s · 127 subdom Upstream projectdiscovery/subfinder ↗
II httpx

httpx

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, o Nuclei rodaria contra endpoints mortos ou protegidos por WAF e geraria ruído em vez de prova.

Licença MIT Versão 1.6.10 Métrica ~1min · 412 endpoints Upstream projectdiscovery/httpx ↗
§ Avaliação
III Nuclei

Nuclei

O Nuclei (ProjectDiscovery, MIT) é a engine DAST que executa templates YAML declarativos contra cada endpoint vivo retornado pelo httpx. A biblioteca comunitária oficial nuclei-templates agrega 6.500+ templates curados por mais de 900 contribuidores, cobrindo CVEs publicadas, misconfigurations, exposures e fingerprints de tecnologia. O Security Radar executa com -rl 10 (rate-limit global), severity mapping alinhado ao OWASP Top 10:2025 — edição de 2025 que introduziu A03 Software Supply Chain Failures e A10 Mishandling of Exceptional Conditions — e dedup por hash template+endpoint. Nuclei é escolha de stack porque é determinístico: dado o mesmo template e o mesmo alvo, o output é reproduzível. Condição inegociável pra uma evidência forense.

Licença MIT Versão 3.3.0 Métrica ~2min · 6.500+ templates Upstream projectdiscovery/nuclei ↗
IV CVSS v3.1

CVSS v3.1

Cada finding do Nuclei 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.

Licença FIRST.org spec Versão v3.1 (2019) Métrica 0-10 · padrão dominante 2026 Upstream first.org/cvss/v3.1 ↗
§ Avaliação · regulatória
V Templates LGPD-BR

Templates LGPD-BR

Sobre a base OWASP, o Security Radar soma 187 templates LGPD-BR mantidos pela Indícia — regras que verificam exposição de CPF/CNPJ em respostas públicas, cookies sem consentimento (Art. 8º LGPD), retenção além do declarado, endpoints /api/users?id= vulneráveis a IDOR com dados de titulares (Art. 6º IV, Lei 13.709/18), banner de privacidade ausente e política de cookies fora de conformidade com a Res. CD/ANPD 4/2023. Cada template 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.

Licença Indícia proprietary Versão 2026.04 · 187 regras Métrica CPF · CNPJ · cookies · retenção Upstream Lei 13.709/18 ↗
§ Evidência
VI SHA-256

SHA-256

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.

Licença NIST FIPS 180-4 Versão 2015 · public domain Métrica 256-bit digest · determinístico Upstream NIST FIPS 180-4 ↗
VII Merkle tree

Merkle tree

Os hashes SHA-256 de todos os findings de um ciclo entram como folhas de uma Merkle tree — estrutura descrita por Ralph Merkle em 1979 e operacionalizada em RFC 6962 Certificate Transparency (e seu sucessor RFC 9162). A raiz da árvore de cada ciclo é publicada junto com o export, permitindo prova de inclusão em O(log n) pra qualquer finding individual sem expor os demais. Um ciclo com 412 findings precisa de ~9 hops pra provar que um item específico estava lá — mesma estrutura que sustenta Git, Bitcoin e os logs públicos de autoridades certificadoras. O operador pode exportar a árvore pra S3/Azure Blob/GCS; a Indícia assina a raiz, nunca apaga folhas. Append-only é a garantia: findings passados permanecem auditáveis mesmo após nova execução.

Licença RFC 6962 · RFC 9162 Versão Merkle 1979 · CT 2013/2021 Métrica prova inclusão O(log n) Upstream RFC 6962 · Certificate Transparency ↗
§ Delivery
VIII Webhooks

Webhooks

Publicação final do ciclo sai por webhooks HTTP POST assinados com HMAC-SHA-256 pros endpoints Slack, Jira e PagerDuty do workspace. 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.

Licença HMAC-SHA-256 signed Versão retry 3× · backoff 1s/2s/4s Métrica Slack · Jira · PagerDuty · DLQ
§ IV · Fluxo · 4 estações

Da descoberta à publicação em 4 min 23 s.

I. ~45s
Entrada
domínios + subdomínios descobertos
II. ~15s
Triagem
score + dedup + CVSS v3.1
III. ~5s
Evidência
SHA-256 + árvore merkle
IV. ~3s
Publicação
timeline · webhook · pdf
Stack OSS

subfinder 2.6 · httpx 1.4 · nuclei 3.2 · templates @9e4a2c

Licenças

MIT · Apache-2.0 · compatível com uso comercial sem atribuição por finding.

Privacidade

Mascaramento na origem. Nenhum PII persiste após triagem. LGPD Art. 6º IV.

Auditoria

Logs imutáveis · hash chain SHA-256 · exportáveis pra S3/Azure Blob/GCS.