RUBRICA DE PONTUAÇÃO PÚBLICA · v1.1 · ATUALIZADA 2026-10-10

Metodologia do scanner

Toda pontuação do zn Scan é uma fração ponderada dos controles aplicáveis. Esta página define o catálogo completo de controles, os pesos de cada nível e as regras que mantêm a medição neutra e reproduzível. A rubrica é versionada; cada mudança aparece com sua data no registro de alterações abaixo, e cada relatório informa a versão da rubrica usada na pontuação.

1. Somente passivo

Os scans remotos fazem o handshake MCP (initialize, notifications/initialized) e tools/list via Streamable HTTP, em até 15 segundos e somente nas portas 443, 80 ou 8443. Nenhuma ferramenta é invocada e nenhum payload adversarial é enviado ao alvo. Se tools/list exigir autenticação, os controles de ferramentas saem do denominador em vez de falhar, e o relatório mostra quantos controles foram pontuados.

2. Aplicabilidade

Um controle que o alvo não pode atender por design (sem ferramentas de mutação, servidor somente leitura) é excluído do denominador em vez de ser pontuado como falha. Pontuação = peso obtido / peso aplicável. Uma nota com letra exige pelo menos um controle no nível das ferramentas: caso contrário, o relatório fica Sem nota.

3. Neutralidade de produto

Nenhum controle favorece um produto específico. O zn-gate aparece apenas como uma entre várias opções de correção, sempre ao lado de uma alternativa open source. Todas as notas de A+ a F podem ser alcançadas sem nenhuma compra.

Faixas de nota

NotaPontuaçãoSignificado
A+95–100Altamente resiliente
A85–94Base sólida
B70–84Risco moderado
C50–69Risco elevado
F< 50Vulnerabilidade crítica
NR—Sem nota: nenhum controle no nível das ferramentas pôde ser pontuado (endpoint com autenticação, transporte SSE antigo ou nenhum esquema de ferramentas). Os controles observados continuam listados.

Nível Essencial

12 pts cada

Segurança básica. Controles ausentes contam como falhas.

Criptografia de transporte TLS 1.2+

RFC 5246 / RFC 8446tls_transport

Endpoints acessíveis via HTTPS com uma cadeia de certificados válida para o hostname. Transporte HTTP em texto claro falha.

Correção: Termine o TLS na borda com um certificado gerenciado e redirecione todas as requisições em texto claro.
Alternativa open source: Let's Encrypt + Caddy ou certbot para Nginx com HSTS.

Fronteira de transporte autenticada

MCP Authorizationauth_boundary

Endpoints MCP que expõem ferramentas capazes de mutação impõem uma fronteira de autenticação (OAuth 2.1 com PKCE ou bearer tokens assinados) antes de servi-las.

Correção: Exija o fluxo authorization code do OAuth 2.1 com PKCE em todo endpoint de transporte MCP.
Alternativa open source: Provedores de identidade open source (Keycloak, Ory Hydra, oauth2-proxy) oferecem os mesmos fluxos.

Limites de entrada e de payload

OWASP LLM10input_bounds

Os parâmetros string declarados incluem comprimentos máximos, enums ou patterns, para que uma única chamada não possa carregar payloads ilimitados.

Correção: Restrinja os parâmetros string com maxLength, enum ou pattern e rejeite corpos grandes demais no nível do transporte.
Alternativa open source: maxLength do JSON Schema mais limites de tamanho do corpo no nível do framework (ex.: limites do body-parser no express).

Higiene das descrições de ferramentas

OWASP LLM01tool_desc_hygiene

As descrições de ferramentas e parâmetros são analisadas em busca de imperativos adversariais e Unicode invisível escondidos nas docstrings (envenenamento indireto de ferramentas).

Correção: Reescreva as descrições como declarações neutras de capacidade; remova orações imperativas e caracteres invisíveis.
Alternativa open source: mcp-scan (Invariant Labs) e LlamaFirewall sinalizam descrições envenenadas.

Sem primitivas de shell irrestritas

OWASP LLM06shell_primitives

Ferramentas que expõem shell arbitrário, eval ou execução de comandos no host sem sandbox são críticas por design.

