Análisis de vulnerabilidades en dependencias de NPM, PIP y Composer

Clase 39 de 53 • Curso de DevOps con GitLab

Resumen

La seguridad en dependencias de NPM, PIP y Composer define la salud de tu software. Integrar análisis de dependencias en GitLab y decidir con criterio ante vulnerabilidades te ahorra incidentes graves. Aquí entenderás por qué las dependencias son frágiles, cómo usar el Dependency Scanning y qué hacer ante paquetes maliciosos.

¿Por qué las dependencias son un punto crítico de seguridad?

Las dependencias concentran riesgos porque son código que no escribiste, difícil de auditar a detalle y con funcionamiento interno desconocido. Esto no te hace mal desarrollador: aplica el principio de encapsulación, pero exige control y monitoreo.

¿Qué riesgos introducen paquetes de NPM, PIP y Composer?

Inclusión de vulnerabilidades sin detectar por auditorías manuales.
Presencia de paquetes maliciosos que parecen legítimos.
Exfiltración de datos si el paquete accede a variables de entorno.
Dependencias de desarrollo menos críticas que las de producción, pero igual deben evaluarse.

¿Cómo afecta el principio de encapsulación?

Permite reutilizar código sin conocer su interior.
Aumenta dependencia de terceros: por eso automatiza la verificación de vulnerabilidades.
Evita “whitelistar” manualmente paquete por paquete: mejor usa escaneo sistemático.

¿Por qué las variables de ambiente son objetivo?

Contienen llaves de bases de datos y API keys.
Si un paquete es malicioso, puede enviar estas variables al atacante en producción.
Caso narrado: una librería “legítima” estilo Mark Improved o Mark 2 copió funcionalidades y envió variables de ambiente al autor malicioso, detectado por tráfico saliente inusual.

¿Cómo aplicar dependency scanning en GitLab sin fricción?

El análisis de dependencias funciona como el análisis estático de código: se ejecuta la misma imagen de análisis sobre tu código y sobre todas las dependencias. En GitLab, usa el patrón modular para incluir Dependency Scanning en tu pipeline.

¿Qué muestra el widget de seguridad en un merge request?

Hallazgos de vulnerabilidades en dependencias directamente en el merge request.
Información en contexto para decidir antes de fusionar.
Visibilidad centralizada en el widget de seguridad al pulsar “Expandir”.

¿Qué patrón modular reutilizar?

Incluye la plantilla de Dependency Scanning en tu configuración de CI.
Fragmento citado:

include template Dependency Scanning gitlabci.yaml

Esto habilita el escaneo automático en cada cambio: decisiones informadas sin esfuerzo extra.

¿Cómo identificar paquetes maliciosos?

Observa solicitudes salientes inesperadas desde servidores.
Revisa hallazgos del widget de seguridad.
Si una librería “popular” cambia de nombre o surge una “mejora” sospechosa, verifica su comportamiento.

¿Qué decisiones tomar ante vulnerabilidades en paquetes?

Las vulnerabilidades requieren decisiones claras respaldadas por severidad, impacto y entorno. No todas exigen bloquear el merge; prioriza según riesgo real.

¿Cuándo corregir, reemplazar o aceptar el riesgo?

Corregir: si la severidad es alta o afecta producción.
Reemplazar la dependencia: si el paquete acumula fallos o no se actualiza.
Aceptar el riesgo: si la vulnerabilidad es baja y con mitigaciones claras.

¿Cómo evaluar si es de desarrollo o producción?

Desarrollo: impacto menor en tiempo de ejecución, evalúa caso por caso.
Producción: exige acción inmediata si hay exposición de datos o ejecución en tiempo real.

¿Qué enseña el caso de NCU o NPM Check Updates?

Ejemplo directo: al escanear NCU o NPM Check Updates se hallaron más de setenta vulnerabilidades.
Decisión efectiva: cambiar a otra librería con el mismo comportamiento pero sin vulnerabilidades.

Comparte en los comentarios tus experiencias con vulnerabilidades en dependencias: ayuda a crear conciencia y mejorar la seguridad colectiva.

Andres Rodriguez

student•

El año pasado se detectó un paquete de npm muy usado por muchos desarrolladores (event-stream) que estaba infectado con código malicioso. En resumen, un usuario malintencionado se ganó la confianza del mantenedor del repo del paquete para luego, ya siendo un contribuidor (de hecho, llegó a ser el dueño del repo), introcudir este código malicioso. La forma en que lo hizo vulneró incluso a los escaneos de código estático como el que vemos en este curso. Les dejo el resto: https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502

Francisco Garcia [C6]

student•

