Contenido del curso
Análisis de vulnerabilidades en dependencias de NPM, PIP y Composer
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?
¿Cómo afecta el principio de encapsulación?
¿Por qué las variables de ambiente son objetivo?
¿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?
¿Qué patrón modular reutilizar?
include template Dependency Scanning gitlabci.yaml
¿Cómo identificar paquetes maliciosos?
¿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?
¿Cómo evaluar si es de desarrollo o producción?
¿Qué enseña el caso de NCU o NPM Check Updates?
Comparte en los comentarios tus experiencias con vulnerabilidades en dependencias: ayuda a crear conciencia y mejorar la seguridad colectiva.
Andres Rodriguez
Estudiante![Francisco Garcia [C6]](https://static.platzi.com/media/avatars/avatars/garciafran_c845c2fe-2ea4-42db-a305-a7f4ef13b0fd.jpeg){kind=small}
Francisco Garcia [C6]
Estudiante
Helí Fernando Jerez Rincón
Estudiante
Juan Stiven Muñoz Garcia
Estudiante
Salvador Santander Gutiérrez
Estudiante
José Hugo Calderón Villanueva
Estudiante
Gabriel Hans González Peña
Estudiante
Carlos Alberto Gutiérrez Vasquez
Estudiante
Carlos Denis
EstudianteSalvador Santander Gutiérrez
EstudianteEl 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
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.
Les dejo aquí una BD de vulnerabilidades de software opensource
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
También me gustaría saberlo
Explicación clara sobre los huecos de seguirdad
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
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'); var f = morgan('25 \" + console.log('hello!'); + //:method :url :status :res[content-length] - :response-time ms'); f({}, {}, function () { }); However, it is hard to believe that the package is used this way in any application. However, a more interesting attack vector is when combining this vulnerability with a prototype pollution one:
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.
¿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
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'
