Saltar al contenido

Seguridad

Divulgación responsable

Si has encontrado un fallo de seguridad, escríbenos por el formulario de contacto. Respondemos en 48 horas. No emprenderemos acciones legales contra quien investigue de buena fe respetando las condiciones de esta página.

Puerto seguro

  • Probar contra cuentas propias
  • Reportar en cuanto se confirme el hallazgo
  • Dar un margen razonable antes de publicar
  • Preguntar si algo no queda claro

No

  • Acceder a datos de otros usuarios
  • Degradar o interrumpir el servicio
  • Extraer, conservar o divulgar datos ajenos
  • Ingeniería social contra personas

Sin recompensas monetarias. El servicio es gratuito y no genera ingresos con los que sostenerlas. Ofrecemos reconocimiento público, respuesta rápida y trato serio de cada reporte. Lo decimos de frente para no hacerte perder el tiempo.

Plazos que asumimos

Plazos de respuesta y corrección
HitoPlazoDetalle
Acuse de recibo48 horasSiempre, incluso si el reporte parece inválido
Evaluación inicial7 díasCon la clasificación de gravedad asignada
Corrección de vulnerabilidades críticas7 díasCon mitigación temporal si la definitiva tarda
Corrección de altas7 díasExplotables a distancia sin autenticación
Corrección de medias30 díasRequieren autenticación o condiciones poco frecuentes
Publicación completa90 díasAntes si ya hay explotación activa

Un criterio propio de este producto: cualquier fallo que permita alterar la fecha, la huella o el registro de transparencia de un certificado ya emitido es crítico de forma automática, aunque no haya explotación y aunque sea difícil de explotar. Es el único tipo de fallo que destruye retroactivamente el valor de todo lo emitido, y por eso no se pondera como los demás.

Notificación regulatoria

Conforme al Reglamento (UE) 2024/2847 sobre ciberresiliencia, las vulnerabilidades activamente explotadas se notifican al CSIRT designado y a ENISA en tres plazos: alerta en 24 horas, notificación en 72 horas e informe final en 14 días. El reloj arranca desde que tenemos conocimiento, no desde que confirmamos el alcance.

El procedimiento completo, con los ocho requisitos del Anexo I parte II, está en el documento de gestión de vulnerabilidades.

Postura de seguridad del sistema

Contenedores sin privilegios

Los cuatro servicios de aplicación y la base de datos corren como usuario sin privilegios, con todas las capacidades del kernel retiradas y no-new-privileges activo. El sistema de archivos raíz está en solo lectura: no se puede instalar nada en caliente.

Antivirus en fallo cerrado

Cada archivo se analiza antes de entrar en la canalización. Si el motor no responde, el archivo NO pasa. La alternativa —dejarlo pasar cuando el antivirus está caído— convierte una caída en una vía de entrada.

Sin contraseñas que robar

La autenticación es por enlace de un solo uso con caducidad. No almacenamos ninguna contraseña de usuario, así que no pueden filtrarse, reutilizarse ni adivinarse.

Registros de solo-anexado

El registro de auditoría, las hojas del árbol de transparencia y las pruebas de anclaje no tienen ruta de borrado ni de modificación en el código. No es una prohibición administrativa: es la ausencia deliberada de la operación.

Cuarentena de dependencias

Los guiones de instalación están desactivados por defecto y se autorizan uno a uno. Las versiones publicadas hace menos de 7 días quedan en cuarentena, porque contra un paquete comprometido un escáner llega tarde por construcción.

Limitación por visitante, no por IP

La topología de red hace que la dirección IP real del cliente no llegue a la aplicación. Por eso la limitación de tasa agrupa por identidad de visitante: cualquier defensa basada en IP sería aquí inútil o directamente peligrosa.

Más

Registrar y certificar mi obra
Rastreamos datos: registramos accesos (IP, user-agent), páginas vistas y eventos de uso para seguridad, analítica y cumplimiento. Consulta la Política de Privacidad.