Saltar al contenido

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

    Pendiente

    Comprueba también SSL Labs y Security Headers. No publicamos el detalle de hallazgos: solo la letra.

  • app.securitymbt.com

    Pendiente

    Comprueba 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:

DatoPlazo
Instantáneas de superficie90 días (30 en Free); siempre la primera y una semanal del histórico
Escaneos y cambiosLos días de historial del plan (ilimitado en Business)
Hallazgos resueltos365 días tras resolverse. Los abiertos no se borran
Incidentes de uptime365 días
Reportes / escaneos públicos30 días / 7 días
Auditoría, eventos de seguridad, facturasSin 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:

ProveedorPara quéEstado
Hosting VPS (Hetzner u equivalente UE)API, workers, base de datos, RedisPrevisto / en despliegue
Correo transaccionalVerificación, alertas, invitacionesPendiente de fijar proveedor en producción
StripeCobro de suscripcionesAún no activo (facturación en sprint posterior)
Proveedor de LLMApoyo opcional en análisis de códigoNo 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.