Visão Geral de Segurança

Esta Visão Geral de Segurança descreve as medidas técnicas e organizacionais que a Melaya Labs LLC ("Melaya") aplica atualmente para proteger a confidencialidade, a integridade e a disponibilidade da plataforma Melaya. Destina-se a oferecer a usuários potenciais e existentes, compradores corporativos e auditores uma visão honesta do que está em produção hoje, do que está em andamento e do que ainda não foi implementado. Quando uma capacidade for aspiracional ou estiver em andamento, ela é marcada explicitamente como tal, em vez de ser ocultada por linguagem vaga. Segurança é uma responsabilidade compartilhada: a Melaya é responsável pela segurança da plataforma, e os clientes são responsáveis pela segurança do que constroem, fazem upload e executam sobre ela.

1. Criptografia em Trânsito e em Repouso

Todos os dados em trânsito entre os clientes dos usuários e os Serviços são protegidos pelo Transport Layer Security (TLS) versão 1.2 ou superior, com encerramento no Cloudflare na borda da implantação. O perfil TLS de produção segue o guia de compatibilidade Intermediária da Mozilla: somente TLS 1.2 e 1.3, somente conjuntos de cifras ECDHE, somente cifras AEAD com sigilo futuro perfeito, HSTS com max-age de dois anos e a diretiva preload, e uma Política de Segurança de Conteúdo estrita com uma lista de permissões explícita para connect-src. A Política de Segurança de Conteúdo é aplicada em ambas as superfícies: o servidor de API define default-src 'none' por meio do seu middleware de cabeçalhos de segurança, e a aplicação web pública utiliza uma política que inclui na lista de permissões nossos próprios backends, além dos provedores de pagamento e de autenticação, bloqueia conteúdo de plugins e sequestros via base-tag ou form-action, e confina a execução de scripts, de modo que um script injetado não consiga exfiltrar dados para uma origem atacante. O perfil TLS completo, a lista de cifras confirmada e a cadência de revisão trimestral estão documentados no runbook TLS Baseline no cofre de segurança interno. As chamadas internas de serviço a serviço dentro da nossa infraestrutura são realizadas por loopback ou links de rede privada.

A criptografia em repouso é implementada atualmente na camada de aplicação por meio de criptografia de envelope no nível de campo. A criptografia de disco completo na camada de armazenamento ainda não está habilitada: os dispositivos de bloco de produção não estão criptografados no nível de disco no momento. A criptografia no nível de volume usando LUKS foi selecionada como o caminho de remediação e é um item confirmado no roadmap de segurança. Até que seja executada, a Melaya não apresenta a criptografia na camada de disco nem a criptografia de volume gerenciada pelo provedor como um controle ativo.

Os valores sensíveis são protegidos por uma camada de criptografia de envelope no nível da aplicação, implementada em nosso serviço de criptografia de envelope. As credenciais de API de exchanges (chave, segredo, senha), as credenciais de conector por usuário e os tokens OAuth, bem como os segredos TOTP e os códigos de recuperação de MFA, são envolvidos com AES-256-GCM usando uma chave mestra de 256 bits mantida apenas no processo do servidor, antes de serem enviados ao provedor de cofre Infisical ou gravados na tabela de fallback agents.credentials. O formato de transmissão carrega um identificador de chave explícito (v1:<kid>:<base64(iv|ciphertext|tag)>) para que o servidor possa aceitar múltiplas chaves válidas durante uma janela de rotação e direcionar as leituras para a chave exata que envolveu cada valor. Novas gravações sempre utilizam a chave ativa, que é a primeira entrada na lista de chaves configurada. A rotação é um procedimento de três versões que nunca interrompe a plataforma: adiciona-se a nova chave como segunda entrada (as gravações ainda vão para a chave antiga, a nova chave é somente leitura), promove-se a primeira posição (as gravações passam para a nova chave, a chave antiga permanece legível), re-envolve-se as linhas históricas vinculadas ao identificador de chave retirada e, em seguida, remove-se a entrada antiga. Nem o Infisical nem o host Postgres veem as credenciais em texto simples em nenhum momento: a comprometimento de qualquer um dos subprocessadores isoladamente produz apenas texto cifrado, e o invasor ainda precisaria de uma chave de envelope configurada para recuperar qualquer chave de exchange. Um script de migração único tratou as linhas legadas em texto simples anteriores à existência da camada de envelope. A varredura foi concluída no banco de dados de produção e seu verificador de ida e volta (envelope-verify.ts, 7/7 cenários) retorna zero em cada execução de CI e contra a produção em funcionamento.

2. Isolamento de Tenant e de Pipeline

