Mantente un paso adelante de las vulnerabilidades de seguridad con parches de seguridad

Tradicionalmente, como parte del flujo de trabajo de desarrollo de software, los equipos suelen publicar nuevas versiones de sus paquetes o aplicaciones para corregir los problemas de seguridad a medida que surgen.

Sin embargo, en los proyectos de código abierto, como los responsables de mantenimiento suelen ser voluntarios y pueden distraerse con sus compromisos habituales, las versiones de los paquetes con correcciones pueden tardar en publicarse. Esto puede generar una brecha considerable entre el momento en que se descubre una vulnerabilidad y aquel en que se corrige y se hace pública. Lamentablemente, si no hay una versión oficial publicada con una corrección para ese componente de software, aumenta el riesgo de explotación.

Para enfrentar estas situaciones, Snyk selecciona parches de seguridad para proyectos JavaScript de código abierto en el ecosistema npm. Así ayudamos a los responsables de mantenimiento a mantener seguros sus paquetes y a anticiparse a las amenazas, incluso cuando no tienen tiempo para corregir los problemas de seguridad de inmediato. Snyk aplica una corrección de seguridad directamente a cualquier paquete npm afectado, en coordinación con su responsable de mantenimiento. De esta manera, incluso si no hay una versión oficial que resuelva el problema (o si la versión podría interrumpir tu compilación), estamos aquí para ayudarte.

¿Por qué son importantes los parches de seguridad?

El tiempo que tardan los responsables de mantenimiento de código abierto en publicar una corrección de seguridad puede tener un impacto grave. Por eso, los parches de seguridad son esenciales. Como ejemplo, podemos mencionar las vulnerabilidades de contaminación de prototipos que se descubrieron recientemente en la popular biblioteca de JavaScript lodash.

El equipo de investigación de seguridad de Snyk descubrió vulnerabilidades de contaminación de prototipos en lodash (CVE-2019-10744) que afectaban a todas las versiones. Desde el momento del descubrimiento, trabajamos con John Dalton, responsable de mantenimiento de lodash, mediante un proceso de divulgación responsable para comunicar los hallazgos y proporcionar correcciones de seguridad que resolvieran las vulnerabilidades.

Una vez que las correcciones se hicieron públicas como un Pull Request para resolver el problema de seguridad en el repositorio de lodash, comenzó la cuenta regresiva para el lanzamiento oficial de lodash con esas correcciones.

La información sobre la vulnerabilidad se hizo pública el 2 de julio de 2019, pero la versión oficial se retrasó una semana y no se publicó hasta el 9 de julio de 2019.

El parche de seguridad que proporciona el mecanismo de Snyk es gratuito para todos los usuarios. Abrimos Pull Requests de forma proactiva para aplicar el parche, corregir la vulnerabilidad de seguridad y proteger tus proyectos.

¿Cómo aplica Snyk los parches de seguridad?

El mecanismo de aplicación de parches a módulos de Snyk se integra con la compatibilidad de scripts de npm package.json para los eventos del ciclo de vida. El proceso de npm permite que los programas de corrección se integren sin problemas con la administración del ciclo de vida de npm durante las distintas fases de la compilación, por ejemplo, cuando npm se instala, cuando se publica en un registro, entre otras.

La página de documentación de npm contiene información detallada sobre todos los eventos disponibles del ciclo de vida de npm, y sobre cómo y cuándo funcionan.

Snyk usa el evento del ciclo de vida prepublish en package.json para aplicar parches antes de empaquetar y publicar el paquete, y también cada vez que se ejecuta npm install localmente sin argumentos adicionales_._Para ver mejor cómo funciona, podemos crear algunos paquetes localmente y usar verdaccio como registro npm local para experimentar con la publicación y la instalación de módulos.

Con un npm init -y y una actualización de nuestro módulo de prueba aaa para incluir un script prepublish, el código queda así:

1
2{
3  "name": "aaa",
4  "version": "1.1.0",
5  "description": "",
6  "scripts": {
7    "test": "echo \"Error: no test specified\" && exit 1",
8    "prepublish": "echo hello little green world"
9  },
10  "main": "index.js",
11  "keywords": [],
12  "author": "",
13  "license": "ISC"
14}

Cuando ejecutamos un npm install en la línea de comandos, se muestra lo siguiente:

Se ejecutó nuestro evento del ciclo de vida de npm, que imprimió este breve texto en la consola y también permitió que Snyk aplicara los parches necesarios.

Snyk actualiza la configuración de tu evento pre-publish para que quede así:

1
2"scripts": {
3  "snyk-protect": "snyk protect",
4  "prepublish": "npm run snyk-protect"
5}

Cuando se ejecuta un npm install, Snyk detecta las vulnerabilidades que hay en tu código, descarga de nuestra base de datos un parche para corregirlas y lo aplica al módulo vulnerable en la carpeta node_modules.

Esto significa que, cuando clonas un proyecto, instalas todas sus dependencias y lo ejecutas, Snyk se activa durante la instalación de los módulos para aplicar un parche a la vulnerabilidad de seguridad.

En los proyectos de Node.js, la aplicación ya está protegida cuando la ejecutas. En el caso de una biblioteca JavaScript típica que transpila código, por ejemplo, con un empaquetador de módulos como webpack, babel o typescript, el resultado del paquete que suele estar en dist/ también incluye la corrección de seguridad.

¿Cómo funciona npm prepublish?

Quizá sigas distintos flujos de trabajo y no solo un simple npm install para tu proyecto, lo que significa que podrías omitir el evento prepublish. En esos casos, no se aplican los parches de Snyk.

Para entender mejor el evento de script prepublish de npm, veamos cómo se invoca:

• npm install

• npm install --dev

• npm ci

• yarn

• yarn install

• yarn install --frozen-lockfile

¿Cuándo no se invoca el evento prepublish de npm?

• npm install --prod

• yarn install --prod

Como mencioné antes, al ejecutar npm install con argumentos adicionales, no se incluye prepublish. Por lo tanto, si tu flujo de trabajo para instalar dependencias de módulos npm incluye ejecutar npm install --prod, puedes invocar directamente snyk protect de Snyk.

Por ejemplo, considera la siguiente configuración de Travis CI:

1
2install:
3  - npm install --prod
4  - snyk protect

Parches de seguridad de Snyk para bibliotecas

En nuestros experimentos con paquetes npm usamos estas dos bibliotecas:

• aaa: tiene vulnerabilidades de seguridad en sus dependencias y sus responsables de mantenimiento no han publicado versiones más recientes con una corrección oficial. Los parches de Snyk corrigen estas vulnerabilidades.

• bbb: usa aaa como dependencia propia.

En nuestro caso, el proyecto bbb usa aaa. Cuando bbb instala sus dependencias, por ejemplo, al ejecutar npm install, no se ejecuta el evento del ciclo de vida prepublish de aaa.

Esto significa que, a menos que aaa se haya publicado en el registro como un paquete transpilado que incluya todas sus dependencias —algo común únicamente en las bibliotecas frontend—, al instalar aaa en bbb, las bibliotecas anidadas de aaa siguen teniendo las mismas vulnerabilidades de seguridad conocidas.

En estos casos, el responsable de mantenimiento de la biblioteca principal bbb debe corregir las vulnerabilidades de seguridad ofreciendo parches que también resuelvan las dependencias anidadas de aaa.

Resumen

En conclusión, cuando los responsables de mantenimiento no pueden publicar nuevas versiones con correcciones de seguridad con suficiente rapidez o, en el peor de los casos, ya no participan en los proyectos y no responden, aumenta aún más el tiempo durante el cual persisten las vulnerabilidades de seguridad. Por estas razones, los parches de seguridad precisos son una herramienta fundamental para ayudarte a anticiparte a las vulnerabilidades que aún no se han corregido.