fue un usuario de Twitter, que por esta red alertó de un comportamiento malicioso en el paquete ‘cross-env’ al detectar que robaba información de las variables de entorno durante la instalación.

Este paquete, según npm, es uno de los muchos paquetes fraudulentos detectados, el cual fue publicado por el usuario ‘hacktask’ el día 19 de Julio, imitando ser el paquete ‘crossenv’. Dicho paquete fue eliminado el 1 de agosto con unas 700 descargas, aunque muchas de éstas fueron realizadas por automatismos y tan solo unas 50 parecen ser infecciones reales

El ataque utilizado en estos repositorios se denomina ‘typo-squatting’ y consiste en nombrar al paquete fraudulento con un nombre ligeramente similar al nombre de un paquete real. Se busca engañar al usuario para su instalación e infección.

Actualmente el usuario ‘hacktask’ está bloqueado y todos sus paquetes han sido eliminados del repositorio.

A continuación publicamos la lista de estas librerías fraudulentas con el número de descargas según npm.

babelcli: 42 cross-env.js: 43 crossenv: 679 d3.js: 72 fabric-js: 46 ffmepg: 44 gruntcli: 67 http-proxy.js: 41 jquery.js: 136 mariadb: 92 mongose: 196 mssql-node: 46 mssql.js: 48 mysqljs: 77 node-fabric: 87 node-opencv: 94 node-opensl: 40 node-openssl: 29 node-sqlite: 61 node-tkinter: 39 nodecaffe: 40 nodefabric: 44 nodeffmpeg: 39 nodemailer-js: 40 nodemailer.js: 39 nodemssql: 44 noderequest: 40 nodesass: 66 nodesqlite: 45 opencv.js: 40 openssl.js: 43 proxy.js: 43 shadowsock: 40 smb: 40 sqlite.js: 48 sqliter: 45 sqlserver: 50 tkinter: 45

Por el comportamiento malicioso de estas librerías se recomienda cambiar todas las credenciales utilizadas en el entorno de desarrollo.

Helí Fernando Jerez Rincón

student•

Les dejo aquí una BD de vulnerabilidades de software opensource

https://www.whitesourcesoftware.com/vulnerability-database

Juan Stiven Muñoz Garcia

student•

Buenas tardes quisiera saber si se puede hacer un efectivo changelog apartir de nuestros merge request y que agrupe los commits como items de que fue lo que se añade o se arreglo

Salvador Santander Gutiérrez

student•

También me gustaría saberlo

José Hugo Calderón Villanueva

student•

Explicación clara sobre los huecos de seguirdad

Gabriel Hans González Peña

student•

Como tester, se ocupa mucho las herramientas generadoras de datos fake. Así que uno de los casos con ese tipo de paquetes, el famoso faker, fue vulnerado, de manera directa, por el desarrollador tronó todo el repositorio de github que afectó a todos los usuarios de esta misma

Carlos Alberto Gutiérrez Vasquez

student•

Module

module name: morgan **version: **1.9.0 npm page: https://www.npmjs.com/package/morgan

Module Description HTTP request logger middleware for node.js

Named after Dexter, a show you should not watch until completion.

Module Stats 1,120,329 downloads in the last week

Vulnerability

Vulnerability Description

An attacker can use the format parameter to inject arbitrary commands

Steps To Reproduce:

The basic attack vector looks like this:

var morgan = require('morgan');
//payload delivered through a prototype pollution attack
Object.prototype[':method :url :status :res[content-length] - :response-time ms'] = '25 \\" + console.log(\'hello!\'); +  //:method :url :status :res[content-length] - :response-time ms';
//benign looking usage of morgan that can be exploited due to the prototype pollution attack
var f = morgan(':method :url :status :res[content-length] - :response-time ms');
f({}, {}, function () {
});

Eval and it's variants like Function() should almost neve be used in such popular packages.

Patch

N/A remove the usage of Function().

Wrap up

I contacted the maintainer to let them know: N I opened an issue in the related repository: N Impact

If combined with a prototype pollution attack this vulnerability is very serious (RCE). Otherwise, it is very unlikely that the attacker can control the vulnerable format parameter, but not impossible to think.

Carlos Denis

student•

¿Cómo se incluyen diferentes templates en el gitlab-ci ? He intentado con utilizando 2 diferentes, y solo se ejecuta el que pongo en primera posición.

Por ejemplo :

include:
  - template: SAST.gitlab-ci.yml
  - template: Dependency-Scanning.gitlab-ci.yml

Salvador Santander Gutiérrez

student•

Buenas, lo respondió alguien en la siguiente clase. No lo he probado pero si te sirve:

include:
  -'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
  -'/templates/.after-script-template.yml'