A plataforma impõe isolamento lógico entre inquilinos na camada de aplicação. Cada pedido autenticado inclui um identificador de utilizador derivado de um JSON Web Token validado, e cada consulta à base de dados, acesso ao armazenamento de objetos e pesquisa no índice de recuperação é limitada por esse identificador através de SQL parametrizado e do contexto tRPC. Os índices de recuperação criados para a Estrutura Agêntica são armazenados por pipeline e só são devolvidos a consultas originadas na pipeline que os detém. O estado do motor, as configurações de estratégia e os históricos de ordens são igualmente particionados por utilizador. A segurança ao nível de linha do Postgres é aplicada como uma camada de defesa em profundidade por detrás do âmbito da camada de aplicação: FORCE ROW LEVEL SECURITY está ativo em produção em 44 tabelas nos esquemas agents.* e cex.* ao abrigo de 117 políticas de segurança ao nível de linha, e a aplicação liga-se sob uma função dedicada de baixo privilégio que executa NOBYPASSRLS e, por conseguinte, não consegue ver entre inquilinos mesmo que uma consulta se esqueça acidentalmente da sua cláusula WHERE user_id. O contexto de segurança ao nível de linha por pedido define o identificador do inquilino e a função como parâmetros de sessão antes de qualquer consulta ser executada, e o conjunto de ligações emite DISCARD ALL na libertação para que o contexto não possa transitar entre inquilinos. Dezassete cenários entre inquilinos no nosso verificador rls-verify.ts terminam com zero contra a base de dados em produção em cada execução de CI, incluindo casos de SELECT, INSERT, UPDATE, DELETE, reatribuição de propriedade, desvio de administrador, linha zero sem contexto e regressão de fuga de contexto.

3. Gerenciamento de Chaves e Segredos

Os segredos de aplicação, chaves de assinatura, credenciais de banco de dados e chaves de API de terceiros utilizados pela própria Melaya são armazenados em um arquivo de segredos controlado pelo operador, carregado na inicialização do processo, e em nosso provedor de cofre. Eles nunca são confirmados no controle de versão e os valores de produção não são compartilhados entre desenvolvedores. A chave de criptografia de envelope é uma chave de criptografia dedicada, mantida apenas no repositório de segredos do operador, separadamente das credenciais do banco de dados Postgres e separadamente do token do cofre Infisical, de modo que o comprometimento de qualquer um dos três não expõe as credenciais de exchange em texto simples. Recomenda-se fortemente que os clientes limitem cada chave de API de exchange somente a permissões de negociação, desabilitem saques na plataforma emissora e apliquem a lista de permissões de IP quando a plataforma oferecer suporte a essa função.

Os tokens de sessão são assinados sob uma janela de rotação de múltiplas chaves. O servidor aceita um conjunto ordenado de chaves de assinatura, cada uma identificada por um identificador de chave curto. Novos tokens são assinados com a primeira chave (ativa) e carregam esse identificador no cabeçalho JWT para verificação em O(1). Os tokens emitidos sob qualquer chave retirada na janela continuam a ser verificados até que seu TTL de sete dias expire, momento em que a chave retirada pode ser removida. Tokens expirados são rejeitados imediatamente, mesmo que uma chave não ativa os aceitaria. As viagens de verificação são asseguradas em nosso verificador jwt-keys-verify.ts.

4. Autenticação e Controle de Acesso

A autenticação do usuário é baseada em e-mail e senha com hash bcrypt no fator de trabalho 12, combinada com limitação de taxa nos endpoints de login, registro e recuperação de senha (20 tentativas por IP por 15 minutos, aplicada por um limitador distribuído com suporte em Redis). Os tokens de sessão são emitidos como JSON Web Tokens com validade de sete dias e vinculados às declarações de usuário, função e nível. O controle de acesso baseado em função distingue user de admin, e o controle de acesso baseado em nível condiciona funcionalidades ao catálogo de quatro níveis. Toda ação de consequência é verificada no lado do servidor. As verificações no lado do cliente são apenas uma indicação visual de experiência do usuário e nunca são utilizadas como controle de segurança.

A autenticação de dois fatores está disponível para todos os usuários por meio do perfil padrão TOTP (RFC 6238, SHA-1, 6 dígitos, período de 30 segundos, tolerância de desvio de ±1 janela) e é compatível com todos os principais aplicativos autenticadores. Os segredos compartilhados TOTP são gerados no servidor com 160 bits de entropia, envolvidos pela camada de criptografia de envelope descrita na seção 1 e armazenados em uma coluna envolvida na linha do usuário. Os códigos de recuperação são gerados uma única vez no momento do cadastro, processados com hash bcrypt no fator de trabalho 12 e, em seguida, envolvidos uma segunda vez pela camada de envelope, de modo que um comprometimento isolado do banco de dados não permita recuperá-los. O cadastro é um processo de duas etapas que exige que o usuário comprove ter configurado seu autenticador inserindo um código válido antes que o segundo fator seja marcado como ativo. O fluxo de login passa por uma verificação de senha, seguida de um token de desafio de curta duração (cinco minutos) e, em seguida, uma verificação de código que consome atomicamente a linha de desafio. Um token de desafio capturado não pode ser reproduzido após um consumo bem-sucedido. O MFA é obrigatório para adicionar credenciais de API de CEX e para gerar chaves de API da plataforma, as duas ações de maior impacto sobre fundos no produto. Cada resultado de desafio MFA (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) é gravado no log de auditoria append-only descrito na seção 6, para que os padrões de desafio sejam auditáveis e resistentes a adulterações.