Correção: Substitua ferramentas de shell abertas por operações granulares e delimitadas, ou execute-as dentro de um sandbox (Docker, Firecracker).
Alternativa open source: MicroVMs Firecracker, gVisor ou Docker com rootfs somente leitura e capabilities removidas.

Mutação do sistema de arquivos delimitada

OWASP LLM06fs_mutation

Ferramentas de escrita ou exclusão de arquivos devem delimitar seus parâmetros de caminho (pattern, comprimento ou uma raiz de sandbox declarada). Caminhos sem delimitação falham.

Correção: Vincule o servidor a uma única raiz de workspace, respeitando as exclusões de arquivos ocultos.
Alternativa open source: O servidor MCP de sistema de arquivos de referência delimita as raízes da mesma forma.

Sem parâmetros de credenciais em texto claro

OWASP LLM02credentials_exposure

Os parâmetros das ferramentas não devem aceitar chaves de API, senhas ou tokens como argumentos visíveis ao modelo.

Correção: Injete as credenciais em tempo de execução a partir do ambiente ou de um gerenciador de segredos, nunca por argumentos de ferramentas.
Alternativa open source: Vault, AWS Secrets Manager ou Doppler com injeção restrita ao ambiente.

Nível Recomendado

6 pts cada

Boa prática para servidores expostos. Falhas subtraem peso.

Tipagem estrita do esquema de parâmetros

OWASP LLM05param_typing

Toda ferramenta declara um inputSchema do tipo object e todo parâmetro declarado tem um tipo explícito. Ferramentas sem argumentos passam; esquemas ausentes ou tipados como sacolas abertas falham.

Correção: Declare tipos (string, integer, boolean) e campos obrigatórios no inputSchema de toda ferramenta.
Alternativa open source: Zod, Pydantic ou JSON Schema puro geram esquemas estritos da mesma forma.

Aprovação humana em mutações de alto impacto

OWASP LLM06financial_human_gate

Ações irreversíveis (reembolso, transferência, cobrança, deploy) exigem uma etapa de aprovação humana auditável. Não observável de forma passiva: reportado para verificação manual, nunca pontuado.

Correção: Adicione um fluxo de confirmação em duas etapas com tokens de aprovação do lado do servidor para ferramentas de mutação.
Alternativa open source: Qualquer fila de aprovação baseada em webhooks (bot do Slack, fluxo do Linear) implementa a mesma barreira.

Capacidade de filtragem da saída de ferramentas

OWASP LLM01output_filter_capacity

O alvo deve apresentar algum mecanismo para inspecionar ou filtrar o conteúdo retornado pelas ferramentas antes que chegue ao modelo, independentemente do fornecedor.

Correção: Filtre as saídas das ferramentas em linha (gate neural, política de regex ou middleware do framework) antes de reinjetá-las no contexto.
Alternativa open source: LlamaFirewall, LLM Guard ou Azure Prompt Shield oferecem capacidade equivalente.

Isolamento do namespace de ferramentas

OWASP LLM01namespace_isolation

O contexto não pode redefinir, sombrear ou sobrescrever nomes de ferramentas registrados a partir de documentos não confiáveis.

Correção: Reconstrua o registro de ferramentas a cada turno e rejeite nomes sombreados.
Alternativa open source: O SDK MCP de referência mantém imutáveis os nomes de ferramentas controlados pelo cliente.

Nível Bônus

2 pts cada

Crédito extra. Se ausente por design, o controle é excluído do denominador: nunca subtrai.

Política de retenção zero de dados publicada

OWASP LLM02zdr_policy

Uma declaração publicada e linkável sobre o que o servidor retém das chamadas de ferramentas ou das conversas.

Correção: Publique uma declaração de retenção de dados no site.
Alternativa open source: Uma página pública de documentação ou um relatório de confiança atende a isso sem nenhum fornecedor.

Trilha de auditoria criptográfica

OWASP LLM06audit_trail

Veredictos e mutações produzem registros de evidência encadeados por hash ou assinados.

Correção: Registre os veredictos com encadeamento por hash ou armazenamento append-only.
Alternativa open source: Logs encadeados por hash com OpenSSL ou um log Merkle append-only implementam esse padrão.

