Investigação de boa fé nunca é recebida com advogados.

A investigação de segurança torna o produto mais seguro e queremos que o relatório chegue até nós antes de chegar a um atacante. Se seguir esta política, iremos: reconhecer o seu relatório rapidamente, trabalhar consigo para compreender e validar o mesmo, mantê-lo informado enquanto o corrigimos, dar-lhe crédito se assim o desejar e não intentar ou apoiar ações legais contra si pela investigação. Este último compromisso é o objetivo deste documento, e a cláusula 07 estabelece-o em termos.

Envie um e-mail para security@transglot.ai. Inclua o que encontrou, onde o encontrou, os passos para reproduzir o problema, o que um atacante poderia fazer com ele e tudo o que nos ajude a confirmá-lo: um pedido e resposta, um vídeo curto, uma prova de conceito. Informe-nos se deseja receber crédito e sob que nome. Escreva em inglês, se possível. Se quiser encriptar o relatório, solicite numa primeira mensagem e trocaremos uma chave. Também publicamos um ficheiro security.txt com o mesmo endereço, para que um scanner automatizado aponte para uma caixa de correio lida por uma pessoa.

Reconhecemos um relatório no prazo de três dias úteis. Fornecemos uma avaliação inicial, incluindo se conseguimos reproduzi-lo e como o classificámos, no prazo de dez dias úteis. Informamo-lo quando uma correção for lançada e, normalmente, teremos lançado uma para um problema grave ou crítico no prazo de noventa dias após a sua validação, mais rapidamente se o risco estiver ativo. Se uma correção demorar mais tempo, explicaremos o motivo em vez de ficarmos em silêncio. Informá-lo-emos antes de publicarmos qualquer informação sobre o problema e não publicaremos o seu nome sem perguntar.

Por favor, conceda-nos noventa dias a partir do seu primeiro relatório antes de publicar detalhes e, por acordo, um período mais longo se a correção for genuinamente complexa ou se exigir ação por parte do cliente. Não utilizaremos esse período para ocultar o problema: mantê-lo-emos atualizado e, se não conseguirmos corrigi-lo, também lhe informaremos disso, e não nos oporemos à publicação após o término do período. Se um problema estiver a ser ativamente explorado, informe-nos imediatamente e agiremos com essa urgência. Estamos disponíveis para coordenar um aviso conjunto e solicitar um CVE quando apropriado.

A aplicação web de produção e o site de marketing nos nossos próprios domínios, a API REST pública, o ponto de entrega, o editor contextual e as suas superfícies de incorporação, os nossos pacotes de cliente publicados, a entrega e assinatura de webhooks, os nossos fluxos de autenticação e single sign-on e a nossa infraestrutura pública, tal como acessível a partir da internet. Relatórios sobre decisões de design que documentámos como compromissos deliberados, como o pool partilhado de memória de tradução de correspondência exata ou a ausência de encriptação ao nível do disco em volumes ativos, são bem-vindos como argumentos, mas não constituem vulnerabilidades: estão indicados na página de segurança precisamente para que um investigador não perca uma tarde a provar algo que já publicamos.

Qualquer coisa não operada por nós, incluindo o próprio website de um cliente, uma integração de terceiros e qualquer sistema alcançado através de um conector. Negação de serviço, testes volumétricos ou de esgotamento de recursos e qualquer coisa que degrade o serviço para outros utilizadores. Engenharia social, phishing ou tentativas físicas contra o nosso pessoal, os nossos escritórios ou os nossos fornecedores. Spam e relatórios gerados por um scanner automatizado sem análise anexa. Descobertas que sejam apenas um cabeçalho de boas práticas em falta, uma flag de cookie sem impacto demonstrado, uma biblioteca desatualizada sem caminho explorável, um limite de taxa que encontrou ao excedê-lo, um cross-site scripting autoinfligido, um relatório de clickjacking numa página sem ação sensível ou a ausência de uma política de segurança de conteúdo abrangente, que já documentamos como uma lacuna. Vulnerabilidades que exigem acesso físico ao dispositivo desbloqueado de uma vítima ou que exigem um comprometimento ao nível de root da máquina da própria vítima.

If you make a good faith effort to comply with this policy during your research, we will consider your research to be authorised, we will work with you to understand and resolve the issue quickly, and we will not recommend or pursue legal action against you, including under computer misuse, anti-hacking, anti-circumvention or contract law, and including any claim under the Acceptable Use Policy or the Terms of Service that your testing would otherwise breach. If a third party brings an action against you for research conducted under this policy, we will make it known that your activities were authorised. This safe harbour is limited to us: it cannot and does not authorise you to act against a third party, another customer, or anyone else’s systems.

Utilize apenas logins e Contas que lhe pertençam ou para as quais tenha permissão explícita para testar e crie o seu próprio espaço de trabalho gratuito em vez de sondar o de outra pessoa. Não aceda, modifique, copie, exfiltre ou destrua dados que não sejam seus e, se encontrar dados de clientes por acidente, pare, não os guarde e informe-nos imediatamente sobre o que viu para que possamos avaliar a exposição. Não degrade a disponibilidade nem execute testes de carga, stress ou negação de serviço. Não utilize uma descoberta para obter mais acesso do que o necessário para a demonstrar e não mantenha persistência. Não extorja e não condicione a divulgação a um pagamento. Não publique antes do permitido pela cláusula 04. Cumpra a legislação aplicável e quaisquer restrições de controlo de exportações ou sanções que se lhe apliquem.

Atualmente, não existe um programa pago de recompensas por bugs. O que oferecemos é uma resposta rápida e humana, crédito num reconhecimento público se o desejar, uma referência escrita para descobertas graves e o porto seguro acima mencionado. Se iniciarmos um programa pago, publicaremos aqui o âmbito e os intervalos antes de aceitarmos a primeira submissão.

Não lhe pediremos para assinar um acordo de confidencialidade como condição para receber o seu relatório, nem utilizaremos um formulário de submissão de relatórios para o obrigar ao silêncio. Não o ameaçaremos por um relatório que se revele de baixa severidade ou duplicado. Não o reportaremos ao seu empregador, universidade ou plataforma. Se discordarmos da sua classificação de severidade, explicaremos o motivo em vez de fechar o tópico.

Um cliente que encontre uma vulnerabilidade enquanto utiliza o produto está abrangido por esta política e pela sua porto seguro, e reportá-la nunca constitui uma violação da Política de Utilização Aceitável. Reporte-a através do endereço de segurança em vez do suporte normal, para que chegue às pessoas certas sem ficar numa fila de espera. Evite testar com dados de produção pertencentes aos seus próprios utilizadores finais, sempre que possível.

A página de segurança indica as coisas que não construímos, propositadamente, para que um revisor ou investigador as conheça através de nós e não durante a due diligence: os volumes ativos não têm encriptação de disco, o registo de auditoria é apenas de anexação na camada da aplicação e não possui cadeia de hash ou assinatura, não existe uma política ampla de segurança de conteúdo e, atualmente, não possuímos nenhuma certificação de segurança de terceiros. Publicar as nossas próprias lacunas é a forma mais económica de honestidade no setor e poupa uma semana a todos.

Os relatórios de segurança e questões sobre esta política devem ser enviados para security@transglot.ai. Tudo o que não seja uma questão de segurança, incluindo abuso e direitos de autor, deve ser enviado para hello@transglot.ai. Questões de privacidade e proteção de dados devem ser enviadas para privacy@transglot.ai.