Como avaliar se um aplicativo de companhia oferece um canal eficaz para relatar vulnerabilidades?
Um endereço chamado security@empresa.com não prova que exista um processo de divulgação. Um canal eficaz deixa claro quais produtos entram no escopo, que tipos de teste são permitidos, quais ações são proibidas, quais dados devem acompanhar o relato e como a organização confirma, atualiza e coordena uma correção. O RFC 9116 padroniza o arquivo security.txt e exige campos como contato e expiração, mas sua presença não autoriza automaticamente testes. Políticas de organizações como a GSA e programas do Google ilustram como escopo, boa-fé e restrições podem ser descritos. Para um usuário comum, a avaliação deve ser documental: não explore a falha, não acesse dados alheios e não publique detalhes. Se o problema for exposição da própria conta, use também o suporte e as medidas de proteção ao usuário.
Veja se o canal pode ser encontrado sem caça ao contato
Procure página ‘Security’, ‘Vulnerability Disclosure’, ‘Report a vulnerability’ e `/.well-known/security.txt` no domínio oficial. O arquivo deve apontar a contato e política atuais; observe data de expiração e idiomas. Um formulário genérico de atendimento pode receber relatos, mas não é equivalente a um canal técnico se não indicar encaminhamento. Confirme que domínio, certificado e links pertencem à empresa. Não envie detalhes por redes sociais, avaliação de loja ou e-mail encontrado em diretório não oficial, pois isso pode expor a falha e atrasar a triagem.
Leia o escopo antes de descrever qualquer problema
A política deve listar aplicativos, APIs, sites, versões ou domínios incluídos e exclusões. Veja se contas próprias são obrigatórias, se há ambiente de teste e quais dados jamais devem ser acessados. Um aplicativo de companhia pode depender de autenticação, pagamentos, mídia e fornecedores; a política precisa dizer até onde a organização recebe responsabilidade. Se o ativo não aparece, pergunte pelo canal sem realizar teste. Ausência de clareza é uma limitação do programa, não autorização para ‘confirmar’ a vulnerabilidade de forma mais agressiva.
Diferencie relato responsável de teste intrusivo
Um usuário pode reportar comportamento observado na própria conta, tela, rede ou arquivo sem tentar obter acesso adicional. Pare ao encontrar dado de terceiro, capacidade de alteração, credencial ou impacto crescente. Não use automação, não crie carga, não contorne controle, não faça engenharia social e não retenha informação alheia. Regras da GSA e do Google mostram que programas definem limites próprios; eles não são universais. Este artigo serve para avaliar o canal, não para orientar exploração. Se há risco atual à sua conta, reduza exposição e use suporte em paralelo.
Prepare um relato reproduzível e mínimo
Inclua produto e versão, plataforma, conta de teste própria, data, pré-condição, passos mínimos, resultado observado, resultado esperado e impacto limitado ao que você confirmou. Remova tokens, dados pessoais e arquivos de outras pessoas. Use texto claro, capturas redigidas e hash quando necessário; siga a opção de criptografia publicada. Não infle gravidade nem atribua causa sem evidência. Um bom relato permite à equipe reproduzir sem você ampliar o teste. Guarde uma cópia do envio e o identificador técnico, mas não publique a descrição durante a coordenação.
Avalie confirmação, andamento e comunicação
O canal deve confirmar recebimento, fornecer número, indicar como enviar complemento e atualizar o status em intervalos razoáveis declarados. Nem toda política promete prazo de correção, pois severidade e dependências variam; procure pelo menos compromisso de avaliação e coordenação. Resposta automática é início, não evidência de triagem. Observe se pedidos da equipe são específicos e enviados pelo domínio esperado. Não entregue credenciais nem execute novas ações fora do escopo. Quando a organização fecha o caso, peça resumo suficiente para entender se houve correção, duplicidade, não reprodução ou risco aceito.
Procure sinais de processo, não só recompensas
Uma recompensa pode atrair pesquisa, mas não é requisito de um canal responsável. Evidências mais úteis são política datada, security.txt válido, escopo legível, porto seguro condicionado, meio seguro de contato, confirmação, status e reconhecimentos ou boletins anteriores. Verifique se a empresa atualiza regras e corrige links quebrados. Monte uma tabela com encontrado, não encontrado e não testado. Se contato, escopo e limites básicos faltam, classifique o canal como insuficientemente verificável e escolha um meio oficial de suporte; não transforme essa ausência em convite para testar.
Perguntas frequentes
security.txt autoriza testar o aplicativo?
Não. O RFC 9116 deixa claro que a presença do arquivo não concede permissão geral. Leia a política e o escopo.
Um programa precisa pagar recompensa para ser eficaz?
Não. Contato claro, limites, confirmação, acompanhamento e coordenação são sinais mais fundamentais.
Posso publicar a falha se ninguém responder?
Não presuma permissão. Siga a política, evite ampliar risco e procure orientação adequada ao contexto antes de divulgar.