Sécurité
Une sécurité que vous pouvez présenter à un auditeur.
Comment nous construisons et exploitons Moatgator pour que votre revue de sécurité puisse dire oui.
Builds éphémères
Les artefacts de build ont une durée de vie courte et expirent au bout de 24 heures, et chaque build s'exécute dans un worker isolé.
Vos clés de signature restent à vous
La signature a lieu dans votre pipeline. Moatgator ne détient jamais vos clés de signature, vos certificats ni vos provisioning profiles.
Accès à moindre privilège
La GitHub App ne demande que les permissions dont elle a besoin, et la GitHub Action s'authentifie avec OIDC plutôt qu'avec des secrets de longue durée.
Aligné sur l'OWASP MASVS
Les rapports Scan rattachent chaque constat aux contrôles MASVS que vos auditeurs connaissent déjà.
Une télémétrie qui respecte les utilisateurs
Pulse collecte des signaux de sécurité sur les appareils et les tentatives, pas le contenu de vos utilisateurs, avec échantillonnage, rétention selon le plan et choix de la région.
Prêt pour la LGPD
Nous traitons les données personnelles conformément à la LGPD. L'accord de traitement des données (DPA) et la liste des sous-traitants, avec finalité, données et pays, sont publiés, tout comme notre politique de divulgation des vulnérabilités.
Développement sécurisé
Notre propre pipeline exécute l'analyse statique, le contrôle des dépendances et la détection de secrets à chaque changement.
Accès à nos systèmes
L'accès à la production exige le MFA et une authentification unique avec approbation, et les actions internes sensibles laissent une trace d'audit.
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
Documents
- Accord de traitement des données (DPA) : publié
- Liste des sous-traitants : publique, avec finalité, données et pays
- Réponses au questionnaire de sécurité : sur demande
- Exemple de rapport rattaché au MASVS : sur demande
Questions de sécurité
Stockez-vous le code source de mon app ?
Non. La protection s'exécute sur l'app compilée dans votre pipeline, et les artefacts de build expirent au bout de 24 heures.
Qui détient les clés de signature ?
Vous. Moatgator renvoie un artefact non signé et votre pipeline le signe.
Quelles données personnelles traitez-vous ?
Seulement ce que vous envoyez par nos formulaires, et des signaux de sécurité sur les appareils et les tentatives via Pulse, jamais le contenu de vos utilisateurs.
Pouvez-vous répondre à notre questionnaire de sécurité ?
Oui. Contactez-nous avec votre questionnaire ou les exigences de votre revue.
La protection rend-elle une app impossible à attaquer ?
Non. La protection augmente le coût des attaques et les rend visibles. Elle réduit le risque ; elle ne l'élimine pas.
Besoin d'une documentation de sécurité ?
Dites-nous ce qu'exige votre revue et nous vous l'enverrons.