Herramientas de DevSecOps para proyectos de código abierto en JavaScript y Node.js

En este artículo, quiero proponer prácticas recomendadas y explicar cómo quienes mantienen y desarrollan proyectos pueden adoptar herramientas de DevSecOps para mejorar la postura de seguridad de sus proyectos de código abierto.

No faltan los incidentes de seguridad ni las historias de terror sobre paquetes maliciosos en el ecosistema de código abierto de JavaScript. Como parte del ecosistema de código abierto, ya sea que mantengamos proyectos o los usemos, debemos prestar la debida atención a la seguridad del código abierto para asegurarnos de que nadie quede expuesto a riesgos.

La siguiente recopilación de herramientas de DevSecOps y prácticas de seguridad se basa en mi experiencia en Snyk trabajando de cerca con el proyecto de proxy privado ligero y registro npm verdaccio. En concreto, vamos a cubrir lo siguiente:

1. Adopta una política responsable de divulgación de vulnerabilidades e inclúyela en tus proyectos como parte de las pautas de seguridad.

2. Establece un proceso y pautas de seguridad.

3. Asegúrate de que todas las personas que mantienen o colaboran en el proyecto tengan habilitada la autenticación de dos factores (2FA) tanto en GitHub como en el registro npm.

4. Evita las filtraciones de datos y la exposición de información confidencial mediante el uso de hooks de git pre-commit que impidan que los desarrolladores filtren contraseñas y secretos al confirmar cambios y subirlos a un repositorio.

5. Integra el análisis y la corrección de dependencias de código abierto para evitar vulnerabilidades en paquetes de código abierto de terceros. Integrar Snyk en el flujo de trabajo de git puede ayudarte.

6. Usa Snyk Advisor para buscar y comparar más de un millón de paquetes de código abierto en el registro npm y elegir el paquete npm adecuado.

Adopta una política responsable de divulgación de vulnerabilidades

Una política responsable de divulgación de vulnerabilidades permite que investigadores de seguridad y otros usuarios reporten vulnerabilidades que afectan al proyecto y gestionen el proceso en una conversación privada, lejos de miradas indiscretas.

La conversación privada permite que todas las partes involucradas —es decir, quienes mantienen el proyecto y quienes investigan la seguridad— realicen una investigación más detallada, clasifiquen la vulnerabilidad, preparen una prueba de concepto y, por último, creen una corrección para remediarla.

Una vez que haya una corrección disponible y se haya publicado durante un tiempo razonable, la vulnerabilidad puede divulgarse públicamente y los usuarios podrán actualizar sus paquetes para recibir la corrección de seguridad.

Este proceso ayuda a proteger a los usuarios de vulnerabilidades que se divulgarían sin coordinación previa con el proyecto.

Para conocer más a fondo por qué es tan importante la divulgación responsable de vulnerabilidades, consulta Entender la divulgación responsable. El equipo de investigación de seguridad de Snyk ofrece un programa para quienes mantienen proyectos de código abierto, en el que nuestro equipo colabora en la clasificación de vulnerabilidades, trabaja en una corrección y solicita un CVE. Está disponible para muchos ecosistemas basados en lenguajes de programación, como Node.js, Java, .NET, Python, Ruby, PHP y otros:/.

Establece pautas de seguridad

Un proyecto debe contar con procesos de seguridad que permitan responder a incidentes con la participación de sus integrantes y comunicar su preparación y sus políticas de seguridad a los investigadores.

La siguiente información debe estar disponible:

1. Políticas de seguridad del proyecto; por ejemplo, qué vulnerabilidades se consideran problemas de seguridad y cuáles no se consideran vulnerabilidades.

2. Una política responsable de divulgación de vulnerabilidades o referencias a programas existentes que la contemplen.

3. Información de contacto para comunicarse con los responsables de seguridad del proyecto. Se recomienda adoptar los campos pertinentes de la especificación security.txt.

4. Evita filtrar secretos: ya sea que uses claves de API, contraseñas u otros secretos, pueden terminar fácilmente en el control de código fuente o incluso en un paquete publicado en el registro npm público.

Para comunicar esta información de manera eficaz, se recomienda incluirla en un archivo SECURITY.md en el directorio de nivel superior del proyecto.

Todas las personas que colaboran en el proyecto deben habilitar 2FA

Como responsables y colaboradores de confianza para publicar versiones seguras de malware de un proyecto, debemos asegurarnos de que nuestras cuentas no se vean comprometidas. Esto ya ocurrió en npm, con el incidente de seguridad de eslint-scope, el paquete npm mailparser y otros.

Sí, ya se han comprometido paquetes e inyectado malware, y volverá a ocurrir. Puedes leer más sobre qué es una puerta trasera y ver lo fácil que es crear una con Node.js y publicarla en npm.

