Gestión de vulnerabilidades

• Avisos automáticos de vulnerabilidades conocidas en las dependencias del proyecto.
• Análisis de las dependencias en cada cambio, mediante las herramientas del gestor de paquetes.
• Comprobación de tipos y compilación en cada cambio: un fallo de compilación no llega a producción.
• Pruebas automatizadas, entre ellas la del aislamiento entre clientes, que se ejecuta contra la base real.
• Avisos externos recibidos en admin@oriax.ai.
• Boletines de seguridad de los proveedores que usamos.

La gravedad se decide por el daño posible a datos de clientes, no por la puntuación teórica del aviso. Un fallo crítico en una biblioteca que no interviene en ninguna ruta alcanzable desde fuera no es crítico para nosotros; un fallo medio en el camino del aislamiento sí lo es.

• Crítica — permite leer o modificar datos de otro cliente, o eludir la autenticación.
• Alta — permite acceso no autorizado a datos de un cliente concreto, o ejecución de código.
• Media — degrada la seguridad sin exponer datos por sí sola.
• Baja — sin impacto práctico en la configuración actual.

• Crítica — contención inmediata y corrección en 48 horas.
• Alta — 7 días naturales.
• Media — 30 días naturales.
• Baja — en el siguiente ciclo ordinario de mantenimiento.

Los plazos cuentan desde la confirmación, no desde el aviso. Si una corrección no llega a tiempo se documenta por qué y qué medida provisional la sustituye mientras tanto.

Las versiones quedan fijadas por el archivo de bloqueo del gestor de paquetes, de modo que lo que se compila en el servidor es exactamente lo que se probó. Las actualizaciones de seguridad se aplican en cuanto existen; las demás, agrupadas y con revisión.

La imagen del contenedor se reconstruye en cada despliegue desde una imagen base reciente, lo que arrastra las correcciones del sistema operativo sin intervención manual.

Si encuentras un fallo, escríbenos a admin@oriax.ai. Acusamos recibo en 24 horas y te mantenemos informado hasta el cierre. Te pedimos que no divulgues el fallo hasta que esté corregido, y que no accedas a datos de terceros más allá de lo imprescindible para demostrarlo.

A cambio: no emprendemos acciones legales contra quien investigue de buena fe respetando esas dos condiciones, y damos crédito público a quien lo desee.

Cada vulnerabilidad confirmada se anota con fecha de detección, gravedad asignada, fecha de corrección y cambio que la resuelve. Ese registro es el que permite comprobar si los plazos de arriba se cumplen de verdad.