O acesso de funcionários da Melaya aos sistemas de produção é concedido individualmente, por engenheiro, sob um fluxo de aprovação documentado de duas pessoas, e revogado quando não for mais necessário. O provisionamento de acesso requer aprovação de alguém diferente do solicitante, e o processo de desligamento desativa a conta, rotaciona as chaves de assinatura JWT para invalidar as sessões ativas, revoga as chaves de API e remove as chaves SSH. As entradas privilegiadas obsoletas em sudoers e as chaves autorizadas SSH são removidas sessão a sessão, e uma cadência de revisão de acesso trimestral está documentada. A separação completa entre o usuário de implantação e o usuário de execução do serviço, de modo que um processo de serviço comprometido não possa pivotar para o caminho de implantação, está registrada como um controle planejado no roadmap de segurança.

5. Rate Limiting de Rede e Infraestrutura

A limitação de taxa é aplicada na camada de aplicação por um armazenamento compartilhado com suporte em Redis, de modo que os limites são globais em todas as instâncias do servidor, e não por processo. Dois buckets configurados de forma independente são aplicados: um bucket restrito nos endpoints de autenticação (20 tentativas por IP por janela de 15 minutos) e um bucket geral de API (200 requisições por IP por minuto). O limitador opera com falha fechada: se o armazenamento Redis estiver inacessível, os endpoints de autenticação negam o acesso em vez de permitir a passagem. O wrapper do limitador com suporte a lotes tRPC é verificado por nosso verificador rate-limit-verify.ts (7/7 cenários, incluindo o ataque de contrabando via lote).

O tráfego de borda é gerenciado pela Cloudflare, com WAF, detecção de bots e bloqueio geográfico em caminhos de alto risco. Um scaffold Terraform para a zona da Cloudflare está confirmado junto com um runbook operacional abrangendo detecção de desvio, substituição de emergência e a regra de reconciliação de 24 horas. A importação e reconciliação da zona atualmente gerenciada manualmente com esse scaffold está em andamento e é a tarefa de liberação antes do agendamento do primeiro teste de penetração externo.

6. Monitoramento, Logging e Auditoria

A plataforma emite registos estruturados a partir do servidor tRPC Node.js, do Motor Rust, do trabalhador Python e da borda. Todos os registos ao nível do servidor e do contentor (o diário systemd, os registos do sistema do servidor, os registos de acesso e erro do nginx, o stdout do contentor de CI e de source-forge e todos os registos da aplicação Melaya) são enviados fora do servidor em tempo real para um inquilino do Grafana Cloud Loki na mesma região que o servidor de produção, através de um coletor Grafana Alloy, para que o registo de auditoria sobreviva a uma comprometimento do servidor ou perda de disco. As ligações de rede de saída são registadas por uma regra de registo de saída na camada de rede e reencaminhadas para o mesmo repositório externo; este tráfego de saída é registado e monitorizado atualmente, enquanto a lista de permissões de saída baseada em negação forçada permanece um item pendente no roteiro.

Eventos relevantes para a segurança (resultados de autenticação, resultados de desafios MFA, adições e remoções de credenciais de API de CEX, emissão e revogação de chaves de API da plataforma, alterações e reversões de nível) são adicionalmente gravados em uma tabela agents.audit_log append-only. O schema revoga UPDATE e DELETE da função da aplicação, mantém uma cadeia de hash criptográfica sobre as linhas (prev_hash / row_hash), armazena o IP do ator somente como um digest HMAC-SHA256 com chave secreta, e não em texto simples (pois SHA-256 simples é vulnerável a ataques de dicionário), e disponibiliza uma tabela auxiliar agents.audit_log_tombstone para o apagamento previsto no Artigo 17 do GDPR, sem jamais alterar a cadeia. Um verificador diário (verify-audit-chain.ts) percorre a cadeia de ponta a ponta, verifica a monotonicidade dos timestamps com uma tolerância de ±2 segundos de NTP e emite um digest âncora adequado para armazenamento externo somente de gravação. Seis cenários de adulteração em audit-log-verify.ts retornam zero contra a produção em funcionamento.

