Página de confianza · sin cuenta
Seguridad de securitymbt
Cuando alguien te pregunta si es seguro darnos un dominio, esta página es la respuesta. Está escrita para ser honesta: lo que ya hacemos, lo que diseñamos para hacer, y lo que todavía no tenemos (por ejemplo, SOC 2).
Nuestra propia calificación
No es una promesa de que el producto funciona: es el resultado de escanear nuestros propios dominios con el mismo motor que usas tú. Si la configuración se degrada, este número baja y el CI semanal falla.
Todavía no hay un auto-escaneo publicado. Cuando el workflow semanal corra contra producción, la letra A–F aparecerá aquí.
api.securitymbt.com
PendienteComprueba también SSL Labs y Security Headers. No publicamos el detalle de hallazgos: solo la letra.
app.securitymbt.com
PendienteComprueba también SSL Labs y Security Headers. No publicamos el detalle de hallazgos: solo la letra.
Cómo se calcula la letra: metodología del score.
Cifrado
- En tránsito: HTTPS/TLS entre tu navegador y nuestros servicios. La API no acepta tráfico claro en producción.
- En reposo: la base de datos y los discos del entorno de producción se cifran en el proveedor (volúmenes cifrados). Los backups se diseñan cifrados; la restauración se prueba, no solo se asume.
- Contraseñas: solo hashes argon2id. Nunca bcrypt, nunca texto plano.
- Secretos de MFA (TOTP): cifrados con AES-256-GCM antes de guardarse. Un volcado de base de datos no deja los secretos TOTP usables.
Dónde está alojado
El diseño de producción apunta a VPS en la Unión Europea (proveedor previsto: Hetzner), con PostgreSQL y Redis en la misma región. El frontend puede servirse desde el mismo VPS o un origen estático; en cualquier caso, los datos de negocio viven en la región europea elegida.
El entorno de desarrollo local (Docker en el portátil del equipo) no es el entorno de clientes. Cuando haya un despliegue estable, publicaremos la región exacta y el rango de IPs de origen del escáner para allowlists.
Qué guardamos y qué no
Guardamos
- Cuentas, organizaciones y membresías
- Activos (dominios, etiquetas, estado de verificación)
- Hallazgos, evidencia técnica y scores
- Historial de escaneos y auditoría de acciones sensibles
- Notas internas de la agencia sobre sus clientes
No guardamos
- Código fuente de repositorios (el plano de código aún no está en producción)
- Contraseñas en claro
- Volcados completos de sitios ajenos “por si acaso”
- Datos de pago de tarjetas: eso lo procesa el proveedor de cobro cuando exista facturación
Los plazos concretos —cuánto guardamos cada tipo de dato, qué no se borra nunca y cómo exportar o borrar una organización— están en la política de retención y resumidos más abajo.
Los escaneos activos (puertos, sondas) solo se ejecutan sobre activos con verificación de propiedad vigente. Escribir un dominio en un formulario no basta: hay que demostrar control (DNS TXT, archivo well-known o meta tag).
Retención de datos
No conservamos el historial operativo de forma indefinida. Un cliente que pregunta cuánto guardamos sus datos merece una respuesta concreta:
| Dato | Plazo |
|---|---|
| Instantáneas de superficie | 90 días (30 en Free); siempre la primera y una semanal del histórico |
| Escaneos y cambios | Los días de historial del plan (ilimitado en Business) |
| Hallazgos resueltos | 365 días tras resolverse. Los abiertos no se borran |
| Incidentes de uptime | 365 días |
| Reportes / escaneos públicos | 30 días / 7 días |
| Auditoría, eventos de seguridad, facturas | Sin límite. No se borran nunca |
Puedes exportar todo en ZIP y pedir el borrado de la organización (7 días de gracia) desde Ajustes → Datos. El detalle, incluidos los avisos a 60 y 80 días tras cancelar un plan, está en docs/data-retention.md.
Aislamiento entre organizaciones
Cada organización es un tenant. El acceso a datos de negocio pasa por un contexto de tenant obligatorio y por Row-Level Security (RLS) en PostgreSQL: aunque la aplicación falle, la base de datos rechaza filas de otra organización.
Hay una batería de tests de aislamiento en CI que intenta leer datos ajenos a propósito. Si alguno pasa, el cambio no entra. En un producto de seguridad, una fuga entre clientes no es un bug menor: es el final del producto.
Divulgación de vulnerabilidades
Si encuentras un problema de seguridad en securitymbt, escríbenos a security@securitymbt.com. Preferimos reportes privados y coordinados. No ofrecemos hoy un programa de recompensas público; sí respondemos y priorizamos fallos que afecten a datos de clientes o al aislamiento entre organizaciones.
También publicamos /.well-known/security.txt (RFC 9116) para que un técnico sepa en segundos a quién escribir.
Subprocesadores
Lista actual, con el nivel de honestidad que toca en esta fase:
| Proveedor | Para qué | Estado |
|---|---|---|
| Hosting VPS (Hetzner u equivalente UE) | API, workers, base de datos, Redis | Previsto / en despliegue |
| Correo transaccional | Verificación, alertas, invitaciones | Pendiente de fijar proveedor en producción |
| Stripe | Cobro de suscripciones | Aún no activo (facturación en sprint posterior) |
| Proveedor de LLM | Apoyo opcional en análisis de código | No usado en el plano externo actual |
Cuando un subprocesador pase a producción, esta tabla se actualizará antes o a la vez que el cambio. Si un cliente exige “sin IA”, el plano de código tendrá un modo que no envíe fragmentos a un LLM de terceros.
Certificaciones
No tenemos SOC 2 ni ISO 27001 hoy. SOC 2 Type II suele llevar meses y un coste relevante; no es un entregable de esta fase. Lo que sí hacemos desde ya es diseñar como si se fuera a auditar: auditoría de acciones, control de acceso por rol, RLS, secretos fuera del código y tests de aislamiento en CI.
Preferimos decir “aún no” a inventar un sello. Si eres un prospecto que necesita SOC 2 para comprar, dínoslo: es exactamente la señal que prioriza ese trabajo.
Cómo calculamos el score
La calificación A–F es pública y versionada. Leer la metodología.