# Gestión de vulnerabilidades y divulgación coordinada **Marco:** Reglamento (UE) 2024/2847 sobre ciberresiliencia (CRA), Anexo I parte II y artículos 13 y 14 · RFC 9116 (`security.txt`) · ISO/IEC 29147 y 30111 **Organización:** Veritas Digital LLC · Versión 1.0 · 5 de agosto de 2026 --- ## 1 · Por qué esto tiene fecha límite El Reglamento de Ciberresiliencia se aprobó el 23 de octubre de 2024 y su aplicación es escalonada: | Fecha | Qué entra en vigor | |---|---| | 11 de diciembre de 2024 | Entrada en vigor del Reglamento | | **11 de septiembre de 2026** | **Obligaciones de notificación del artículo 14** | | 11 de diciembre de 2027 | Aplicación plena | **Quedan 37 días para la fecha del artículo 14.** Veritas UGC y la aplicación Android asociada son productos con elementos digitales puestos a disposición en el mercado de la Unión, así que la obligación aplica con independencia del tamaño de la organización o de que el servicio sea gratuito. --- ## 2 · Plazos de notificación — el núcleo del artículo 14 Aplican a **vulnerabilidades activamente explotadas** y a **incidentes graves** que afecten a la seguridad del producto. | Plazo | Qué hay que hacer | Destinatario | |---|---|---| | **24 horas** | Alerta temprana | CSIRT designado y ENISA | | **72 horas** | Notificación de la vulnerabilidad o incidente, con evaluación inicial y medidas correctoras | CSIRT designado y ENISA | | **14 días** *(vulnerabilidad explotada)* | Informe final: descripción, gravedad, impacto y solución | CSIRT designado y ENISA | | **1 mes** *(incidente grave)* | Informe final del incidente | CSIRT designado y ENISA | | **Sin demora indebida** | Informar a los usuarios afectados y, cuando proceda, sobre medidas correctoras | Usuarios | **El reloj arranca desde que la organización tiene conocimiento**, no desde que confirma el alcance. Esta distinción es la que hace que el procedimiento tenga que estar escrito de antemano: a las 24 horas rara vez se sabe lo suficiente, y aun así hay que alertar. --- ## 3 · Procedimiento interno ### Fase 0 · Recepción | Canal | Vía | |---|---| | Divulgación responsable | `/.well-known/security.txt` | | Aviso automatizado | `osv-scanner` en cada compilación | | Vigilancia | Avisos de seguridad de Node, Docker, PostgreSQL y las dependencias directas | **Acuse de recibo en 48 horas**, siempre, incluso si el informe parece inválido. ### Fase 1 · Triaje (dentro de las primeras 24 horas) Dos preguntas, en este orden, porque de la segunda depende que arranque el reloj regulatorio: 1. **¿Es real y afecta a un producto en alcance?** 2. **¿Hay indicios de explotación activa?** | Gravedad | Criterio | Acción | |---|---|---| | **Crítica** | Explotación activa, o compromiso de integridad probatoria, o exposición de material de usuarios | Alerta a las 24 h. Corrección inmediata. Notificación a usuarios | | **Alta** | Explotable a distancia sin autenticación, sin indicios de explotación | Corrección en 7 días | | **Media** | Requiere autenticación o condiciones poco frecuentes | Corrección en 30 días | | **Baja** | Impacto limitado, o mitigada por defensa en profundidad | Siguiente ciclo de mantenimiento | > **Un criterio propio de este producto.** Cualquier defecto que permita **alterar la fecha, la > huella o el registro de transparencia de un certificado ya emitido es automáticamente crítico**, > aunque no haya explotación y aunque la explotación sea difícil. 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. ### Fase 2 · Corrección | Paso | Compromiso | |---|---| | Contención | Mitigación temporal si la corrección definitiva tarda | | Corrección | Con prueba de regresión que demuestre que el fallo ya no se reproduce | | Despliegue | Verificado, y con reversión ensayada | | Registro | Entrada en `audit_logs` y en el registro de incidentes | ### Fase 3 · Divulgación | Momento | Contenido | |---|---| | Al desplegar la corrección | Aviso público en la página de estado | | A los 30 días | Detalle técnico completo, salvo que el riesgo residual aconseje esperar | | Siempre | Crédito a quien lo reportó, si lo desea | **Ventana estándar de 90 días** desde el reporte hasta la publicación completa, adelantada si ya hay explotación activa. ### Fase 4 · Aprendizaje Cada incidente resuelto genera una entrada en el registro de lecciones, con la causa raíz y el control que se añade para que no vuelva. **Cuatro entradas reales** a fecha de hoy, la más instructiva de las cuales fue una copia de seguridad que informaba de éxito mientras empaquetaba carpetas vacías. --- ## 4 · Requisitos del Anexo I parte II del CRA | # | Requisito | Estado | |---|---|---| | 1 | Identificar y documentar los componentes, con SBOM | **Implementado** — SBOM en formato CycloneDX, generado en cada compilación | | 2 | Corregir sin demora las vulnerabilidades | **Implementado** — plazos de la sección 3 | | 3 | Aplicar pruebas y revisiones periódicas | **Implementado** — `osv-scanner` en cada compilación y revisión adversarial | | 4 | Publicar información sobre vulnerabilidades corregidas | **Implementado** — página de estado | | 5 | Política de divulgación coordinada | **Implementado** — este documento y `security.txt` | | 6 | Facilitar el reporte de vulnerabilidades | **Implementado** — canal público sin requisitos previos | | 7 | Distribuir actualizaciones de seguridad sin demora | **Implementado** — despliegue continuo | | 8 | Actualizaciones **gratuitas** y con aviso | **Implementado** — el servicio entero es gratuito | --- ## 5 · Compromiso con quien investiga **Puerto seguro.** Veritas Digital LLC **no emprenderá acciones legales** contra quien investigue la seguridad del servicio de buena fe y respetando estas condiciones: | Sí | No | |---|---| | Probar contra cuentas propias | Acceder a datos de otros usuarios | | Reportar en cuanto se confirme el hallazgo | Degradar o interrumpir el servicio | | Dar margen razonable antes de publicar | Extraer, conservar o divulgar datos ajenos | | Preguntar si algo no está claro | Ingeniería social contra personas | **Sin programa de recompensas monetarias.** El servicio es gratuito y no genera ingresos con los que sostenerlas. Se ofrece a cambio reconocimiento público, respuesta rápida y trato serio de cada reporte. Se dice de frente para no hacer perder el tiempo a nadie. --- ## 6 · Inventario de componentes El SBOM se publica en formato **CycloneDX**, se regenera en cada compilación y cubre: | Ámbito | Contenido | |---|---| | Tiempo de ejecución | Node 20 LTS, PostgreSQL 16, Redis, ClamAV, Alpine | | Aplicación | Dependencias de producción con versión y licencia | | Contenedores | Imagen base y capas, con su huella | **Excluido**: las dependencias solo de desarrollo, que no llegan al artefacto desplegado. Se declara la exclusión para que nadie interprete el SBOM como más completo de lo que es. --- ## 7 · Prevención en la cadena de suministro El riesgo dominante en 2025 y 2026 no son las vulnerabilidades catalogadas sino los paquetes legítimos comprometidos que se propagan en horas. Un escáner llega tarde por construcción: cuando la versión maliciosa entra en el árbol de dependencias, todavía no está en ninguna base de datos. | Capa | Medida | Qué neutraliza | |---|---|---| | 1 | `ignore-scripts` en la instalación | Los guiones de instalación, vía de propagación habitual de estos gusanos | | 2 | Cuarentena de versiones con menos de 7 días de publicación | La ventana ciega antes de la detección | | 3 | `osv-scanner` en cada compilación | Lo ya catalogado | | 4 | Fichero de bloqueo fijado y revisado a mano | Actualizaciones silenciosas | Los paquetes que requieren compilar binarios nativos se autorizan **uno a uno y de forma explícita**, no por excepción general. --- ## 8 · Contenido de `security.txt` Publicado en `/.well-known/security.txt` conforme a RFC 9116, con caducidad declarada y revisión antes de que expire. Un `security.txt` caducado indica abandono y es peor que no tener ninguno. --- *Veritas Digital LLC, 5 de agosto de 2026. Procedimiento operativo. Revisión semestral y antes del 11 de septiembre de 2026.*