Express.js
Seguridad de dependencias y supply chain
Explica cómo reducir riesgos de paquetes, scripts, lockfiles, vulnerabilidades, typosquatting y actualizaciones dentro de proyectos Express.js.
- Última actualización
- Actualizada
- Nivel
- Aplicación
Express.js
Explica cómo reducir riesgos de paquetes, scripts, lockfiles, vulnerabilidades, typosquatting y actualizaciones dentro de proyectos Express.js.
La aplicación ejecuta código de cientos de dependencias directas y transitivas. Supply chain security reduce la probabilidad de instalar, construir o desplegar código comprometido.
El riesgo no comienza cuando Express recibe una request. También existe en:
registry
→ package manager
→ install scripts
→ build
→ artifact
→ deployUna dependencia vulnerable, secuestrada o mal configurada puede ejecutar con los permisos del proceso.
Conoce:
El lockfile es parte del inventario y debe versionarse.
Rangos semver permiten updates; lockfile hace reproducible la resolución concreta. En CI usa instalación congelada:
npm ciEsto falla si package.json y lock no coinciden.
Reproducible no significa seguro: puede reproducir una versión vulnerable. Necesitas actualización continua.
Automatizan PRs, pero cada update requiere:
No acumules cientos de PRs ignorados; define cadencia y ownership.
npm audit y scanners encuentran vulnerabilidades conocidas. Limitaciones:
Evalúa reachability, exposición y compensating controls, pero documenta excepciones con fecha.
Cada paquete añade:
No instales una dependencia para una función trivial si Node la ofrece de forma clara. Tampoco reimplementes criptografía o parsers complejos por evitar paquetes.
Verifica nombres y repositorio. Paquetes con nombres parecidos pueden ser maliciosos. Usa allowlists o políticas en organizaciones.
preinstall, install y postinstall ejecutan código. En entornos sensibles:
Deshabilitar scripts globalmente puede romper dependencias legítimas; prueba el enfoque.
Usa registry confiable, autenticación y controles de publicación. Para paquetes propios:
Si un paquete interno sin scope existe en registry público con versión superior, una configuración incorrecta puede instalar el público.
Mitigaciones:
Builds de PRs no confiables no deben recibir secretos de publicación o producción. Separa workflows de test y release.
No ejecutes código de fork con tokens privilegiados.
Construye una vez y promueve el mismo artifact entre ambientes:
commit
→ build/test/scan
→ image digest
→ staging
→ productionNo reinstales dependencias diferentes en producción.
Una Software Bill of Materials registra componentes y versiones. Ayuda a responder rápidamente si aparece una vulnerabilidad.
Debe asociarse al artifact concreto y almacenarse de forma consultable.
Firmar imágenes/artefactos y verificar en deployment reduce riesgo de sustitución. La confianza depende de proteger identidad y pipeline de firma.
Fijar digest mejora reproducibilidad, pero requiere proceso para actualizar parches.
Aunque una dependencia sea comprometida, limita impacto:
Defense in depth asume que algún control puede fallar.
Una librería de parsing queda vulnerable:
Si no puedes actualizar:
Una excepción sin vencimiento se vuelve deuda invisible.
Security no termina en build:
npm ci limpio.Deployment de Express lleva el artifact verificado a producción con health, configuración y rollback.