7. Gerenciamento de Vulnerabilidades

Cada commit executa npm audit --production e uma varredura de sistema de arquivos com Trivy como parte do CI. O Trivy é invocado duas vezes em cada build: uma vez no modo bloqueante com ignore-unfixed: true, de modo que achados acionáveis reprovam a verificação, e uma vez com ignore-unfixed: false e sem bloqueio, de modo que a superfície completa de vulnerabilidades é enviada para a aba de Segurança do repositório como evidência de conformidade. O host de produção executa unattended-upgrades com o canal de segurança habilitado e uma janela de reinicialização automática. As imagens de contêiner de terceiros para os serviços de CI, source-forge, cofre de segredos, Postgres e Redis são revisadas antes de atualizações de versão, rastreadas no runbook de Cadência de Correções no cofre de segurança interno e monitoradas por um detector diário de desvio de digest de imagem, que emite alertas dentro de 24 horas após qualquer rotação silenciosa de imagem.

A Melaya ainda não realizou um teste de penetração externo por terceiros. O escopo do engajamento, incluindo ativos dentro e fora do escopo, regras de engajamento, lista de fornecedores candidatos exigindo acreditação CREST e cadência de remediação pós-engajamento, está confirmado no runbook interno Pentest Scope, para que a seleção do fornecedor possa avançar assim que a reconciliação do IaC da Cloudflare da seção 5 for concluída. Nenhuma afirmação de "pentest anual" é feita em qualquer lugar na documentação da Melaya.

8. Desenvolvimento de Software Seguro

As alterações na plataforma passam por controle de versão com revisão por pares antes da mesclagem. O modo strict do TypeScript e a análise estática são executados em cada build de cliente e servidor. O gitleaks é executado como hook pré-commit e no CI, com uma lista de permissões com escopo por caminho em vez de uma global, de modo que a divulgação acidental de credenciais reprova o build antes da mesclagem. Todas as ações de CI são fixadas por SHA de commit para evitar ataques de reescrita de tag na cadeia de suprimentos. As implantações em produção passam por um wrapper SSH restrito do Jenkins com uma restrição command= em authorized_keys, de modo que, mesmo um runner de CI comprometido, só pode invocar as operações explícitas resync <service> e log <service> para os serviços Melaya da lista de permissões: sem shell arbitrário, sem travessia de sistema de arquivos, sem escalada de privilégios além da própria reinicialização do serviço. Cada invocação do pipeline de implantação é registrada externamente no tenant Grafana Cloud Loki para auditoria, juntamente com um registro de proveniência confirmado vinculando o binário em execução ao seu commit de origem.

9. Resposta a Incidentes

A Melaya mantém um runbook escrito de Resposta a Incidentes abrangendo a declaração de severidade (quatro níveis de severidade), atribuições de função (Comandante de Incidente, líder técnico, comunicações, escriba), uma lista de verificação de contenção que inclui etapas explícitas de rotação de chave de envelope, chave JWT e chave HMAC de IP de log de auditoria, a matriz de notificação de 72 horas do Artigo 33 do GDPR e um modelo de post-mortem. O runbook está confirmado no cofre de segurança interno e é tratado como um documento em constante atualização: o primeiro exercício tabletop está agendado para 2026-07-15, e o runbook está explicitamente marcado como "não ativo" em seus próprios procedimentos até que esse exercício seja realizado. Os engenheiros de plantão respondem a incidentes reais atualmente. O requisito do exercício tabletop refere-se ao exercício formal, não à existência do caminho de resposta.

10. Backup e Recuperação de Desastres

Os objetivos de Recovery Time Objective (RTO) e Recovery Point Objective (RPO) por subsistema estão publicados no runbook interno RTO RPO: o nível agents.* tem como alvo RTO de 15 minutos e RPO de 2 horas, o armazenamento de credenciais de CEX tem como alvo RTO de 5 minutos e RPO de 1 hora, o Infisical e o armazenamento de objetos têm como alvo RTO de 4 horas e RPO de 1 hora, e o Redis não tem backup e é reconstruído na reconexão. Os mecanismos de backup combinam o arquivamento contínuo WAL com uma janela de recuperação point-in-time de 14 dias, um dump lógico noturno retido entre regiões, um backup base mensal e uma exportação diária de âncora do log de auditoria somente de gravação para um local externo. Todos os artefatos de backup são comprimidos, com checksum e criptografados com restic. A verificação de restauração é executada em duas cadências: um trabalho semanal automatizado realiza uma verificação de integridade do restic e uma restauração parcial em um diretório temporário, e o primeiro exercício completo de restauração em um ambiente descartável está agendado para 2026-07-15, após o qual seu atestado escrito de tempo de restauração e verificação de integridade será confirmado no mesmo runbook. A Melaya opera a partir de uma única região de hospedagem primária atualmente. Isso é declarado claramente, e os controles compensatórios (dumps noturnos entre regiões, arquivamento contínuo WAL, uma sonda de integridade entre regiões e failover DNS da Cloudflare) limitam o RTO máximo de perda total da região a aproximadamente 24 horas como um risco documentado e aceito.

