Segurança e Bug Bounty

1. Objetivo

A segurança da plataforma Trilha Invoice, de suas APIs, integrações e dados processados é uma prioridade.

Esta política estabelece as regras para o reporte responsável de vulnerabilidades de segurança e define os critérios do programa de reconhecimento e recompensa por vulnerabilidades válidas.

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.

2. Escopo

Estão incluídos no escopo os serviços e recursos mantidos diretamente pelo Trilha Invoice, incluindo:

• Aplicação web do Trilha Invoice;
• APIs públicas e privadas utilizadas pela aplicação;
• Endpoints de autenticação;
• Processos de autorização;
• Gestão de chaves de API;
• Integrações desenvolvidas pelo Trilha Invoice;
• Consulta e processamento de documentos fiscais;
• Emissão de documentos fiscais disponibilizada pela plataforma;
• Webhooks;
• Ambientes de homologação e produção;
• Subdomínios pertencentes ao Trilha Invoice;
• Mecanismos de cobrança e controle de consumo;
• Isolamento de dados entre empresas e usuários.

Integrações de terceiros somente fazem parte do escopo quando a vulnerabilidade estiver relacionada à forma como o Trilha Invoice utiliza ou implementa a integração.

3. Exemplos de vulnerabilidades elegíveis

Podem ser considerados válidos, entre outros:

• SQL Injection;
• Remote Code Execution — RCE;
• Server-Side Request Forgery — SSRF;
• Cross-Site Scripting — XSS;
• IDOR;
• Broken Access Control;
• Escalação de privilégios;
• Bypass de autenticação;
• Bypass de MFA;
• Account Takeover;
• Exposição indevida de dados;
• Vazamento de documentos fiscais;
• Acesso a documentos pertencentes a outro CNPJ;
• Falhas de isolamento entre empresas;
• Uso de chave de API pertencente a outra empresa;
• Bypass dos controles de consumo;
• Manipulação indevida de cobranças;
• Emissão de documento fiscal sem autorização;
• Consulta de documentos fiscais sem autorização;
• Alteração ou exclusão de dados de terceiros;
• Falhas de validação de webhook;
• Exposição de certificados digitais;
• Exposição de tokens, secrets ou credenciais;
• Upload arbitrário de arquivos;
• Path Traversal;
• Command Injection;
• Falhas criptográficas com impacto real.

4. Ambiente de homologação

Sempre que possível, os testes devem ser realizados no ambiente de homologação.

O pesquisador deve evitar realizar testes destrutivos ou invasivos no ambiente de produção.

Quando uma vulnerabilidade somente puder ser demonstrada em produção, o teste deve ser limitado à menor quantidade possível de ações necessárias para comprovar sua existência.

5. Regras para realização dos testes

O pesquisador deve:

• Utilizar preferencialmente contas e empresas próprias;
• Criar dados fictícios sempre que possível;
• Limitar a exploração ao mínimo necessário;
• Não acessar deliberadamente dados de terceiros;
• Não alterar documentos pertencentes a terceiros;
• Não excluir informações;
• Não interromper serviços;
• Não realizar testes que prejudiquem outros usuários;
• Não manter acesso após demonstrar a vulnerabilidade.

Caso durante o teste seja identificado acesso a dados pertencentes a outro cliente, o pesquisador deve interromper imediatamente a exploração após obter evidência suficiente para demonstrar a falha.

6. Certificados digitais

O Trilha Invoice poderá utilizar certificados digitais para autenticação, consulta ou emissão de documentos fiscais.

Não é permitido:

• Exportar certificados digitais pertencentes a terceiros;
• Fazer download de chaves privadas;
• Utilizar certificados obtidos durante um teste;
• Utilizar certificados para consultar ou emitir documentos adicionais;
• Divulgar certificados ou suas respectivas senhas.

Caso seja identificado acesso indevido a um certificado digital ou chave privada, o teste deve ser interrompido imediatamente.

7. Chaves de API e tokens

Caso uma vulnerabilidade permita visualizar uma chave de API, token ou credencial pertencente a outro usuário ou empresa:

