Política de Divulgação de Vulnerabilidades e Bug Bounty — Trilha Hub
Versão 2.1 — em vigor desde 14 de outubro de 2026.
A segurança da plataforma Trilha Hub, de suas APIs e dos dados financeiros que ela processa é uma prioridade. Esta Política explica como reportar uma vulnerabilidade de forma responsável, o que você pode esperar de nós e os critérios do nosso programa de reconhecimento e recompensa.
O objetivo é permitir que pesquisadores de segurança comuniquem falhas de forma responsável, possibilitando sua análise e correção antes de qualquer divulgação pública.
1. Como reportar
Envie o relato para [email protected].
Inclua, sempre que possível:
- descrição da vulnerabilidade e do impacto potencial;
- endpoint, URL ou tela afetada;
- passos para reproduzir, com o mínimo de ambiguidade;
- requisições e respostas relevantes, ou prova de conceito;
- data e hora aproximadas dos testes e o IP de origem que você usou (ajuda a separar seu teste de um ataque real nos nossos logs);
- a conta/organização de teste utilizada;
- recomendação de correção, se você tiver uma.
Assunto recomendado: [SECURITY] Relatório de Vulnerabilidade (ou [SECURITY][CRITICAL] para
vulnerabilidades críticas). Aceitamos relatos em português ou inglês. Você também pode informar o
nome pelo qual deseja ser reconhecido (ver item 16).
2. Nosso compromisso
| Etapa | Prazo |
|---|---|
| Confirmação de recebimento | Até 3 dias úteis |
| Triagem inicial e classificação de severidade | Até 10 dias corridos |
| Atualização de andamento | A cada 15 dias, até a conclusão |
| Correção de vulnerabilidade crítica ou alta | Prioridade máxima; prazo informado na triagem |
3. Escopo
Dentro do escopo
- aplicação web em
app.trilhahub.cloud; - APIs públicas da plataforma (
/api/...); - autenticação e autorização — login, OAuth Google, segundo fator (TOTP);
- isolamento de dados entre Organizações (multi-tenant via RLS no banco);
- subdomínios públicos de lojinha (
{slug}.trilhahub.cloud), quando existirem; - webhooks recebidos pela plataforma (gateway de pagamento, WhatsApp Business);
- o aplicativo instalável (PWA) e o app Android (Capacitor);
- ambientes de produção.
Fora do escopo
- infraestrutura e serviços de terceiros — Asaas (gateway de pagamento), Meta/WhatsApp Business, Google (OAuth/GTM), Oracle Cloud Infrastructure, Oracle Object Storage, Hostinger (e-mail) e OpenAI (Trilha Assistant) — reporte diretamente a eles, salvo quando a falha estiver na forma como o Trilha Hub usa ou implementa a integração;
- o site institucional (
www.trilhahub.cloud, para onde também redireciona o endereço antigoescotismo.trilhahub.cloud) — são páginas estáticas sem backend nem dado pessoal; relate mesmo assim se achar algo, mas não entram no programa de recompensa do item 10; - ambientes de desenvolvimento, teste ou homologação;
- dados ou contas de Organizações reais que não sejam suas.
4. Regras para pesquisa de boa-fé
Faça
- utilize preferencialmente uma conta e uma Organização de teste próprias;
- crie dados fictícios sempre que possível;
- limite a exploração ao mínimo necessário para comprovar a falha;
- pare assim que confirmar a existência da vulnerabilidade;
- reporte imediatamente e dê tempo razoável para a correção antes de divulgar publicamente (ver item 13);
- respeite a privacidade de terceiros.
Não faça
- não acesse, copie, altere ou exclua dados de outras Organizações ou pessoas — se você acidentalmente alcançar dado de terceiro, interrompa a exploração assim que tiver evidência suficiente, não guarde cópia e nos informe;
- não interrompa serviços nem realize ataques de negação de serviço, teste de carga ou envio massivo;
- não use engenharia social contra nossa equipe, clientes ou fornecedores;
- não teste segurança física de instalações;
- não instale backdoor, mantenha persistência, nem faça pivô para outros sistemas;
- não extorqua nem condicione o relato a pagamento;
- não mantenha acesso depois de demonstrar a vulnerabilidade.
Testes de intrusão contratados ou automatizados contra o ambiente de produção exigem autorização prévia e por escrito — solicite pelo mesmo e-mail.
5. Exemplos de vulnerabilidades elegíveis
Podem ser consideradas válidas, entre outras:
- SQL Injection;
- Remote Code Execution (RCE);
- Server-Side Request Forgery (SSRF);
- Cross-Site Scripting (XSS);
- IDOR (Insecure Direct Object Reference);
- Broken Access Control;
- Escalação de privilégios;
- Bypass de autenticação ou de MFA;
- Account Takeover;
- Reuso de refresh token não detectado;
- Acesso a lançamentos, cobranças ou dados de associados de outra Organização — falha de isolamento multi-tenant (RLS);
- Bypass dos limites do plano contratado (entitlements);
- Manipulação indevida de cobranças, mensalidades ou saldo;
- Falha na validação de assinatura de webhook (gateway de pagamento, WhatsApp);
- Exposição de segredos, credenciais ou tokens em resposta de API ou em log;
- Upload arbitrário de arquivo;
- Path Traversal;
- Command Injection;
- Falha criptográfica com impacto real.
6. Atividades proibidas
Não fazem parte deste programa:
- DoS, DDoS ou qualquer ataque que cause indisponibilidade;
- testes de carga;
- brute force em grande escala ou credential stuffing;
- spam, phishing, vishing, smishing ou engenharia social;
- ataques físicos ou tentativas de comprometer funcionários;
- ransomware, malware, persistência em servidores ou movimentação lateral;
- destruição de dados ou alteração deliberada de dados de terceiro;
- exfiltração de banco de dados;
- uso da vulnerabilidade para obtenção de vantagem financeira.
7. O que geralmente não consideramos vulnerabilidade
Salvo demonstração de impacto concreto e explorável:
- ausência de cabeçalho de segurança sem vetor de exploração demonstrado;
- versões de software expostas ou banner informativo;
- Self-XSS;
- Open Redirect simples;
- clickjacking em página sem ação sensível;
- CSRF em formulário sem efeito de estado, ou autopreenchimento habilitado;
- ausência de SPF/DMARC em domínio que não envia e-mail;
- ausência de flags em cookies sem impacto demonstrável;
- dependências desatualizadas sem exploração prática, ou CVE identificado apenas por scanner;
- relatos de "boas práticas" sem impacto (ex.: política de senha considerada fraca por um scanner, quando já atendemos a linha de base);
- rate limiting sem cenário concreto de abuso;
- relatório resultante exclusivamente da saída de uma ferramenta automatizada (Nuclei, Nessus, Burp Scanner, OWASP ZAP, Nikto, Qualys, OpenVAS...), sem análise e validação manual;
- necessidade de acesso físico ao dispositivo, ou de a vítima já estar comprometida por malware.
O uso moderado de scanners automatizados é permitido, desde que não cause impacto aos serviços.
8. Classificação de severidade
A avaliação pode usar conceitos do CVSS, combinados com análise de impacto real para o Trilha Hub.
| Severidade | Exemplos |
|---|---|
| Crítica | Execução remota de código; comprometimento de infraestrutura; acesso administrativo completo; vazamento em massa de dados financeiros ou pessoais; comprometimento de múltiplas Organizações; bypass completo de autenticação; movimentação de fundos ou cobrança sem autorização. |
| Alta | Account Takeover; IDOR envolvendo dados sensíveis; escalação de privilégios; acesso a dados de outra Organização; bypass relevante de autorização; reuso de refresh token. |
| Média | Vulnerabilidades que dependam de condições específicas; exposição limitada de informação; falha com impacto restrito a determinadas operações. |
| Baixa | Exposição de informação de baixo impacto; exploração altamente limitada; melhoria de segurança sem impacto direto relevante. |
9. Relatórios duplicados
Quando duas ou mais pessoas reportarem a mesma vulnerabilidade, é considerado para eventual recompensa o primeiro relatório válido recebido — aquele que já traz informação suficiente para identificar a vulnerabilidade, reproduzir o problema e confirmar o impacto. Relatórios posteriores podem ser classificados como duplicados, mesmo que tragam informação adicional, salvo quando identificarem impacto significativamente diferente ou uma forma independente de exploração.
10. Programa de recompensa
Vulnerabilidades válidas podem receber uma recompensa de até R$ 500,00. O valor é definido considerando severidade, impacto real, qualidade do relatório, facilidade de reprodução, número de Organizações potencialmente afetadas e sensibilidade dos dados envolvidos — o teto não representa garantia de pagamento desse valor para qualquer vulnerabilidade.
Como referência:
| Severidade | Recompensa sugerida |
|---|---|
| Baixa | Reconhecimento ou até R$ 50 |
| Média | Até R$ 150 |
| Alta | Até R$ 300 |
| Crítica | Até R$ 500 |
Não há obrigação de recompensa quando o relatório for duplicado, a vulnerabilidade já for conhecida internamente, não for reprodutível, estiver fora do escopo, resultar de violação desta Política, de exploração abusiva ou de divulgação pública antes da correção, resultar exclusivamente de scanner automatizado, ou não houver impacto de segurança relevante. Mesmo sem recompensa financeira, podemos reconhecer publicamente a contribuição (item 16).
11. Divulgação coordenada
Pedimos que você não divulgue publicamente antes da correção. Nosso prazo padrão é de 90 dias a partir da confirmação de recebimento, prorrogável de comum acordo quando a correção for complexa. Se entendermos que o risco aos usuários exige mais tempo, conversaremos com você; sem acordo, respeitaremos sua decisão de divulgar após o prazo, e faremos nossa própria comunicação aos clientes afetados.
12. Safe Harbor
Pesquisas realizadas de boa-fé e dentro das regras desta Política são consideradas autorizadas pelo Trilha Hub. Não pretendemos iniciar ações legais contra quem respeite o escopo, cumpra esta Política, não cause dano, não obtenha vantagem indevida, não acesse dado além do necessário e não divulgue informação prematuramente. Esta proteção não se aplica a atividade maliciosa, fraudulenta ou realizada fora dos limites definidos aqui.
13. Confidencialidade
Informações recebidas por meio deste programa podem ser usadas para reprodução da vulnerabilidade, correção do problema, auditoria interna e aprimoramento dos nossos controles de segurança. Mantemos registros técnicos do reporte para fins de segurança e auditoria.
14. Reconhecimento público
Com sua autorização, podemos publicar seu nome em uma página de reconhecimento de pesquisadores de segurança. Você pode optar por nome completo, apelido, perfil profissional ou permanecer anônimo.
15. Alterações desta Política
Esta Política pode ser atualizada a qualquer momento para refletir mudanças na plataforma, no escopo, nas regras de segurança ou nos valores de recompensa. A versão publicada em nesta página é considerada a versão vigente.
16. Contato
- Segurança: [email protected]
- Privacidade e dados pessoais: [email protected]
- Arquivo legível por máquina:
/.well-known/security.txt
Documento versionado no repositório do produto. Versão 2.1, vigente desde 14/10/2026 — em
relação à 2.0 (27/08/2026), muda só o item do site institucional no escopo, que citava
escotismo.trilhahub.cloud como site; hoje o endereço só redireciona.
Referência técnica interna: RFC-SEC-001, SEC-IR-005.