Para minimizar los incidentes de toma de control de cuentas y de paquetes comprometidos, asegúrate de lo siguiente:

1. Todas las personas colaboradoras habilitan la autenticación de dos factores (u otras formas de autenticación multifactor) en el repositorio de código fuente.

2. Todas las personas colaboradoras con permiso para publicar el paquete habilitan la autenticación de dos factores en el registro npm.

3. ¡No olvides analizar tus proyectos para detectar puertas traseras conocidas!

Evita las filtraciones de datos y la exposición de información confidencial

Un problema común al administrar repositorios públicos de proyectos de código abierto es que es muy fácil publicar por error secretos como contraseñas y claves de API, u otra información confidencial.

He visto que esto ocurre muchas veces, tanto en proyectos de código abierto como en proyectos privados de código interno, que tampoco están a salvo del impacto de la filtración de secretos. Recuerda: ¡git lo recuerda todo!

Usa hooks de git

Es posible que tengas secretos en tu directorio de trabajo, en archivos específicos como .env, que deberían excluirse de las confirmaciones en un SCM o de la publicación en un registro de paquetes. Sin embargo, es inevitable que ocurran errores, por eso necesitamos controles que nos ayuden a prepararnos para esta posibilidad.

Hay muchas herramientas excelentes que pueden analizar tus confirmaciones de manera estática mediante un hook de Git pre-commit para asegurarse de que no intentes subir contraseñas ni información confidencial a tu repositorio de GitHub. Las confirmaciones se rechazarán si la herramienta encuentra patrones de expresiones regulares configurados para detectar información confidencial. Puede que ralentice un poco las subidas, pero vale mucho la pena.

También puedes usar herramientas como GitGuardian en tus pipelines de CI y CD para detener automáticamente las compilaciones cuando se encuentre información confidencial en el código o en un archivo de configuración. Establecer reglas para todo el equipo que eviten que esto ocurra es una excelente forma de prevenir malas prácticas en el flujo de trabajo de desarrollo actual.

¿Por qué es importante?

1. https://github.blog/2019-05-14-git-ransom-campaign-incident-report/

2. https://about.gitlab.com/2019/05/14/git-ransom-campaign-incident-report-atlassian-bitbucket-github-gitlab/

Evita las filtraciones de contraseñas con la herramienta detect-secrets

Es una prioridad de seguridad garantizar que quienes mantienen y desarrollan el proyecto de código abierto Verdaccio para npm, que se usa para ofrecer un registro privado de npm y un servidor proxy, no filtren contraseñas ni información confidencial.

Me uní a ellos para colaborar en un Pull Request que agrega una herramienta a su flujo de trabajo de desarrollo y los protege para evitar que filtren información confidencial al control de código fuente.

Elegimos el proyecto detect-secrets de Yelp por su flexibilidad para administrar un manifiesto de secretos en un repositorio y por su arquitectura general para auditar los secretos detectados. Esto permite administrar manifiestos de secretos sin conexión, hacerles seguimiento y crear listas de permitidos, además de aplicar medidas preventivas cuando se interactúa con el repositorio de git.

Modos de funcionamiento:

1. Medida preventiva: para proteger a los usuarios e impedir que agreguen secretos al control de código fuente, el proyecto proporciona el ejecutable detect-secrets-hook, que recibe archivos como argumentos y los analiza en busca de secretos. Si detecta alguno, genera una alerta y cancela todo el proceso.

2. Análisis sin conexión para auditorías y listas de permitidos: la medida preventiva mencionada solo se aplica al crear confirmaciones, por lo que únicamente evita que se agreguen secretos a partir del momento en que se implementa. Un análisis sin conexión permite analizar todos los archivos de un repositorio git para crear una base de referencia de secretos conocidos. Luego se puede auditar para determinar si se trata de un falso positivo o de un secreto que se debe eliminar y revocar correctamente.

Los dos modos de funcionamiento se complementan y ofrecen la flexibilidad de adoptar cualquiera de ellos de manera independiente, según las necesidades de los desarrolladores.

Usar detect-secrets como herramienta en tus hooks de git puede no ser lo más adecuado para todos los proyectos, especialmente los de JavaScript y Node.js, porque requiere un entorno funcional de Python. Si esto no representa un problema para tu proyecto, puedes instalarla y empezar a usarla así:

$ pip install --user detect-secrets

Como alternativa, aquí tienes una receta para usarla en proyectos de JavaScript y Node.js basados en npm y evitar la exposición de información confidencial con detect-secrets.

Para implementar una medida preventiva de pre-commit para desarrolladores de JavaScript, usaremos las siguientes dos dependencias del proyecto:

• husky permite que los proyectos npm administren fácilmente los hooks de git para los desarrolladores mediante un manifiesto a nivel del proyecto y una dependencia npm que simplifica la administración de hooks con herramientas que ya conocen los desarrolladores de JavaScript.