• Não utilize a credencial;
• Não realize chamadas adicionais com ela;
• Não tente descobrir seu nível de acesso;
• Preserve apenas a evidência mínima necessária;
• Informe imediatamente o Trilha Invoice.

8. Dados fiscais

Documentos fiscais podem conter informações empresariais, tributárias e pessoais.

Caso seja identificado acesso indevido a documentos pertencentes a outra organização:

• Não faça download em massa;
• Não consulte documentos adicionais;
• Não compartilhe os documentos;
• Não armazene os arquivos;
• Não publique informações existentes nesses documentos.

Uma única evidência ou quantidade mínima de registros é suficiente para demonstrar a vulnerabilidade.

9. Atividades proibidas

Não fazem parte deste programa:

• DoS;
• DDoS;
• Ataques que causem indisponibilidade;
• Testes de carga;
• Brute force em grande escala;
• Credential stuffing;
• Spam;
• Engenharia social;
• Phishing;
• Vishing;
• Smishing;
• Ataques físicos;
• Tentativas de comprometer funcionários;
• Ransomware;
• Malware;
• Persistência em servidores;
• Movimentação lateral;
• Destruição de dados;
• Alteração deliberada de dados de terceiros;
• Exfiltração de banco de dados;
• Download massivo de documentos;
• Uso da vulnerabilidade para obtenção de vantagem financeira.

10. Sistemas de terceiros

Não fazem parte do programa vulnerabilidades existentes exclusivamente em serviços de terceiros.

Exemplos:

• Portal Nacional da NF-e;
• Portal Nacional da NFS-e;
• SEFAZ;
• Prefeituras;
• Gateways de pagamento;
• Bancos;
• Provedores de cloud;
• Serviços do Google;
• Meta;
• WhatsApp;
• Serviços de e-mail;
• Autoridades certificadoras.

Entretanto, uma vulnerabilidade na integração desenvolvida pelo Trilha Invoice com esses serviços poderá ser considerada válida.

11. Vulnerabilidades normalmente não elegíveis

Normalmente não serão consideradas para recompensa, salvo quando houver impacto relevante demonstrado:

• Ausência de headers de segurança;
• Versões de software expostas;
• Self-XSS;
• Open Redirect simples;
• Clickjacking sem operação sensível;
• Informações públicas;
• Enumeração simples de usuários;
• Recomendações genéricas de TLS;
• Ausência de flags em cookies sem impacto demonstrável;
• Dependências desatualizadas sem exploração prática;
• CVEs identificados apenas por scanner;
• Problemas exclusivamente de UX;
• Rate limiting sem cenário concreto de abuso;
• Relatórios exclusivamente automatizados;
• Vulnerabilidades em versões antigas de navegadores sem suporte;
• Problemas em dispositivos comprometidos pelo próprio usuário.

12. Scanners automatizados

O uso moderado de ferramentas automatizadas é permitido, desde que não cause impacto aos serviços.

Não serão considerados relatórios contendo apenas a saída de ferramentas como:

• Nuclei;
• Nessus;
• Burp Scanner;
• OWASP ZAP;
• Nikto;
• Qualys;
• OpenVAS;

sem análise e validação manual da vulnerabilidade.

13. Como reportar

O relatório deve conter, sempre que possível:

• Descrição da vulnerabilidade;
• Endpoint afetado;
• Ambiente afetado;
• Passo a passo de reprodução;
• Requisições e respostas relevantes;
• Evidências;
• Impacto esperado;
• Conta utilizada para os testes;
• Possível recomendação de correção.

O pesquisador também pode informar o nome pelo qual deseja ser reconhecido.

Contato de segurança: [email protected]

Assunto recomendado: [SECURITY] Relatório de Vulnerabilidade

Para vulnerabilidades críticas: [SECURITY][CRITICAL] Vulnerabilidade Crítica

14. Relatórios duplicados

Quando duas ou mais pessoas reportarem a mesma vulnerabilidade, será considerado para eventual recompensa o primeiro relatório válido recebido.