11. Continuidade de Negócios

Um Plano de Continuidade de Negócios escrito está confirmado no cofre de segurança interno, abrangendo resposta à interrupção da região primária, falha do provedor Postgres, interrupção do cofre Infisical (o servidor continua atendendo as sessões existentes por meio de credenciais em cache, e novas gravações de CEX são recusadas com um erro visível ao usuário), interrupção do Stripe (as assinaturas existentes não são afetadas), matriz de disponibilidade de pessoal e uma tabela de contingência por fornecedor. O plano é revisado na mesma cadência trimestral que o baseline de TLS, com uma revisão completa anual como parte do exercício tabletop.

12. Segurança de Fornecedores e Suboperadores

A Melaya usa subprocessadores e provedores de infraestrutura para as funções descritas na lista pública de Subprocessadores. A função contratual, a localização e a salvaguarda de transferência de cada provedor devem ser avaliadas com base na implantação e no contrato efetivos; provedores de modelos, conectores, comerciantes ou ferramentas selecionados pelo cliente podem atuar segundo as instruções do cliente e seus próprios termos, e não segundo os contratos de fornecedores da Melaya. Clientes empresariais recebem os direitos aplicáveis de notificação e objeção a subprocessadores conforme seu contrato ou aditivo de tratamento de dados. O principal ambiente hospedado da Melaya é atualmente operado em Singapura, país não abrangido por uma decisão de adequação da União Europeia; portanto, as transferências aplicáveis exigem um mecanismo legal de transferência e salvaguardas suplementares quando necessário. Um local runner executa Python, arquivos locais, operações de recuperação e credenciais selecionadas em hardware controlado pelo cliente, mas, conforme o modo selecionado, a configuração da execução, o conteúdo de dispatch assinado, a entrega de credenciais selecionadas, eventos de colaboração, telemetria, solicitações a modelos em nuvem ou chamadas de conectores ainda podem passar pela Melaya ou por terceiros, ou alcançá-los. A página pública de Subprocessadores, o contrato do cliente e o fluxo efetivo de dados - e não apenas a palavra “local” - determinam as divulgações sobre destinatários e residência dos dados.

13. Postura de Compliance

A Melaya está construindo seus controles com os Critérios de Serviços de Confiança do SOC 2 e a ISO/IEC 27001 em mente. Na data deste documento, a Melaya NÃO possui SOC 2 Tipo I, SOC 2 Tipo II, ISO/IEC 27001 nem qualquer atestação de segurança equivalente de terceiros, e nenhuma avaliação por organismo examinador ou certificador foi conduzida. Esses são marcos aspiracionais em nosso roadmap. Qualquer cliente potencial que exija uma atestação atualmente deve esperar um entregável de análise de lacunas, e não um relatório concluído. Clientes corporativos podem solicitar nossa matriz de controles atual e a lista de remediações em andamento entrando em contato pelo [email protected].

Um modelo de Acordo de Tratamento de Dados em quinze seções foi redigido e commitado no cofre interno de segurança. Ele incorpora as Cláusulas Contratuais Padrão da Comissão Europeia (Módulo 2 para controlador-para-operador e Módulo 3 para operador-para-operador), o UK International Data Transfer Addendum e o equivalente FADP suíço. O compromisso de notificação de violação em 72 horas do GDPR Artigo 33, o procedimento de devolução-ou-exclusão e os direitos de auditoria (limitados a anual e SOC 2 Type II sob NDA quando esse for obtido) estão todos vinculados no modelo. A revisão por advogado externo está pendente antes que o DPA seja oferecido como clickwrap em planos pagos e como versão bilateralmente assinável no plano citadel.

14. Responsabilidades do Cliente

A segurança na Melaya é compartilhada. Os clientes são responsáveis por escolher senhas fortes e únicas, proteger suas credenciais de conta, definir o escopo das chaves API de exchange para as permissões mínimas necessárias, revisar e validar o comportamento dos pipelines que constroem, controlar o conteúdo que fazem upload em índices de recuperação, revisar os termos e as práticas de tratamento de dados de qualquer provedor de modelo de linguagem de terceiros pelo qual optem por rotear, e reportar prontamente qualquer suspeita de comprometimento. Recomendamos fortemente habilitar a autenticação de dois fatores nas configurações da conta na primeira vez que você fizer login; ela é exigida antes que qualquer credencial CEX possa ser adicionada ou que qualquer chave API da plataforma possa ser gerada, e é o controle de segurança de maior impacto que um cliente pode aplicar à sua própria conta.