• lint-staged permite ejecutar tareas como linters y formateadores en archivos preparados para confirmar, de modo que cumplan con las reglas preconfiguradas cuando se agregan al control de código fuente.

Nota: lint-staged es opcional, pero suele ser una dependencia bastante común en los proyectos de JavaScript.

Una vez que agregues lint-staged y husky como dependencias de desarrollo del proyecto, puedes actualizar el archivo package.json con la configuración necesaria para el hook pre-commit:

"husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },
 "lint-staged": {
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

A partir de ese momento, cada vez que agregues o actualices un archivo en el control de código fuente de git, se analizará en busca de información confidencial, como secretos, contraseñas y claves de API, y se detendrá la operación de confirmación en el repositorio.

Nota: en los monorepos donde las dependencias husky y lint-staged están instaladas en directorios anidados, y no en el nivel superior, será necesario actualizar la configuración de lint-staged para adaptarla al directorio .git:

 "lint-staged": {
   "relative": true,
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Base de referencia de secretos

Para asegurarnos de que se hayan analizado todos los archivos del repositorio git en busca de posibles secretos, ejecutamos un análisis puntual:

detect-secrets scan > .secrets-baseline

Una vez finalizado el análisis, el resultado generado sirve como base de referencia de secretos permitidos en todo el código. Los resultados en JSON incluyen metadatos de todos los complementos utilizados, la fecha en que se generó el análisis, un hash del secreto y los detalles del archivo donde se encontró.

A veces, pueden aparecer cadenas parecidas a secretos en la documentación, como en los archivos README. En esos casos, se espera que se confirmen y se mantengan en el control de código fuente porque no son secretos reales. Otras veces, sí se encuentran secretos y hay que tratarlos de forma segura. Una vez resuelto el problema, una nueva acción de scan generará una base de referencia actualizada sin los secretos eliminados.

Para ayudar a los equipos a remediar los secretos que se encuentran en el código, la herramienta ofrece una función de audit que recorre el archivo de base de referencia y solicita interactivamente al usuario que indique si un secreto es un falso positivo —por ejemplo, un secreto usado en archivos de prueba— o un positivo verdadero. En este último caso, el secreto ya está en el control de código fuente y debe eliminarse.

Integra Snyk para desarrollar rápido y mantenerte seguro

¿Cómo puedes desarrollar rápido y mantenerte seguro?

Quienes mantienen y colaboran en proyectos de código abierto suelen incluir paquetes de código abierto en sus proyectos. Además, con el tiempo agregan más dependencias. ¿Cómo sabes si la próxima dependencia que agregues no tiene vulnerabilidades?

El equipo de Verdaccio creó una integración con git que integra Snyk en su repositorio de GitHub para ofrecer un flujo de trabajo de git totalmente compatible, con pruebas de seguridad en la CLI.

¿Quieres empezar a usar Snyk rápidamente? Consulta esta guía para pasar de cero a héroe de la seguridad. Mejor aún, puedes ver un video de 1 minuto y 35 segundos para empezar a usar Snyk rápidamente:

Play Video: Getting Started with Snyk: Import and Test a GitHub Repository

Usa Snyk Advisor para elegir el paquete adecuado

El proyecto npm Verdaccio usa dependencias como commander, pero, como desarrollador, ¿cómo puedes saber si el paquete npm commander es un proyecto saludable?

Por suerte, Snyk Advisor te ayuda a buscar y comparar más de 1 millón de paquetes de código abierto y a cuantificar factores clave para tomar decisiones, como el mantenimiento, la popularidad, la comunidad y la postura de seguridad del proyecto. Con esa información, Snyk Advisor propone una métrica para calcular la puntuación general de salud de un paquete.

Verdaccio también depende de cookies y cors. ¿Qué puntuación tienen? ¡Te dejo descubrirlo!

Palabras finales

En resumen, revisamos varias herramientas de DevSecOps y prácticas de seguridad que puedes usar como responsable de mantenimiento de un proyecto de código abierto o como desarrollador que trabaja en uno. Desde evitar que las contraseñas se filtren al control de versiones, hasta probar y monitorear tus dependencias para detectar vulnerabilidades, e incluso elegir el paquete npm adecuado con Snyk Advisor.

Te recomiendo que sigas leyendo:

• Centro de DevSecOps para conocer más prácticas de seguridad que siguen otras organizaciones, como Auth0 y Datadog. El centro incluye análisis detallados de prácticas de seguridad, como el modelado de amenazas y otras.

• Junto con Juan Picado, escribimos las 10 mejores prácticas de seguridad para npm y una guía de referencia. Puedes descargar un PDF o leer el artículo del blog.

• Es muy probable que hayas trabajado con archivos lock en paquetes basados en npm. ¿Sabías que los archivos lock pueden ser un punto ciego de seguridad que permite inyectar módulos maliciosos?