Segurança
Segurança que você pode apresentar a um auditor.
Como construímos e operamos o Moatgator para que a sua revisão de segurança possa dizer sim.
Builds efêmeros
Os artefatos de build têm vida curta e expiram em 24 horas, e cada build roda em um worker isolado.
Suas chaves de assinatura continuam suas
A assinatura acontece no seu pipeline. O Moatgator nunca guarda suas chaves de assinatura, certificados nem provisioning profiles.
Acesso com privilégio mínimo
O GitHub App pede só as permissões de que precisa, e a GitHub Action se autentica com OIDC em vez de segredos de longa duração.
Alinhado ao OWASP MASVS
Os relatórios do Scan associam cada achado aos controles do MASVS que seus auditores já conhecem.
Telemetria que respeita os usuários
O Pulse coleta sinais de segurança sobre aparelhos e tentativas, não o conteúdo dos seus usuários, com amostragem, retenção por plano e escolha de região.
Pronto para a LGPD
Tratamos dados pessoais conforme a LGPD. O acordo de tratamento de dados (DPA) e a lista de suboperadores, com finalidade, dados e país, estão publicados, assim como a nossa política de divulgação de vulnerabilidades.
Desenvolvimento seguro
Nosso próprio pipeline roda análise estática, verificação de dependências e varredura de segredos a cada mudança.
Acesso aos nossos sistemas
O acesso à produção exige MFA e login único com aprovação, e ações internas sensíveis deixam trilha de auditoria.
Controles que podemos apontar
Cada afirmação aqui é um controle com evidência. O que ainda não foi construído aparece separado, sem data prometida.
“Construído” quer dizer implementado e testado no código-fonte do produto. “Construído” não é o mesmo que auditado, e a plataforma está em beta privado. As evidências ficam em repositórios privados e podem ser mostradas a clientes sob pedido.
Construído e testado
Acesso e identidade
Autenticação em dois fatores (TOTP), opcional ou obrigatória por organização
Donos e admins podem ser obrigados a usar um código de uso único. Um código não pode ser reutilizado e o segredo é guardado cifrado.
- Desde
- Evidência
api/src/lib/totp.tsapi/src/auth-security.test.ts
Senhas guardadas com scrypt; tokens de sessão guardados só como hash
As senhas usam scrypt com sal por usuário. Tokens de sessão e de uso único ficam só como hash: ler o banco não revela um token utilizável.
- Desde
- Evidência
api/src/auth/local.tsapi/src/auth-security.test.ts
Chaves de API mostradas uma vez, guardadas em hash, com escopo, validade e rotação
O segredo de uma chave só aparece quando ela é criada e é guardado como hash com segredo. As chaves podem ter escopo, validade, rotação e revogação imediata.
- Desde
- Evidência
api/src/lib/apikey.tsapi/src/api-keys.test.ts
Dados
Isolamento entre clientes por linha, imposto no banco de dados
Toda tabela com dados de cliente tem segurança por linha forçada, e a aplicação conecta com um papel que não consegue contorná-la. Um teste gerado confere cada uma dessas tabelas.
- Desde
- Evidência
api/migrations/0001_init.sqlapi/src/rls.test.ts
Trilha de auditoria à prova de adulteração
Ações sensíveis entram num log encadeado por hash que o banco recusa alterar ou apagar. Donos podem verificar a cadeia e exportá-la.
- Desde
- Evidência
api/src/lib/audit-chain.tsapi/migrations/0004_audit_chain.sql
Criptografia no nível da aplicação para segredos guardados (AES-256-GCM)
Segredos de webhooks e de dois fatores são cifrados antes de chegar ao banco. A chave fica fora do banco.
- Desde
- Evidência
api/src/lib/field-crypto.ts
Telemetria sem endereço IP e com identificador de aparelho que gira
O ID bruto do aparelho nunca é guardado; o hash guardado muda a cada 30 dias e é diferente em cada app. Endereços IP são removidos antes da ingestão e ficam fora dos logs.
- Desde
- Evidência
api/src/privacy/index.tsapi/docs/privacy/field-inventory.md
Prazos de retenção por plano, exportação e eliminação de dados sob solicitação
Os eventos são apagados depois do prazo do plano. Clientes podem exportar seus dados e apagar eventos por período ou por aparelho.
- Desde
- Evidência
api/src/retention/index.tsapi/docs/pulse/retention.md
Plataforma
Verificação de origem nas requisições que alteram dados e limites de taxa nas rotas sensíveis
Requisições que alteram dados numa sessão de navegador precisam vir de uma origem permitida. Login, cadastro, escritas e ingestão têm limite de taxa.
- Desde
- Evidência
api/src/plugins/auth.tsapi/src/lib/ratelimit.ts
Webhooks de saída assinados e protegidos contra requisição forjada no servidor (SSRF)
Os webhooks levam assinatura HMAC. Destinos em faixas privadas, de loopback e de metadados de nuvem são recusados, inclusive depois da resolução de DNS, e redirecionamentos não são seguidos.
- Desde
- Evidência
api/src/lib/ssrf.tsapi/src/webhooks.test.ts
Programas e processos
Contato para divulgação de vulnerabilidades publicado (security.txt)
Um arquivo security.txt (RFC 9116) diz aos pesquisadores onde reportar. A caixa de e-mail depende do domínio da empresa, que ainda não foi registrado.
- Desde
- Evidência
landing/public/.well-known/security.txt
Processo e prazos documentados para bypasses reportados
Um processo escrito define prazos por severidade (7, 14, 30 e 90 dias) e como a correção é publicada depois da concordância de quem reportou.
- Desde
- Evidência
api/docs/security/bypass-response.md
Runbooks de resposta a incidentes e níveis de severidade
Os runbooks cobrem queda, fila travada, vazamento de artefato, chave comprometida, bypass público e abuso, com níveis de severidade, papéis e modelos de comunicação.
- Desde
- Evidência
api/docs/ops/incident-response/README.md
No roteiro
Builds efêmeros com artefatos que expiram em 24 horas
Os workers de build rodarão isolados e os artefatos serão apagados automaticamente. O pipeline de build ainda não existe.
Previsto: Phase 1
As chaves de assinatura do seu app ficam com você, por padrão
A assinatura acontecerá no seu próprio pipeline. É uma meta de desenho do serviço de build, que ainda não existe.
Previsto: Phase 1
Criptografia em trânsito e em repouso na infraestrutura gerenciada
A plataforma ainda não está no ar. TLS e armazenamento cifrado serão ligados e verificados na primeira implantação.
Previsto: At first deployment
Hierarquia de chaves gerenciada com rotação automática
Existem uma biblioteca de gestão de chaves e um módulo de infraestrutura, mas nenhum serviço de chaves real foi criado e a biblioteca ainda não está ligada à plataforma.
Previsto: At first deployment
Teste de invasão independente
Um teste de invasão externo está planejado. Hoje não existe relatório para publicar.
Previsto: Phase 3
Programa privado de recompensa por vulnerabilidades
Um programa privado de recompensas está planejado para depois do teste independente.
Previsto: Phase 3
Login único (SAML, OIDC) e provisionamento SCIM
Planejado para o plano Enterprise.
Previsto: Phase 3
SOC 2 Tipo I
Planejado. Hoje a empresa não tem nenhuma certificação de segurança.
Previsto: 2028
Documentos
- Acordo de tratamento de dados (DPA): publicado
- Lista de suboperadores: pública, com finalidade, dados e país
- Respostas ao questionário de segurança: sob solicitação
- Relatório de exemplo mapeado ao MASVS: sob solicitação
Dúvidas sobre segurança
Vocês guardam o código-fonte do meu app?
Não. A proteção roda sobre o app compilado no seu pipeline, e os artefatos de build expiram em 24 horas.
Quem guarda as chaves de assinatura?
Você. O Moatgator devolve um artefato não assinado e o seu pipeline o assina.
Quais dados pessoais vocês tratam?
Só o que você envia pelos nossos formulários e sinais de segurança sobre aparelhos e tentativas pelo Pulse, nunca o conteúdo dos seus usuários.
Vocês respondem ao nosso questionário de segurança?
Sim. Fale conosco com o seu questionário ou os requisitos da sua revisão.
A proteção torna um app impossível de atacar?
Não. A proteção aumenta o custo dos ataques e os torna visíveis. Ela reduz o risco, mas não o elimina.
Precisa de documentação de segurança?
Conte o que a sua revisão exige e nós enviamos.