![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>La soluci\u00f3n \u00f3ptima ser\u00eda transferir solo las correcciones y vulnerabilidades m\u00e1s importantes, pero el principal problema radica en identificar tales errores entre el flujo general. La mayor\u00eda de los problemas emergentes son el resultado del uso del lenguaje C, que requiere gran precisi\u00f3n al trabajar con memoria y punteros. La situaci\u00f3n se agrava porque muchas correcciones potenciales de vulnerabilidades no se acompa\u00f1an de identificadores CVE o reciben tal identificaci\u00f3n un tiempo despu\u00e9s de la publicaci\u00f3n del parche. En estas circunstancias, a los fabricantes les resulta muy dif\u00edcil distinguir las correcciones secundarias de los problemas importantes que afectan la seguridad. Seg\u00fan las estad\u00edsticas, m\u00e1s del 40 % de las vulnerabilidades se corrigen antes de recibir CVE, y el retraso promedio entre la emisi\u00f3n del parche y la asignaci\u00f3n de CVE es de tres meses (es decir, inicialmente el parche se percibe como un error com\u00fan, pero solo despu\u00e9s de unos meses se hace evidente que se trat\u00f3 de una correcci\u00f3n de vulnerabilidad).<\/p>\nEn consecuencia, al no tener una rama separada para las correcciones de vulnerabilidades y no recibir informaci\u00f3n sobre la relaci\u00f3n de seguridad de un determinado problema, los fabricantes de productos basados en el n\u00facleo de Linux tienen que seguir trasladando todas las correcciones de las nuevas ramas estables. Pero este trabajo requiere un gran esfuerzo y enfrenta resistencia en las empresas debido al temor a la aparici\u00f3n de cambios regresivos que puedan afectar el funcionamiento normal del producto.<\/p>\n
Recordemos que, seg\u00fan Linus Torvalds, todos los errores son importantes y las vulnerabilidades no deber\u00edan separarse de otros tipos de errores ni destacarse en una categor\u00eda m\u00e1s prioritaria. Esta opini\u00f3n se explica porque para un desarrollador com\u00fan, que no se especializa en cuestiones de seguridad, no es evidente la relaci\u00f3n entre una correcci\u00f3n y una vulnerabilidad potencial (para muchas correcciones, solo una auditor\u00eda separada permite entender que est\u00e1n relacionadas con la seguridad). Seg\u00fan Linus, la tarea de identificar entre el flujo general de correcciones las vulnerabilidades potenciales debe ser asumida por especialistas en seguridad de los equipos responsables del mantenimiento de los paquetes del n\u00facleo en las distribuciones de Linux.<\/p>\n
Kees Cook considera que la \u00fanica soluci\u00f3n para mantener la seguridad del n\u00facleo con costos razonables a largo plazo es la reorientaci\u00f3n de ingenieros en las empresas que se dedican a portar correcciones a versiones locales del n\u00facleo, hacia un trabajo conjunto y coordinado en el mantenimiento de correcciones y vulnerabilidades en el n\u00facleo principal (upstream). En la actualidad, muchos fabricantes utilizan versiones no tan recientes del n\u00facleo en sus productos y realizan backporting de correcciones por su cuenta, lo que resulta en que los ingenieros de diferentes empresas duplican el trabajo unos de otros al resolver el mismo problema.<\/p>\n
Por ejemplo, si 10 empresas, cada una con un ingeniero dedicado al backporting de las mismas correcciones, reorientaran a esos ingenieros para que corrigieran errores en el upstream, en lugar de portar una sola correcci\u00f3n, podr\u00edan arreglar 10 errores distintos en beneficio com\u00fan o participar en la revisi\u00f3n de los cambios propuestos y evitar que se incluya c\u00f3digo con errores en el n\u00facleo. Los recursos tambi\u00e9n podr\u00edan destinarse a desarrollar nuevas herramientas para pruebas y an\u00e1lisis de c\u00f3digo que permitan identificar autom\u00e1ticamente, en una fase temprana, clases t\u00edpicas de errores que surgien una y otra vez.<\/p>\n
Kees Cook tambi\u00e9n sugiere utilizar m\u00e1s activamente las pruebas automatizadas y de fuzzing directamente en el proceso de desarrollo del n\u00facleo, aplicar sistemas de integraci\u00f3n continua y abandonar la arcaica gesti\u00f3n del desarrollo a trav\u00e9s de correo electr\u00f3nico. Actualmente, la eficacia de las pruebas se ve obstaculizada porque los procesos principales de prueba est\u00e1n separados del desarrollo y ocurren solo despu\u00e9s de la formaci\u00f3n de las versiones. Kees tambi\u00e9n recomend\u00f3 para reducir el n\u00famero de errores utilizar durante el desarrollo lenguajes que proporcionen m\u00e1s un alto nivel de seguridad<\/a>, como Rust.<\/p>\n