¿De dónde vienen los parches de seguridad?

Las vulnerabilidades conocidas en el software son un problema ampliamente reconocido y han causado algunas de las mayores brechas de seguridad del mundo, como la brecha de Mossack Fonesca (Panama Papers), la de VerticalScope, en la que se robaron 45 millones de contraseñas y direcciones IP de una red de 1,100 sitios web, y la brecha de los foros de Ubuntu, en la que se robaron 2 millones de nombres de usuario y contraseñas.

La mejor solución para las vulnerabilidades conocidas es actualizar el software. Sin embargo, no siempre es posible. Puede que no haya una actualización de seguridad disponible de inmediato para el software del que dependes. O bien, la actualización puede incluir cambios importantes en la funcionalidad, conocidos como “breaking changes”, que afectan la forma en que las personas u otros sistemas integrados acceden al software y lo usan. Esto hace que las actualizaciones sean costosas y, a menudo, inviables.

La siguiente mejor solución es aplicar un parche al software. Un parche de seguridad es una actualización de una pieza de software que corrige un problema de seguridad específico y, al mismo tiempo, modifica lo menos posible la funcionalidad.

En el caso del software de código cerrado, la única forma de obtener un parche de seguridad es recibirlo del proveedor del software e instalarlo. Un ejemplo conocido es Windows Update, que suele distribuir parches de seguridad a millones de PC con Windows. La gestión de parches de proveedores de software comercial es un campo en auge y se ha escrito mucho sobre la “gestión de parches”: el proceso para obtener, probar y aplicar parches de seguridad a tus aplicaciones. Se han desarrollado numerosas herramientas que ayudan al personal de TI a identificar cuándo se publican nuevos parches e implementarlos en su flota de computadoras.

El software de código abierto se está convirtiendo en el estándar de facto para muchos casos de uso en las organizaciones, especialmente como infraestructura para desarrollar software nuevo. El código abierto es tan vulnerable como el código cerrado, pero no siempre está claro dónde conseguir un parche de seguridad para la vulnerabilidad más reciente. Además, muchos mantenedores de proyectos de código abierto trabajan en ellos en su tiempo libre, lo que significa que, incluso después de descubrir una vulnerabilidad, puede pasar un tiempo antes de que el software se actualice o reciba un parche.

Cuatro formas de encontrar parches de seguridad para software de código abierto

1. Actualizar o aplicar un parche de los autores del software de código abierto

El lugar más obvio para buscar un parche es una nueva versión del software de código abierto vulnerable. En la mayoría de los casos, los mantenedores de la biblioteca corrigen las vulnerabilidades.

2. pull requests

En algunos casos, quienes contribuyen a proyectos de código abierto crean un pull request con una propuesta de código para corregir una vulnerabilidad de seguridad. Sin embargo, puede pasar tiempo antes de que el pull request se integre a la versión principal del software, si es que llega a integrarse.

Por ejemplo, la popular biblioteca de análisis de Markdown para JavaScript, marked, tuvo una vulnerabilidad de XSS con un pull request con la corrección abierto durante un año antes de que se incorporara a una nueva versión.

Si hay un pull request abierto que corrige la vulnerabilidad, los usuarios pueden descargar su código y usarlo como una nueva versión con el parche aplicado. Aun así, existe el riesgo de que los cambios de código propuestos no funcionen como se espera o provoquen regresiones en el software. Por eso, se recomienda comprobar si otros miembros de la comunidad ya revisaron el código nuevo y probarlo antes de implementarlo.

3. Crear un fork y corregir el problema

Los usuarios que también son desarrolladores pueden crear un fork —su propia versión— del software de código abierto y corregir la vulnerabilidad por su cuenta. Esto ofrece mayor confiabilidad, porque quien corrige el problema sabe que tiene una versión estable que satisface sus necesidades y no contiene la vulnerabilidad.

La desventaja es que, al crear un fork, los usuarios se desvinculan de la línea principal de actualizaciones y correcciones del software, y con el tiempo podrían quedar más expuestos a vulnerabilidades. Después de todo, constantemente se descubren vulnerabilidades nuevas.

4. Fuentes de actualizaciones

RedHat y Canonical, dos empresas que respaldan el ecosistema Linux, ofrecen una fuente de actualizaciones para los usuarios de Linux que incluye actualizaciones de seguridad.

El servicio LivePatch de Canonical aplica parches críticos al kernel de Ubuntu sin necesidad de reiniciar el sistema.

RedHat ofrece el administrador de paquetes Yum, que te permite actualizar cualquier paquete de Linux a la versión más reciente disponible, que en muchos casos incluirá correcciones de seguridad. El comando yum check-update comprueba qué paquetes instalados tienen actualizaciones disponibles, y el comando yum update package los actualiza automáticamente a la versión más reciente.

El plugin de seguridad de Yum indica qué actualizaciones están relacionadas con la seguridad. El plugin está disponible en RedHat Enterprise Linux 5.0 y viene integrado en RedHat Enterprise Linux 7.0 y versiones posteriores.

Además, los administradores de paquetes como npm (Node.js) y Maven (Java) pueden ayudar a mantener los paquetes actualizados e instalar actualizaciones de seguridad, aunque no detectan cuáles están relacionadas con la seguridad.

5. Snyk

Una herramienta para gestionar vulnerabilidades conocidas debería ser un requisito en cualquier flujo de trabajo de código abierto, pero es importante asegurarse de que también permita aplicar parches. Por eso decidimos incluir esta función en nuestra oferta principal desde el primer día. Mantenemos nuestro propio conjunto de parches en nuestra base de datos de vulnerabilidades. La mayoría son backports de correcciones originales para versiones anteriores que siguen siendo vulnerables. Algunos son pull requests probados y empaquetados como parches que puedes instalar fácilmente. Y otros los escribe el equipo de investigación de seguridad de Snyk.

Puedes incorporar esos parches a tu proceso de compilación automatizado mediante la CLI, o incluso enviarlos a tu proyecto en un pull request automatizado. Al reducir las fricciones para aplicar parches, puedes probarlos e implementarlos rápidamente como parte de tu flujo de trabajo habitual.

Conclusión

La mayoría, si no todos, los productos de software llegarán a tener vulnerabilidades y requerirán actualizaciones o parches. La pregunta es cuánto tardarás en conseguir un parche que resuelva la vulnerabilidad y qué tan fácil será aplicarlo.

En el caso del software de código cerrado, los usuarios dependen de los proveedores de software, que cada vez responden con mayor rapidez a los problemas de seguridad. En el caso del software de código abierto, una comunidad activa de mantenedores es la mejor protección contra las vulnerabilidades de seguridad y otros defectos. Pero en muchos casos, la comunidad de código abierto no proporcionará el parche que necesitas cuando lo necesitas.

Puedes esforzarte por encontrar o crear un parche por tu cuenta, o recurrir a proveedores como Canonical, RedHat o Snyk para obtener una corrección automatizada. A medida que el ecosistema de código abierto se vuelve más complejo, prevemos que las herramientas se convertirán en un componente esencial de la postura de seguridad de cualquier organización.