Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Una gran parte del software que hace funcionar el mundo se mantiene en el tiempo libre de alguien. Una biblioteca que acaba integrándose en miles de sistemas de producción puede tener detrás a uno o dos responsables de mantenimiento, a menudo sin remuneración, que compaginan esta labor con su trabajo diario. Ese modelo ha impulsado mucho el código abierto, pero se ve sometido a una gran presión precisamente en el momento en que la seguridad más depende de él: cuando hay que notificar una vulnerabilidad, asignarle un CVE, coordinar su gestión y darla a conocer en un plazo determinado.
Llevar a cabo un proceso coordinado de divulgación y asignación de CVE supone un trabajo considerable. Implica clasificar los informes, reservar un identificador, redactar un informe fundamentado, coordinar un embargo y publicar a tiempo. Para un responsable del mantenimiento que ya está al límite de sus capacidades, ese proceso puede descuidarse, y en el caso del software que ha llegado al final de su vida útil, es posible que ni siquiera exista un proceso activo. El resultado es una laguna que acaba absorbiendo toda la comunidad de usuarios: existe una vulnerabilidad, pero la referencia compartida en la que todos confían para realizar su seguimiento y priorizarla aparece tarde o nunca llega. Esto no es un fallo de los mantenedores. Se trata de un desajuste estructural entre el amplio uso que se hace del código abierto y los escasos recursos con los que cuenta gran parte de él.
TuxCare está ahora en condiciones de asumir parte de esa carga.
El anuncio
El Programa CVE ha autorizado a TuxCare como Autoridad de Numeración CVE (CNA). Esto significa que TuxCare puede asignar identificadores CVE y publicar registros CVE para las vulnerabilidades de los productos que mantiene y distribuye, incluidos Endless Lifecycle Support (ELS) y SecureChain para OSS. Los detalles completos se encuentran en nuestro comunicado de prensa.
En qué consiste realmente el trabajo de un auxiliar de enfermería
Una autoridad de numeración CVE es una organización a la que el Programa CVE autoriza a asignar identificadores CVE y a publicar los registros asociados dentro de un ámbito definido. La lista CVE a la que se incorporan dichos registros es una infraestructura compartida: los escáneres, los sistemas SIEM, las fuentes de inteligencia sobre amenazas y los avisos de los proveedores utilizan los identificadores CVE como referencia común para referirse a la misma vulnerabilidad.
Un registro CVE no lo dice todo sobre una vulnerabilidad. Es el punto de coordinación. La CNA puede incluir una puntuación de gravedad y una clasificación de la vulnerabilidad en el propio registro —TuxCare lo hará—, mientras que los sistemas posteriores, como la Base de Datos Nacional de Vulnerabilidades, añaden información adicional, el estado de explotación y detalles sobre la corrección, todo ello vinculado a ese identificador CVE. Por lo tanto, el momento en que se asigna y publica el identificador es importante, ya que es entonces cuando todos los sistemas posteriores pueden empezar a realizar un seguimiento del problema de forma coordinada.
Cuando ninguna CNA cubre un software concreto, el informador debe recurrir a la CNA de último recurso (CNA-LR) del Programa CVE. Ese procedimiento funciona, pero añade un paso intermedio entre las personas que corrigen la vulnerabilidad y las que publican su registro, y esos pasos adicionales suponen una espera adicional. En el caso del software del que dependen muchas personas, ese retraso es el problema.
¿Qué cambios hay para los usuarios de este software?
En el caso de las vulnerabilidades de los productos incluidos en el ámbito de aplicación del CNA de TuxCare, la asignación, la documentación y la corrección se gestionan ahora a través de un único proceso coordinado, siendo TuxCare la fuente oficial de referencia. Una vulnerabilidad confirmada que se encuentre dentro del ámbito de aplicación recibe un identificador CVE en un plazo de 24 horas tras su clasificación, un registro publicado y un parche correspondiente, sin que intervenga ninguna cola de terceros.
Merece la pena hacer especial hincapié en el software al final de su ciclo de vida. Cuando un proyecto llega al final de su ciclo de vida, el proceso de divulgación del responsable del mantenimiento suele ir disminuyendo, aunque el software siga funcionando en producción durante años. Las CNA pueden incluir en su ámbito de aplicación las versiones al final de su ciclo de vida y asignarles CVE, en lugar de dejarlas en la vía de reserva; y el ámbito de aplicación de TuxCare hace precisamente eso a través del ELS. Para las organizaciones que siguen utilizando ese software, esto supone la diferencia entre una vulnerabilidad controlada, documentada y para la que se pueden aplicar parches, y una que queda sin gestionar.
Cómo encaja esto en lo que ya hace TuxCare
TuxCare ya aplica parches a este software. SecureChain recompila y aplica parches a paquetes de código abierto que se mantienen activamente en registros públicos; Endless Lifecycle Support cubre sistemas operativos, bibliotecas y entornos de ejecución de lenguajes que han llegado al final de su ciclo de vida. Ambos se basan en la misma premisa: el software de código abierto del que depende la gente debe seguir siendo seguro, tanto si sus mantenedores siguen al día como si han dejado de ocuparse de él.
La función de la CNA está directamente relacionada con eso. TuxCare ya distribuye el parche; ahora también puede hacerse cargo del registro de la vulnerabilidad que este soluciona. La asignación y la corrección dejan de ser dos pasos inconexos gestionados por dos partes diferentes en dos plazos distintos. Se convierten en un único proceso, coordinado por la misma organización que ya es responsable del parche.
¿Y ahora qué?
La idea general es sencilla. El código abierto impulsa el sector, y gran parte de él lo mantienen personas que nunca se comprometieron a gestionar una operación de divulgación de vulnerabilidades de seguridad. Aliviarles parte de esa carga de coordinación en lo que respecta al software que TuxCare respalda supone una pequeña solución estructural para un problema estructural. Es el tipo de contribución que encaja con una organización cuyo trabajo siempre ha comenzado allí donde el mantenimiento del código abierto llega a su fin.
