⌘K
ENES
GitHub
conceptDevSecOps~1 min de lecturaActualizado Apr 23, 2026

Dependency Risk

Definición

Dependency risk es el riesgo de seguridad introducido por librerías, frameworks y paquetes de terceros directos y transitivos, y por sus patrones de actualización y confianza.

Por qué importa

Las dependencias expanden la base de código, la superficie de privilegio y la carga de mantenimiento más allá de lo que el equipo de producto escribe directamente. El riesgo no viene solo de CVEs conocidas, sino de calidad de mantenimiento, version drift, decisiones de confianza y abuso del ecosistema de paquetes. Mantené el límite ajustado: esta nota trata sobre confianza upstream en paquetes y exposición de mantenimiento, no sobre manipulación de artifacts o trazabilidad de release después del build.

Perspectiva del atacante

Los atacantes buscan:

  • paquetes desactualizados con issues conocidas
  • librerías mal mantenidas
  • oportunidades de dependency confusion y typosquatting
  • paquetes transitivos que nadie está mirando

Perspectiva del defensor

Los defensores deberían:

  • minimizar cantidad de dependencias cuando tenga sentido
  • trackear dependencias directas y transitivas
  • priorizar según reachability e impacto, no solo conteo bruto
  • establecer disciplina de actualización y retiro

Ejemplos prácticos

  • un paquete vulnerable queda porque nadie es dueño de la cadencia de updates
  • una dependencia transitiva introduce riesgo que el equipo no sabía que existía
  • se asume confianza en un paquete porque “es popular”

Notas relacionadas

Referencias

  • Fundamental: OWASP Software Supply Chain Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html
  • Fundamental: NIST SP 800-218 SSDF — https://csrc.nist.gov/pubs/sp/800/218/final

Notas relacionadas

DevSecOpsArtifact IntegrityArtifact integrity es la garantía de que outputs de build, paquetes, imágenes y artifacts de release no fueron manipulados y pueden trazarse hasta el proceso de build previsto. DevSecOpsASVS como input del proceso de desarrolloEsta nota trata OWASP ASVS no como una checklist post-hoc, sino como un input del proceso de desarrollo para diseñar, revisar y verificar controles técnicos de seguridad durante la implementación. DevSecOpsProtección de ramas y controles de releaseLa protección de ramas y los controles de release son las reglas y mecanismos de governance que determinan quién puede cambiar rutas de código protegidas, aprobar releases y promover artifacts hacia producción. DevSecOpsCI/CD HardeningCI/CD hardening es asegurar el build, test y deployment pipeline para que la automatización se vuelva una ruta de control confiable en vez de un amplificador de ataques. DevSecOpsContainer SecurityContainer security es la práctica de reducir riesgo en cómo las aplicaciones containerizadas se construyen, configuran, shippean y corren. DevSecOpsImage ScanningImage scanning es el proceso de inspeccionar container images en busca de vulnerabilidades conocidas, paquetes riesgosos y otros issues antes de promoción o deployment.