15. Divulgação Responsável e Safe-Harbor

Safe-harbor. A Melaya Labs LLC não buscará ação legal contra, nem apoiará qualquer ação legal de terceiros contra, pesquisadores de segurança que ajam de boa-fé e cumpram esta política. Este compromisso se aplica a reivindicações que a Melaya poderia, de outra forma, apresentar sob o U.S. Computer Fraud and Abuse Act (CFAA), o U.K. Computer Misuse Act, as disposições equivalentes dos estatutos de uso indevido de computador dos Estados-Membros da UE, e quaisquer reivindicações de direito civil por quebra de contrato, interferência ilícita ou trespass to chattels. "Boa-fé" significa que o pesquisador fez um esforço genuíno para cumprir o escopo e as regras de engajamento abaixo, não acessou, modificou, destruiu ou exfiltrou dados pertencentes a outros usuários, não degradou intencionalmente os Serviços para outros usuários, e divulgou o achado privadamente para [email protected] antes de qualquer divulgação pública. Esta cláusula é vinculante para a Melaya e não requer aprovação por relatório. Ela não cobre conduta que seja independentemente ilegal sob a jurisdição do pesquisador, tais como fraude financeira real contra outros usuários, ou extorsão.

Scope. Testes estão autorizados contra melaya.org e todos os subdomínios na zona *.melaya.org, a superfície da aplicação em app.melaya.org, os endpoints da Builder API e as páginas jurídicas publicadas pela Melaya. Testes NÃO estão autorizados contra: (i) colocação, cancelamento ou modificação ao vivo de ordens em qualquer exchange de terceiros alcançada via Melaya; (ii) provedores de modelos de linguagem de terceiros (OpenAI, Anthropic, Google, Cohere, runtimes locais) alcançados via um pipeline configurado pelo usuário; (iii) a própria infraestrutura da Cloudflare, do provedor de hospedagem ou do provedor de cofre; (iv) qualquer forma de ataque de denial-of-service (flood L3/L4, flood L7, credential stuffing em volume); (v) engenharia social de funcionários, contratados ou clientes da Melaya; (vi) intrusão física.

Regras de engajamento. Os pesquisadores devem parar de testar no momento em que um achado for provado (uma única leitura não destrutiva é prova suficiente de acesso cross-cliente), nunca devem modificar ou exfiltrar dados de outros usuários, não devem instalar persistência e devem manter os testes automatizados abaixo de 1 requisição por segundo sustentada. O tráfego de teste deve carregar um header User-Agent: Melaya-research/<handle> distinto, para que a Melaya possa distingui-lo do tráfego real e não acione o on-call por causa dele.

SLA de triagem. A Melaya se compromete a reconhecer relatórios válidos dentro de cinco (5) dias úteis do recebimento, fornecer uma avaliação inicial de severidade dentro de dez (10) dias úteis do reconhecimento e remediar as descobertas conforme a escala de severidade: Crítica dentro de 48 horas, Alta dentro de 7 dias corridos, Média dentro de 30 dias corridos, Baixa dentro de 90 dias corridos. Caso a Melaya não cumpra um compromisso de SLA, o pesquisador pode fornecer sete (7) dias de aviso prévio por escrito da intenção de publicar, e a proteção de safe-harbor permanece em vigor durante a publicação, desde que o pesquisador tenha cumprido as regras de engajamento durante todo o processo.

Contato. Relatórios devem ser enviados a [email protected]. Uma chave PGP para relatórios criptografados será publicada em /.well-known/security.txt. Relatórios não devem ser enviados via redes sociais, issues do GitHub em repositórios públicos da Melaya, ou qualquer superfície de chat de suporte: esses canais não são monitorados para conteúdo sensível de segurança e criam risco de divulgação pública acidental antes da remediação.

Esta Seção 15 é autocontida e seus compromissos são vinculantes. O safe-harbor no primeiro parágrafo, o escopo e as regras de engajamento no segundo e terceiro parágrafos, o SLA de triagem no quarto parágrafo, E as regras de interação com os Termos de Serviço e de emenda apenas prospectiva no parágrafo imediatamente seguinte, juntos, constituem o conjunto completo de compromissos vinculantes para a Melaya com relação aos pesquisadores de segurança. Cada parágrafo desta Seção 15, não apenas os quatro primeiros, faz parte do conjunto de compromissos vinculantes. A Melaya mantém um runbook operacional interno para roteamento de triagem e escalada, mas esse runbook não adiciona, subtrai ou modifica qualquer dos compromissos desta Seção 15, e um pesquisador não precisa ler qualquer outro documento para confiar no safe-harbor acima. Qualquer alteração a esta Seção 15 se aplica apenas prospectivamente: um achado relatado de boa-fé sob a versão desta Seção 15 em vigor no momento do relatório permanece protegido pelo safe-harbor dessa versão, independentemente de qualquer emenda subsequente.

