Fiatside

Documento legal

Política de divulgação responsável

Se você encontrar uma falha, preferimos ouvi-la de você do que de um incidente. Este documento declara o que você pode testar, o que é proibido e com que rapidez respondemos.

Versão
1.0.0
Válido a partir de
15 September 2026
Última atualização
2 September 2026

Este documento é um modelo e deve ser revisado por um consultor jurídico antes de ser colocado em produção

O texto abaixo foi redigido com base nas obrigações aplicáveis a um prestador de serviços de ativos digitais, mas ainda não foi validado por um advogado na jurisdição de estabelecimento. Portanto, não é executável como está e não deve ser tratado como um compromisso contratual definitivo.

Conteúdo do documento
  1. 01Preferimos saber por você
  2. 02Escopo
  3. 03Regras de teste
  4. 04Como relatar
  5. 05Nossos tempos de resposta
  6. 06Após a correção
01

Preferimos saber por você

Um serviço que movimenta dinheiro sempre acaba sendo testado, por pessoas bem-intencionadas ou não. Preferimos aprender sobre uma falha por meio de um relatório do que por um incidente, e nos comprometemos a não processar ninguém por pesquisas realizadas de boa-fé dentro do escopo aqui descrito.

Nenhuma recompensa financeira é oferecida neste estágio. Não anunciamos um programa de recompensas que não poderíamos honrar. O que oferecemos é concreto: um rápido aceno, um contraponto técnico, acompanhamento até a correção e crédito público, se você quiser.

02

Escopo

No escopo

  • O site público e suas páginas de aplicação.
  • Endpoints de interface de programação expostos publicamente.
  • Mecanismos de autenticação, sessão e redefinição de senha.
  • Qualquer falha que leve à leitura, alteração ou desvio de dados de outro usuário.
  • Qualquer falha que permita alterar um valor, um beneficiário, uma taxa ou um estado de ordem.
  • Erros de configuração que exponham um segredo, um backup ou um ambiente interno.

Fora do escopo

  • Os serviços próprios de nossos fornecedores: relate-os diretamente ao editor responsável, que administra seu próprio programa.
  • Relatórios produzidos por um scanner automatizado sem prova de explorabilidade.
  • Cabeçalhos ou achados de configuração sem impacto demonstrado — um cabeçalho recomendado ausente, um cookie sem atributo em conteúdo público.
  • Engenharia social contra nossa equipe, nossos fornecedores ou nossos usuários.
  • Negação de serviço, inundação e teste de carga, em qualquer forma.
  • Vulnerabilidades que exigem acesso físico a um dispositivo já comprometido.
03

Regras de teste

Estas regras não são formalidades: elas definem exatamente o que permanece coberto por nosso compromisso de não processar.

  1. Use apenas suas próprias contas e seus próprios dados. Crie uma segunda conta se precisar testar o isolamento entre usuários.
  2. Pare assim que o acesso for demonstrado. Não leia, copie ou exfiltre dados pertencentes a terceiros.
  3. Não degrade o serviço: sem inundação, sem exclusão, sem modificação de dados de produção além dos seus.
  4. Não torne a falha pública antes de ser corrigida, ou antes que o prazo que acordarmos juntos expire.
  5. Se você alcançar involuntariamente dados pessoais, pare imediatamente, não os mantenha e mencione isso em seu relatório.
04

Como relatar

Um relatório útil contém cinco elementos: o componente afetado, o impacto real, etapas de reprodução, uma evidência mínima e os carimbos de data/hora de seus testes. O resto é conforto.

Canal de relato

Nenhuma chave pública de criptografia é publicada ainda. Não publicaremos uma antes que ela seja realmente mantida e testada: uma chave exibida, mas não monitorada, é pior do que nenhuma chave. Se seu relatório contiver material sensível, diga em uma linha primeiro e combinaremos um canal criptografado.

[email protected]

Nunca inclua em um relatório dados pessoais pertencentes a terceiros, um identificador real ou um segredo completo. Uma captura parcialmente redigida é suficiente para demonstrar o acesso.

05

Nossos tempos de resposta

SeverityFirst responseFix target
Critical — funds, keys or identity data exposedWithin 4 hoursFix or mitigation within 72 hours
High — authentication or authorisation bypassWithin 24 hoursFix within 14 days
Medium — limited information leak, partial denial of serviceWithin 72 hoursFix within 60 days
Low — configuration defect with no demonstrated impactWithin 120 hoursHandled in the regular development flow
These times run from receipt of the report, weekends included for the critical level.

Você então recebe uma atualização de status pelo menos a cada duas semanas até o encerramento, mesmo quando não há nada de novo a anunciar. O silêncio é o que leva um pesquisador a publicar: preferimos evitá-lo.

06

Após a correção

  • Confirmamos a correção e permitimos que você a verifique antes de qualquer encerramento.
  • Publicamos uma nota de incidente quando a falha poderia ter exposto dados, mesmo que nenhum abuso seja encontrado.
  • Damos crédito público a você, se quiser, sob o nome ou identificador de sua escolha, ou não, se preferir anonimato.
  • Acordamos uma data de publicação com você, se quiser escrever sua própria análise.
07

Histórico de versões

VersãoÚltima atualizaçãoNature of the change
1.0.02 September 2026Primeira publicação do documento.

Âncoras estáveis: cada seção carrega um identificador que não mudará. Você pode citar uma cláusula por seu link direto.