Política de divulgación coordinada de vulnerabilidades
Clasificación del documento: público
1. Objeto
Catalogic Software («Catalogic», «nosotros», «nuestro») valora la contribución de los investigadores de seguridad independientes y de otras personas que nos ayudan a encontrar y corregir vulnerabilidades de seguridad en nuestros productos. Esta política explica cómo comunicar una posible vulnerabilidad en Catalogic DPX o en Catalogic CloudCasa, qué puede esperar de nosotros y en qué condiciones autorizamos la investigación de seguridad de buena fe.
Esta política refleja también la obligación de Catalogic, como fabricante de «productos con elementos digitales» con arreglo al Reglamento de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847, el «CRA»), de mantener y aplicar un proceso de divulgación coordinada de vulnerabilidades (CRA, anexo I, parte II, punto 5) y de publicar un punto de contacto único para las comunicaciones de vulnerabilidades (CRA, anexo II, punto 2).
2. Ámbito
2.1. Incluido en el ámbito
- Catalogic DPX y vStor: todas las versiones que cuentan actualmente con soporte (consulte el ciclo de vida del soporte de DPX y el calendario de fin de soporte).
- Catalogic CloudCasa: la plataforma SaaS de CloudCasa y todos los componentes autoalojados y conectores que cuentan actualmente con soporte.
- Vulnerabilidades en el código y la configuración desarrollados por Catalogic y en la infraestructura operada por Catalogic que da soporte directo a estos productos.
2.2. Excluido del ámbito
- Denegación de servicio, spam, ingeniería social o ataques físicos contra el personal, las oficinas o los centros de datos de Catalogic.
- Análisis automatizados de vulnerabilidades que generen una carga significativa en los servicios alojados por Catalogic sin coordinación previa.
- Servicios, dependencias o infraestructura de terceros que Catalogic no controla (en la sección 8 se indica cómo comunicarlos).
- Productos que han llegado al fin del soporte, salvo que el aviso de fin de soporte aplicable indique otra cosa.
3. Términos clave
- Vulnerabilidad: una debilidad, susceptibilidad o defecto de un producto con elementos digitales que puede ser aprovechado por una ciberamenaza.
- Vulnerabilidad aprovechada activamente: una vulnerabilidad respecto de la cual existen pruebas fiables de que un agente malintencionado la ha aprovechado en un sistema sin autorización del propietario del sistema (CRA, artículo 3, punto 42). Es el desencadenante jurídico de las propias obligaciones de notificación de Catalogic conforme al artículo 14 del CRA (véase la sección 7).
- Divulgación coordinada de vulnerabilidades (CVD): un proceso en el que quien la descubre comunica la vulnerabilidad de forma privada al fabricante, y se deja tiempo para su evaluación y corrección antes de cualquier divulgación pública.
- Investigación de seguridad de buena fe: el acceso a un producto únicamente para probar, investigar o corregir un problema de seguridad, de una manera que evite causar daños y con una comunicación inmediata a Catalogic.
4. Cómo comunicar una vulnerabilidad
Comunique las posibles vulnerabilidades a nuestro punto de contacto único:
- Correo electrónico: security@catalogicsoftware.com
- Este contacto también se publica en formato legible por máquina en https://www.catalogicsoftware.com/.well-known/security.txt y en https://cloudcasa.io/.well-known/security.txt.
Si cree que una vulnerabilidad se está aprovechando activamente o supone un riesgo inmediato para los datos de los clientes, indíquelo de forma explícita en el asunto (por ejemplo, «ACTIVE EXPLOITATION») para que pueda clasificarse de inmediato (véase la sección 7).
5. Qué debe incluir su comunicación
- El producto y la versión o versiones afectadas (por ejemplo, DPX x.x, componente o fecha de CloudCasa).
- Una descripción de la vulnerabilidad y de su posible impacto.
- Instrucciones paso a paso para reproducirla, código de prueba de concepto o una captura de la petición y la respuesta, siempre que sea posible.
- Si cree que la vulnerabilidad ya se está aprovechando en entornos reales y las pruebas que lo respaldan.
- Su medio de contacto preferido y, si desea que se le reconozca públicamente, el nombre o alias que debemos usar.
No incluya datos reales de clientes, credenciales ni otra información sensible en su comunicación. Describa el acceso obtenido en lugar de extraer datos.
6. Nuestro compromiso
Una vez que recibamos una comunicación válida por el canal indicado, nos comprometemos a:
- Acusar recibo y asignar una referencia de seguimiento.
- Investigar y validar la comunicación, y mantenerle informado de los avances relevantes.
- Trabajar para corregir las vulnerabilidades confirmadas en los plazos que se indican a continuación, con prioridad según la gravedad.
- No emprender acciones legales contra los investigadores que cumplan esta política (véase la sección 9).
- Reconocer a quienes lo deseen cuando haya una corrección disponible (por el momento no existe un programa de recompensas económicas).
| Gravedad de la comunicación (puntuación base CVSS v3.1/4.0) | Plazo objetivo de acuse de recibo | Plazo objetivo de evaluación inicial y clasificación | Plazo objetivo de corrección o mitigación coordinada |
|---|---|---|---|
| Crítica (9,0–10,0) | 1 día hábil | 3 días hábiles | Lo antes razonablemente posible; sin límite fijo, pero con prioridad sobre el resto del trabajo de ingeniería |
| Alta (7,0–8,9) | 2 días hábiles | 5 días hábiles | Conforme al SLA interno de parches para gravedad alta |
| Media (4,0–6,9) | 3 días hábiles | 10 días hábiles | Conforme al SLA interno de parches para gravedad media |
| Baja (0,1–3,9) | 5 días hábiles | 15 días hábiles | Se aborda en una versión periódica de mantenimiento o en una versión menor |
Los plazos de respuesta anteriores son objetivos internos de servicio propuestos, en línea con las prácticas habituales del sector (por ejemplo, los principios de ISO/IEC 29147 y 30111). El CRA no los exige, porque no fija un SLA numérico de respuesta para los programas de CVD.
7. Calendario de divulgación coordinada y explotación activa
Pedimos a quienes comuniquen una vulnerabilidad que no la divulguen públicamente hasta que haya una corrección o una mitigación disponible, o hasta que hayan pasado 90 días naturales desde que se confirmó la validez de la comunicación, lo que ocurra antes, salvo que acordemos conjuntamente otro calendario.
Si, en cualquier momento, Catalogic determina que una vulnerabilidad comunicada cumple la definición de «vulnerabilidad aprovechada activamente» del CRA (artículo 3, punto 42), o si se produce un incidente grave que afecte a la seguridad de DPX o de CloudCasa, Catalogic está obligada por ley a notificarlo al CSIRT designado como coordinador y a la ENISA con arreglo al artículo 14 del CRA, mediante una alerta temprana en un plazo de 24 horas desde que tenga conocimiento, una notificación en un plazo de 72 horas y un informe final posterior. Esta obligación normativa se desarrolla en paralelo a nuestra coordinación con quien comunicó la vulnerabilidad, y no la sustituye.
8. Componentes de terceros y de código abierto
Cuando una vulnerabilidad comunicada se origina en un componente de terceros o de código abierto utilizado en DPX, vStor o CloudCasa, nos coordinaremos, cuando sea factible, con el responsable o custodio del componente original e incorporaremos su calendario de divulgación al nuestro, de conformidad con el anexo I, parte II, punto 6, del CRA.
9. Puerto seguro
Catalogic no emprenderá acciones legales ni dará traslado a las fuerzas de seguridad contra un investigador que: (a) haga un esfuerzo de buena fe por cumplir esta política; (b) evite vulnerar la privacidad, destruir datos o interrumpir o degradar nuestros servicios; (c) no acceda a datos, los modifique ni los extraiga más allá de lo estrictamente necesario para demostrar la vulnerabilidad; y (d) comunique el hallazgo de inmediato y no lo aproveche más allá de lo necesario para su verificación.
10. Avisos públicos
Cuando haya una corrección disponible, Catalogic publicará información sobre la vulnerabilidad, los productos y versiones afectados, la gravedad y las instrucciones de corrección, de conformidad con el anexo I, parte II, punto 4, del CRA. Los avisos se publican en catalogicsoftware.com y en cloudcasa.io.
11. Gobernanza de la política
- Responsable: equipo de seguridad
- Periodicidad de revisión: al menos una vez al año, y ante cambios normativos relevantes (por ejemplo, nuevas orientaciones de la Comisión o de la ENISA sobre el CRA) o cambios en el alcance de los productos.
- Esta política se aplica conjuntamente a DPX y a CloudCasa. Las páginas de avisos específicas de cada producto pueden complementarla.