Interação com os Termos de Serviço (vinculante). Esta Seção 15 constitui a autorização expressa da Melaya para atividade de pesquisa de segurança que, de outra forma, seria restringida pelas proibições dos Termos de Serviço contra contornar, desabilitar ou interferir nas funcionalidades de segurança, limitação de taxa ou controle de acesso da Melaya. Um pesquisador atuando dentro do escopo e das regras de engajamento acima, portanto, não está em violação dos Termos por essa conduta, e a Melaya renuncia a qualquer reivindicação que, de outra forma, pudesse apresentar sob os Termos com relação a essa conduta específica. Este parágrafo é, em si, parte do conjunto de compromissos vinculantes acima e não é mero texto interpretativo.

Modelo de segurança do Device Control

O Device Control foi projetado como um canal autorizado pelo usuário e bloqueado por padrão. O aplicativo Android não pode habilitar sozinho a Acessibilidade nem a captura de tela; o usuário deve conceder essas permissões no sistema operacional. O Android pode exigir aprovação de configurações restritas para builds instaladas por sideload.

Telefones emparelhados se autenticam com um token de dispositivo revogável, cujo hash SHA-256 é armazenado no servidor. Atualmente, o token Android bruto é armazenado nas SharedPreferences privadas do aplicativo, e não em armazenamento criptografado com suporte de hardware; o aplicativo iOS armazena seu token no Keychain. Tokens de telefone são separados de sessões do navegador e tokens do runner, limitados a endpoints de telefone, expiram ou podem ser revogados e devem ser protegidos pela segurança do dispositivo do usuário.

Leituras da árvore de acessibilidade da tela e toques, digitação, gestos de deslizar e ações semelhantes restritas ao aplicativo em primeiro plano são verificados no servidor e no dispositivo Android em relação à lista de aplicativos aprovados pelo usuário. Ações de navegação global têm limites diferentes, e os frames de tela inteira do MediaProjection não são tecnicamente recortados nem condicionados ao aplicativo aprovado em primeiro plano; portanto, um aplicativo não aprovado ou sensível visível durante o espelhamento pode aparecer em um frame.

Frames de tela ao vivo são imagens de tela inteira reduzidas, encaminhadas como dados do frame mais recente para a sessão autenticada do proprietário e para ferramentas de captura de tela. Eles são mantidos brevemente na memória do processo do servidor para atualização e entrega, mas capturas selecionadas, resultados de ferramentas, solicitações de modelos, telemetria ou logs podem persistir ou chegar a um modelo em nuvem ou conector selecionado. Os usuários devem interromper o espelhamento antes de abrir conteúdo sensível não relacionado.

As filas de comandos do telefone e a política de aplicativos aprovados são atualmente definidas por conta de usuário, e não pelo dispositivo selecionado. Se vários telefones estiverem emparelhados, o primeiro telefone elegível a consultar a fila poderá assumir um comando enfileirado; após essa atribuição, o resultado será associado à tarefa e ao token daquele telefone. Execuções móveis nativas também registram uma execução ativa para que o controle de interrupção emergencial da sobreposição do mesmo usuário possa solicitar o encerramento dessa execução registrada; ele não pode encerrar pipelines de usuários arbitrários.

Controles de Mobile Agents e execução em dispositivos

A segurança de Mobile Agents separa decisão, autorização, roteamento e execução física. Um modelo ou agente pode propor um comando; os serviços da Melaya validam o usuário autenticado, o status de telefone emparelhado, a política da ação e o envelope do comando; o primeiro telefone elegível que consultar a fila pode assumir uma tarefa enfileirada por usuário; e o dispositivo registrado e controlado pelo usuário executa o comando sob as permissões do sistema operacional.

Credenciais de dispositivos são distintas de sessões do navegador, identidades de serviços em nuvem, credenciais de provedores e tokens de local runners. O servidor armazena um hash SHA-256 do token de telefone revogável. Atualmente, o Android armazena o token bruto em SharedPreferences privadas, enquanto o iOS o armazena no Keychain. Um token de telefone não autoriza a administração geral da conta, endpoints de telefone de outro usuário ou um runner não relacionado.

Comandos são bloqueados por padrão e definidos pelo usuário autenticado, pela tarefa assumida, pela política de aplicativos, pelo tipo de ação, pelos parâmetros e pelo tempo de vida da fila. Atualmente, a fila e a lista de permissões são definidas por usuário, não direcionadas de modo determinístico a um dispositivo selecionado quando vários telefones estão emparelhados; depois que um telefone assume uma tarefa, verificações de titularidade vinculam seu resultado. Endpoints sensíveis autenticam os chamadores, validam tamanhos e titularidade e rejeitam tarefas expiradas, mas os clientes devem emparelhar somente dispositivos confiáveis.