Funcionamento do scan remoto

  • A resolução DNS é validada antes de cada conexão; as requisições fixam um único endereço resolvido (sem janela para DNS rebinding).
  • Faixas privadas, de loopback, link-local (incluindo 169.254.169.254), CGNAT, multicast e de documentação são rejeitadas na resolução DNS e novamente a cada salto de redirecionamento.
  • Máximo de 2 redirecionamentos, no máximo 8 segundos por requisição, 15 segundos para o scan inteiro e limite de resposta de 512 KB por requisição.
  • Um HTTP 401 ou 403 conta como desafio de autenticação MCP somente com um cabeçalho WWW-Authenticate: Bearer, metadados de recurso protegido da RFC 9728 ou um corpo de erro JSON-RPC. Servidores com autenticação são reportados como Sem nota, nunca como A+ só pelo transporte.
  • Limite: 20 scans por hora por IP de origem.
  • Alvos que não respondem como servidor MCP (inacessíveis, ou respostas HTTP que não são MCP) são informados apenas ao usuário; nada é publicado.
  • Os certificados TLS devem ser válidos para o hostname escaneado (SNI, cadeia completa).
  • Todo relatório traz evidência por controle e sua própria URL (scan.usezn.com/r/{id}/) com variantes em JSON, Markdown e badge, de modo que qualquer pontuação pode ser verificada novamente rodando o mesmo scan. Os relatórios não são indexados pelos motores de busca e são apagados após 90 dias.

Modo estático (artefatos colados)

System prompts e esquemas de ferramentas colados são analisados no navegador e nunca enviados. Valem os mesmos léxicos e pesos por nível; os controles de transporte são excluídos do denominador porque artefatos colados não podem contê-los. Um system prompt colado sem esquema de ferramentas fica Sem nota. Este modo comprova o que os próprios artefatos declaram, nada mais.

Referências normativas

  • TLS 1.2 (RFC 5246) / TLS 1.3 (RFC 8446).
  • Model Context Protocol (2025-06-18): initialize, tools/list, Streamable HTTP, Authorization (OAuth 2.1).
  • OAuth 2.0 Protected Resource Metadata: RFC 9728.
  • OWASP Top 10 for LLM Applications (2025): LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM10 Unbounded Consumption.

Registro de alterações

v1.1

2026-10-10
  • Not rated (NR): a letter grade now requires at least one tool-level check. Auth-gated endpoints, legacy SSE servers and empty tool lists are reported as Not rated instead of earning A+ on transport alone.
  • Auth detection: an HTTP 401/403 counts as an MCP auth challenge only with a WWW-Authenticate: Bearer header, RFC 9728 protected-resource metadata or a JSON-RPC error body; a bare 403 from a firewall is not an MCP server and is not published.
  • Fewer false positives: credential parameters are matched on whole name segments (author, max_tokens and page_token no longer match); tools without arguments pass schema typing; filesystem checks only apply to file-shaped tools; shell detection needs a shell/eval/command-execution name, or a description of arbitrary command or code execution.
  • Tool description hygiene also inspects parameter descriptions and flags invisible Unicode (zero-width, bidirectional and tag characters).
  • References corrected to the OWASP Top 10 for LLM Applications 2025 (LLM01, LLM02, LLM05, LLM06, LLM10) and the MCP authorization spec.
  • Duplicate auth and transport rows removed from reports.

v1.0

2026-09-30
  • First public rubric: 13 checks in three tiers, applicability exclusions, passive remote mode and in-browser static mode.

Os relatórios mantêm a versão da rubrica usada na pontuação. Rode o scan novamente para obter uma pontuação na versão atual. O registro de alterações é publicado em inglês.

Contestações e correções

Acha que um controle está errado para o seu servidor? Envie um e-mail para security@usezn.com com o id do scan (scan_…, exibido em todo relatório) e o que você considera impreciso. Erros de rubrica confirmados são corrigidos em uma nova versão da rubrica, listada no registro de alterações acima. Os donos de servidores também podem pedir a remoção de um relatório publicado sobre o seu servidor. security@usezn.com

A versão atual é a v1.1, atualizada em 2026-10-10. Para solicitar um novo controle, escreva para o mesmo endereço.