Seguridad
Seguridad que puedes poner delante de un auditor.
Cómo construimos y operamos Moatgator para que tu revisión de seguridad pueda decir sí.
Compilaciones efímeras
Los artefactos de compilación son de corta vida y caducan a las 24 horas, y cada compilación se ejecuta en un worker aislado.
Tus claves de firma siguen siendo tuyas
La firma ocurre en tu pipeline. Moatgator nunca guarda tus claves de firma, certificados ni provisioning profiles.
Acceso de mínimo privilegio
La GitHub App solo pide los permisos que necesita, y la GitHub Action se autentica con OIDC en lugar de secretos de larga duración.
Alineado con OWASP MASVS
Los informes de Scan asocian cada hallazgo a los controles de MASVS que tus auditores ya conocen.
Telemetría que respeta a los usuarios
Pulse recoge señales de seguridad sobre dispositivos e intentos, no el contenido de tus usuarios, con muestreo, retención según el plan y elección de región.
Listo para la LGPD
Tratamos los datos personales conforme a la LGPD. El acuerdo de tratamiento de datos (DPA) y la lista de subencargados, con finalidad, datos y país, están publicados, al igual que nuestra política de divulgación de vulnerabilidades.
Desarrollo seguro
Nuestro propio pipeline ejecuta análisis estático, comprobación de dependencias y detección de secretos en cada cambio.
Acceso a nuestros sistemas
El acceso a producción exige MFA y inicio de sesión único con aprobación, y las acciones internas sensibles dejan un rastro de auditoría.
Controls we can point to
Every claim here is a control with evidence. What is not built yet is listed separately, with no date promised.
“Built” means implemented and tested in the product's source code. “Built” is not the same as audited, and the platform is in private beta. Evidence lives in private repositories and can be shown to customers on request.
This section is written in English.
Built and tested
Access and identity
Two-factor authentication (TOTP), optional or required per organization
Owners and admins can be required to use a one-time code. Codes cannot be reused and the secret is stored encrypted.
- Since
- Evidence
api/src/lib/totp.tsapi/src/auth-security.test.ts
Passwords stored with scrypt; session tokens stored only as hashes
Passwords use scrypt with a per-user salt. Session and one-time tokens are kept only as hashes, so a database read does not reveal a usable token.
- Since
- Evidence
api/src/auth/local.tsapi/src/auth-security.test.ts
API keys shown once, stored hashed, with scope, expiry and rotation
A key's secret is displayed only when it is created and stored as a keyed hash. Keys can be limited to one scope, expire, be rotated and be revoked immediately.
- Since
- Evidence
api/src/lib/apikey.tsapi/src/api-keys.test.ts
Data
Row-level isolation between customers, enforced in the database
Every table with customer data has row-level security forced on, and the application connects with a role that cannot bypass it. A generated test checks every such table.
- Since
- Evidence
api/migrations/0001_init.sqlapi/src/rls.test.ts
Tamper-evident audit log
Sensitive actions are appended to a hash-chained log that the database refuses to update or delete. Owners can verify the chain and export it.
- Since
- Evidence
api/src/lib/audit-chain.tsapi/migrations/0004_audit_chain.sql
Application-level encryption of stored secrets (AES-256-GCM)
Webhook secrets and two-factor secrets are encrypted before they reach the database. The key lives outside the database.
- Since
- Evidence
api/src/lib/field-crypto.ts
Telemetry without IP addresses and with rotating device identifiers
The raw device ID is never stored; the stored hash changes every 30 days and differs per app. IP addresses are stripped before ingestion and kept out of logs.
- Since
- Evidence
api/src/privacy/index.tsapi/docs/privacy/field-inventory.md
Retention limits by plan, data export and erasure on request
Events are deleted after the period of the plan. Customers can export their data and erase events by period or by device.
- Since
- Evidence
api/src/retention/index.tsapi/docs/pulse/retention.md
Platform
Origin checks on state-changing requests and rate limits on sensitive routes
Requests that change data from a browser session must come from an allowed origin. Login, sign-up, writes and ingestion are rate limited.
- Since
- Evidence
api/src/plugins/auth.tsapi/src/lib/ratelimit.ts
Outbound webhooks signed and protected against server-side request forgery
Webhook payloads carry an HMAC signature. Destinations in private, loopback and cloud-metadata ranges are refused, including after DNS resolution, and redirects are not followed.
- Since
- Evidence
api/src/lib/ssrf.tsapi/src/webhooks.test.ts
Programs and process
Vulnerability disclosure contact published (security.txt)
A security.txt file (RFC 9116) tells researchers where to report. The mailbox depends on the company domain, which is not registered yet.
- Since
- Evidence
landing/public/.well-known/security.txt
Documented process and deadlines for reported bypasses
A written process sets response deadlines by severity (7, 14, 30 and 90 days) and how a fix is published after the reporter agrees.
- Since
- Evidence
api/docs/security/bypass-response.md
Incident response runbooks and severity levels
Runbooks cover outages, stuck queues, leaked artifacts, compromised keys, public bypasses and abuse, with severity levels, roles and communication templates.
- Since
- Evidence
api/docs/ops/incident-response/README.md
On the roadmap
Ephemeral builds with artifacts that expire after 24 hours
Build workers will run isolated and artifacts will be deleted automatically. The build pipeline does not exist yet.
Target: Phase 1
Your app signing keys stay with you by default
Signing will happen in your own pipeline. This is a design goal for the build service, which does not exist yet.
Target: Phase 1
Encryption in transit and at rest in managed infrastructure
The platform is not deployed yet. TLS and encrypted storage will be enabled and verified at the first deployment.
Target: At first deployment
Managed key hierarchy with automatic rotation
A key-management library and infrastructure module exist, but no real key service is provisioned and the library is not wired into the platform yet.
Target: At first deployment
Independent penetration test
An external penetration test is planned. No report exists to publish today.
Target: Phase 3
Private bug bounty
A private bounty program is planned after the independent test.
Target: Phase 3
Single sign-on (SAML, OIDC) and SCIM provisioning
Planned for the Enterprise plan.
Target: Phase 3
SOC 2 Type I
Planned. The company holds no security certification today.
Target: 2028
Documentos
- Acuerdo de tratamiento de datos (DPA): publicado
- Lista de subencargados: pública, con finalidad, datos y país
- Respuestas al cuestionario de seguridad: bajo petición
- Informe de ejemplo asociado a MASVS: bajo petición
Preguntas sobre seguridad
¿Guardáis el código fuente de mi app?
No. La protección se ejecuta sobre la app compilada en tu pipeline, y los artefactos de compilación caducan a las 24 horas.
¿Quién guarda las claves de firma?
Tú. Moatgator devuelve un artefacto sin firmar y tu pipeline lo firma.
¿Qué datos personales tratáis?
Solo lo que envías mediante nuestros formularios y señales de seguridad sobre dispositivos e intentos a través de Pulse, nunca el contenido de tus usuarios.
¿Podéis responder a nuestro cuestionario de seguridad?
Sí. Contáctanos con tu cuestionario o con los requisitos de tu revisión.
¿La protección hace que una app sea imposible de atacar?
No. La protección aumenta el coste de los ataques y los hace visibles. Reduce el riesgo, pero no lo elimina.
¿Necesitas documentación de seguridad?
Cuéntanos qué exige tu revisión y te la enviamos.