Um relatório somente será considerado válido quando apresentar informações suficientes para:

1. Identificar a vulnerabilidade;
2. Reproduzir o problema;
3. Confirmar o impacto.

Relatórios posteriores poderão ser classificados como duplicados, mesmo que apresentem informações adicionais.

Caso um relatório posterior identifique impacto significativamente diferente ou uma nova forma independente de exploração, o Trilha Invoice poderá avaliá-lo separadamente.

15. Classificação de severidade

A avaliação poderá utilizar conceitos do CVSS, combinados com análise de impacto real para o Trilha Invoice.

16. Programa de recompensa

Vulnerabilidades válidas poderão receber uma recompensa de até R$ 500,00.

O valor será definido considerando:

• Severidade;
• Impacto real;
• Qualidade do relatório;
• Facilidade de reprodução;
• Número de usuários potencialmente afetados;
• Sensibilidade dos dados envolvidos;
• Possibilidade de exploração;
• Qualidade técnica das evidências.

O valor máximo não representa garantia de pagamento de R$ 500,00 para qualquer vulnerabilidade. A definição do valor da recompensa é de responsabilidade do Trilha Invoice.

Como referência, a faixa sugerida:

O valor poderá ser ajustado conforme o impacto real identificado.

17. Situações sem recompensa

Não haverá obrigação de recompensa quando:

• O relatório for duplicado;
• A vulnerabilidade já for conhecida internamente;
• O relatório não permitir reprodução;
• A vulnerabilidade não estiver no escopo;
• As regras desta política forem violadas;
• Houve exploração abusiva;
• Houve divulgação pública antes da correção;
• O relatório resultar exclusivamente de scanner automatizado;
• Não houver impacto de segurança relevante.

O Trilha Invoice poderá ainda reconhecer publicamente uma contribuição mesmo quando não houver recompensa financeira.

18. Divulgação responsável

Vulnerabilidades não devem ser divulgadas publicamente antes de sua correção.

Solicitamos que o pesquisador permita tempo razoável para:

1. Investigar;
2. Reproduzir;
3. Desenvolver a correção;
4. Testar;
5. Publicar a correção.

Qualquer divulgação pública deverá ser previamente coordenada com o Trilha Invoice.

19. Safe Harbor

Pesquisas realizadas de boa-fé e dentro das regras desta política serão consideradas autorizadas pelo Trilha Invoice.

Não pretendemos iniciar ações legais contra pesquisadores que:

• Respeitem o escopo;
• Cumpram esta política;
• Não causem danos;
• Não obtenham vantagem indevida;
• Não acessem dados além do necessário;
• Não divulguem informações prematuramente;
• Reportem a vulnerabilidade de forma responsável.

Esta proteção não se aplica a atividades maliciosas, fraudulentas ou realizadas fora dos limites definidos nesta política.

20. Confidencialidade

Informações recebidas por meio do programa poderão ser utilizadas para:

• Reprodução da vulnerabilidade;
• Correção do problema;
• Auditoria interna;
• Aprimoramento dos controles de segurança.

O Trilha Invoice poderá manter registros técnicos relacionados ao reporte para fins de segurança e auditoria.

21. Reconhecimento público

Com autorização do pesquisador, o Trilha Invoice poderá publicar seu nome em uma página de reconhecimento de pesquisadores de segurança.

O pesquisador poderá optar por:

• Nome completo;
• Apelido;
• Perfil profissional;
• Permanecer anônimo.

22. Alterações desta política

Esta política poderá ser atualizada a qualquer momento para refletir mudanças:

• Na plataforma;
• No escopo;
• Nas regras de segurança;
• Nos valores das recompensas;
• Nas tecnologias utilizadas.

A versão publicada no site do Trilha Invoice será considerada a versão vigente.

23. Princípio geral

O programa existe para incentivar pesquisas realizadas de forma ética e responsável.

Ao identificar uma vulnerabilidade:

Não é necessário demonstrar todo o impacto possível quando já houver evidência técnica suficiente de que a vulnerabilidade existe.