Divulgación Responsable

Política de reporte de vulnerabilidades · RFC 9116 · Ley 1273/2009 Colombia

Safe Harbor: Si encuentras una vulnerabilidad y la reportas de buena fe siguiendo este proceso, no emprenderemos acciones legales contra ti. Queremos trabajar contigo para proteger a los usuarios.

Cómo Reportar

Envía tu reporte a [email protected] con el asunto "[SECURITY] Vulnerabilidad reportada". Incluye:

Descripción detallada de la vulnerabilidad
Pasos para reproducirla (PoC si es posible)
Impacto potencial estimado
Tu nombre o alias (para créditos si lo deseas)

Responderemos en un plazo máximo de 5 días hábiles confirmando la recepción del reporte.

Alcance del Programa (In Scope)

vault.joneshys.com — aplicación web principal (frontend + backend API)
Extensión de Chrome — chrome-extension:// — lógica de la extensión
Endpoints de la API REST (/api/v1/*)
Flujos de autenticación, sesión y cifrado
Configuración de seguridad del servidor (TLS, headers, CORS)

Fuera de Alcance (Out of Scope)

Ataques de denegación de servicio (DoS/DDoS)
Ingeniería social contra el desarrollador
Vulnerabilidades en infraestructura de terceros (MongoDB Atlas, AWS, Cloudflare)
Issues de usabilidad o bugs no relacionados con seguridad
Escaneos automatizados masivos sin coordinación previa
Acceso a cuentas que no son de tu propiedad

Compromisos de Tiempo (SLA de Respuesta)

Confirmación de recepción — Acuse de recibo del reporte dentro de 5 días hábiles.

15d

Evaluación inicial — Confirmación de si es válido y clasificación de severidad (Critical / High / Medium / Low).

30d

Plan de remediación — Fecha estimada de parche para vulnerabilidades Critical y High.

90d

Divulgación coordinada — Publicación pública del CVE/advisory una vez parcheado, o a los 90 días del reporte si no ha sido corregido.

Safe Harbor y Marco Legal

Los investigadores que reporten vulnerabilidades de buena fe, siguiendo este proceso y sin acceder a datos de otros usuarios, están protegidos bajo la figura de safe harbor. No iniciaremos acciones legales bajo la Ley 1273 de 2009 (delitos informáticos, Colombia) contra investigadores que actúen conforme a esta política.

Esta protección aplica únicamente si: (1) no se accede a datos de usuarios reales; (2) no se interrumpe el servicio; (3) el reporte se hace de forma privada antes de cualquier divulgación pública.

Modelo de Seguridad — Qué protege y qué no protege Vault

Vault implementa un modelo de zero-knowledge en reposo con las siguientes propiedades actuales (v1.x):

✅ Zero-knowledge en disco — el servidor nunca almacena el master password ni la clave de descifrado (vault_key) en ningún archivo o base de datos.
✅ Cifrado AES-256-GCM — todas las credenciales están cifradas en reposo; el servidor solo almacena blobs cifrados.
✅ Keypair P-256 ECDH — la private key está cifrada dentro del vault; el servidor la almacena únicamente en forma cifrada.
⚠️ Server-assisted en sesión activa — durante el login, el servidor deriva la vault_key con argon2id en memoria y descifra el vault para retornar los datos al cliente. La clave existe en memoria de proceso durante la sesión (máx. 15 min de inactividad). Un atacante con acceso al proceso en ese instante podría extraerla.

Limitación conocida (ARCH-01): el modelo no es true zero-knowledge en sesión activa. Esta limitación está documentada en nuestro ADR-014 (apéndice ARCH-01) y la migración a descifrado completamente client-side está planificada en ADR-018 (v2.0, Q3 2026).

Si descubres una forma de explotar el acceso a memoria de sesión o cualquier otra vulnerabilidad fuera del modelo documentado, es exactamente el tipo de reporte que queremos recibir.

Reconocimientos

Agradecemos a todos los investigadores que contribuyen a la seguridad de Vault. Los reportes válidos serán reconocidos en esta sección con el nombre o alias que el investigador elija (o de forma anónima si lo prefiere).

— Hall of Fame disponible próximamente —

Política de Privacidad Términos de Servicio Aviso Legal security.txt