Ações de alto impacto ou ambíguas devem exigir nova confirmação humana, informações claras sobre o destino e as consequências e uma rota disponível de pausa ou interrupção emergencial. Indicadores persistentes, sobreposições, notificações de serviço em primeiro plano, visualizações, timeouts, limites de taxa, trilhas de auditoria e limpeza de estado terminal fornecem defesa em profundidade, mas não garantem que uma ação seja correta ou reversível.

Canais de comandos e telemetria usam transporte criptografado e identidades autenticadas. Dispatch assinado ou protegido por integridade, nonces, identificadores de comandos, expiração, vinculação ao dispositivo e detecção de repetição são usados onde implementados para reduzir adulteração e execução entre usuários. A criptografia de transporte não impede que um endpoint autorizado veja o texto simples necessário para executar a solicitação.

Local runners mantêm a execução de Python, os arquivos locais e a inferência de modelos locais no ambiente do usuário, sujeitos aos controles do sistema operacional do usuário. Execuções híbridas também expõem payloads de inferência ou ferramentas aos provedores em nuvem selecionados. Execuções em nuvem ocorrem em infraestrutura gerenciada pela Melaya e podem tratar dados do runtime e segredos selecionados. Sandboxing e isolamento reduzem, mas não eliminam, riscos de aplicativos, dependências, modelos, injeção de prompts ou infraestrutura.

Credenciais armazenadas usam criptografia ou controles de gestão de segredos e são entregues somente quando selecionadas para uma execução. O processo de execução e o provedor externo necessariamente recebem material de autenticação utilizável. Os usuários devem aplicar privilégio mínimo, separar credenciais de produção e teste, fazer rotação e revogação imediatas, restringir escopos de provedores e nunca inserir segredos em prompts, capturas de tela, logs ou saídas de ferramentas não confiáveis.

Serviços de telemetria e colaboração podem receber qualquer mensagem, trace, evento de ferramenta, resultado, custo, status, solicitação de aprovação, captura de tela ou payload de diagnóstico emitido por um runtime. Os clientes devem configurar adequadamente o nível de detalhes e a retenção dos eventos, evitar dados sensíveis desnecessários e aplicar controles de acesso a workspaces e projetos. “Local” descreve o lugar da execução, não garante ausência de transmissão de telemetria.

Acessibilidade do Android e MediaProjection são recursos sensíveis concedidos pelo usuário. Antes do acesso, o aplicativo móvel deve fornecer a divulgação destacada exigida e obter consentimento afirmativo, usar a API disponível de menor escopo, permanecer visível quando exigido, operar de forma reduzida quando a permissão for negada e jamais usar permissões para contornar a segurança da plataforma ou ocultar atividades. Uma build distribuída pelo Google Play não deve permitir que a Acessibilidade inicie, planeje e execute ações autonomamente em desacordo com a política do Google Play.

O aplicativo iOS da App Store é limitado pelo sandbox, pelos entitlements e pelas APIs públicas da Apple e não oferece controle irrestrito de aplicativos de terceiros. Rotas de teste com Mac runner, Developer Mode, XCTest, WebDriverAgent, dispositivo emparelhado e assinatura de desenvolvedor têm um modelo distinto de ameaças e confiança e exigem controle do Mac, da identidade de assinatura, do emparelhamento do dispositivo, do destino de teste e do canal de rede.

Nenhum controle elimina todos os riscos. Modelos podem ser manipulados por prompts ou conteúdo da tela; aplicativos podem mudar layouts; permissões podem ser excessivamente amplas; dependências podem ser comprometidas; dispositivos podem ser perdidos; e usuários autorizados podem usar os recursos indevidamente. Investigamos relatos plausíveis, podemos revogar ou isolar credenciais ou dispositivos afetados e recomendamos o uso imediato dos procedimentos de interrupção, revogação, rotação e comunicação de incidentes.

16. Alterações a Esta Visão Geral

A Melaya pode atualizar esta Visão Geral de Segurança periodicamente para refletir mudanças na plataforma, em nossos controles ou em nossos subprocessadores. A data "Última atualização" no topo deste documento reflete a revisão mais recente. Quando os itens operacionalmente pendentes (como o primeiro exercício de restauração, o primeiro exercício tabletop de RI, o primeiro pentest externo, a criptografia de disco no nível de volume ou a revisão por advogados externos do modelo de DPA) forem concluídos, a seção correspondente será reescrita para refletir o novo estado e a alteração será anunciada no changelog do produto.

17. Contato

Para questões de segurança, relatórios de vulnerabilidades ou para solicitar documentação de compliance, entre em contato: