Gestión de dependencias en desarrollo: El riesgo invisible de las librerías de terceros
- Por Amparo Silva | Amsoft
Introducción
En el ecosistema actual del desarrollo de software, las dependencias de código abierto se han convertido en los cimientos sobre los que se construyen prácticamente todas las aplicaciones modernas. Sin embargo, esta realidad trae consigo un riesgo invisible que muchas organizaciones subestiman: las vulnerabilidades ocultas en librerías de terceros. Según el informe OSSRA 2025 de Black Duck, el 97% de las aplicaciones comerciales contienen componentes de código abierto, con un promedio de 911 componentes por aplicación. Esta dependencia masiva ha transformado la gestión de librerías externas en un factor crítico de seguridad empresarial.
El número de archivos de código abierto en una aplicación promedio se ha triplicado en los últimos cuatro años, pasando de 5.386 en 2020 a más de 16.000 en 2024. Este crecimiento exponencial amplifica significativamente la superficie de ataque potencial. En Chile, donde la Ley Marco de Ciberseguridad (Ley 21.663) entró en vigencia en marzo de 2025, las empresas enfrentan presiones regulatorias adicionales para gestionar adecuadamente estos riesgos. Este artículo explora las mejores prácticas globales para la gestión de dependencias y su aplicación en el contexto empresarial chileno.
1. El caso Log4Shell y otros incidentes por dependencias desactualizadas
1.1 Log4Shell: la vulnerabilidad que sacudió el mundo del desarrollo de software
En diciembre de 2021, la comunidad de desarrollo de software enfrentó una de las crisis de seguridad más significativas de la década. La vulnerabilidad Log4Shell (CVE-2021-44228), descubierta en la biblioteca de logging Log4j, recibió la puntuación máxima de 10/10 en el sistema CVSS, indicando su severidad crítica. Jen Easterly, directora de CISA, la describió como una de las vulnerabilidades más serias que había visto en toda su carrera, estimando que cientos de millones de dispositivos estaban afectados.
La gravedad del incidente radicó en varios factores convergentes: Log4j es una biblioteca de logging extremadamente popular utilizada en aplicaciones Java en todo el mundo, la vulnerabilidad permitía ejecución remota de código con máxima facilidad de explotación, y la biblioteca estaba presente en innumerables sistemas sin que las organizaciones fueran conscientes de ello. Según datos de Arctic Wolf, Log4Shell representó el 11% de todos los casos de respuesta a incidentes en 2022, con un costo promedio de remediación superior a los 90.000 dólares por incidente.
1.2 Patrones de ataques a la cadena de suministro de software
Log4Shell no fue un incidente aislado, sino parte de una tendencia creciente de ataques dirigidos a la cadena de suministro de software. El informe State of the Software Supply Chain 2024 de Sonatype revela que se han detectado más de 512.847 paquetes maliciosos solo en el último año, representando un aumento del 156% respecto al año anterior. Este crecimiento refleja la sofisticación creciente de los atacantes, quienes han identificado las dependencias de código abierto como un vector de ataque de alto impacto.
El caso XZ Utils de 2024 ilustra esta evolución. En este sofisticado ataque, presuntamente respaldado por un estado-nación, los atacantes jugaron un largo juego de ingeniería social para ganar la confianza del mantenedor del proyecto durante dos años antes de introducir código malicioso. Estuvieron a días de lograr que esta versión comprometida fuera integrada en las principales distribuciones Linux, lo que habría proporcionado una puerta trasera a incontables servidores en todo el mundo.
2. Auditando dependencias: herramientas para detectar vulnerabilidades
2.1 Software Composition Analysis (SCA): el estándar de la industria
Las herramientas de Software Composition Analysis se han convertido en componentes esenciales del arsenal de seguridad de cualquier equipo de desarrollo moderno. Estas soluciones automatizan la identificación de componentes de código abierto, sus versiones, licencias asociadas y vulnerabilidades conocidas. Entre las plataformas líderes del mercado se encuentran Black Duck (anteriormente Synopsys), Sonatype Nexus, Snyk y Mend.io (anteriormente WhiteSource).
Según Black Duck, el 86% de las bases de código comerciales auditadas contienen vulnerabilidades de código abierto, y un preocupante 81% presenta vulnerabilidades de alto o crítico riesgo. Estas estadísticas subrayan la importancia de implementar herramientas SCA como parte integral del ciclo de desarrollo. Las soluciones modernas de SCA no solo detectan vulnerabilidades, sino que también proporcionan recomendaciones de remediación, priorizando los riesgos según su severidad y explotabilidad.
2.2 SBOM: el inventario de componentes como estándar de transparencia
El Software Bill of Materials (SBOM) ha emergido como un estándar fundamental para la gestión de dependencias. Un SBOM proporciona un inventario completo de todos los componentes de software, incluyendo bibliotecas de terceros, frameworks y sus versiones específicas. La Orden Ejecutiva 14028 del gobierno de Estados Unidos en 2021 estableció el SBOM como requisito para proveedores de software del gobierno federal, catalizando su adopción global.
Los formatos estándar para SBOM incluyen SPDX (Software Package Data Exchange), respaldado por la Linux Foundation, y CycloneDX, desarrollado por OWASP. Ambos formatos permiten la interoperabilidad entre herramientas y facilitan el intercambio de información sobre componentes entre organizaciones en la cadena de suministro. CISA recomienda activamente la adopción de SBOM como práctica fundamental de seguridad de la cadena de suministro de software.
3. Estrategia de actualización: frecuencia y testing
3.1 El costo oculto de no actualizar
El informe OSSRA 2025 revela un dato alarmante: el 90% de las bases de código auditadas contienen componentes de código abierto con más de cuatro años de antigüedad. Esta práctica de mantener componentes desactualizados amplifica significativamente los riesgos de seguridad, ya que las vulnerabilidades conocidas en versiones antiguas permanecen sin parchear. Además, Sonatype reporta que el 95% de las veces que se consumen componentes vulnerables, ya existe una versión corregida disponible.
El caso de jQuery ilustra perfectamente este problema. Según Black Duck, ocho de las diez vulnerabilidades de alto riesgo más frecuentemente encontradas están en jQuery, una biblioteca JavaScript ampliamente utilizada. El 43% de las aplicaciones escaneadas contienen alguna versión de jQuery, frecuentemente desactualizada. La vulnerabilidad más común, CVE-2020-11023, una vulnerabilidad XSS, todavía está presente en un tercio de las bases de código escaneadas, a pesar de que existen parches disponibles desde hace años.
3.2 Estrategias proactivas de actualización
Las organizaciones líderes implementan estrategias proactivas de actualización que equilibran la seguridad con la estabilidad operativa. Esto incluye ciclos de actualización regulares, típicamente trimestrales para dependencias no críticas, con procesos acelerados para parches de seguridad críticos. La automatización juega un papel crucial: herramientas como Dependabot, Renovate y Snyk pueden generar automáticamente pull requests cuando se detectan actualizaciones disponibles.
El testing automatizado es fundamental para implementar actualizaciones con confianza. Una suite de pruebas robusta, incluyendo pruebas unitarias, de integración y end-to-end, permite verificar que las actualizaciones no introduzcan regresiones. Las organizaciones maduras implementan pipelines de CI/CD que ejecutan automáticamente estas pruebas ante cada actualización de dependencias, reduciendo significativamente el riesgo de introducir inestabilidad en producción.
4. Cuándo es mejor reescribir que depender de librerías obsoletas
4.1 Señales de alerta para considerar la reescritura
No todas las dependencias merecen ser mantenidas indefinidamente. Existen señales claras que indican cuándo una biblioteca debe ser reemplazada o su funcionalidad debe ser reimplementada internamente. El informe OSSRA 2025 señala que aproximadamente el 20% de los proyectos Java y JavaScript que estaban siendo mantenidos en años anteriores ya no reciben actualizaciones, exponiendo a los usuarios a vulnerabilidades sin parches disponibles.
Las señales de alerta incluyen: ausencia de commits o releases por más de dos años, vulnerabilidades conocidas sin planes de remediación, incompatibilidad con versiones modernas del lenguaje o framework, y dependencia de APIs deprecated. Cuando una biblioteca crítica presenta múltiples señales de alerta, las organizaciones deben evaluar seriamente la reescritura de la funcionalidad utilizando código propio o migrar a alternativas activamente mantenidas.
Las señales de alerta incluyen: ausencia de commits o releases por más de dos años, vulnerabilidades conocidas sin planes de remediación, incompatibilidad con versiones modernas del lenguaje o framework, y dependencia de APIs deprecated. Cuando una biblioteca crítica presenta múltiples señales de alerta, las organizaciones deben evaluar seriamente la reescritura de la funcionalidad utilizando código propio o migrar a alternativas activamente mantenidas.
4.2 Análisis costo-beneficio de la reescritura
La decisión de reescribir funcionalidad debe basarse en un análisis costo-beneficio riguroso. Los factores a considerar incluyen: el costo de desarrollo de una solución propia versus el costo continuo de gestionar riesgos de seguridad, la complejidad de la funcionalidad a reemplazar, la disponibilidad de alternativas activamente mantenidas, y el impacto potencial en la operación del negocio en caso de un incidente de seguridad.
Para funcionalidades críticas del negocio, a menudo tiene sentido desarrollar soluciones internas que la organización pueda mantener y evolucionar de forma independiente. Para funcionalidades commoditizadas, migrar a alternativas bien mantenidas suele ser más eficiente. La clave está en evaluar cada caso individualmente, considerando tanto los costos inmediatos como el costo total de propiedad (TCO) a largo plazo.
5. Políticas de uso de librerías en equipos de desarrollo
5.1 Gobernanza de dependencias: estableciendo estándares
Una política efectiva de gestión de dependencias debe establecer criterios claros para la selección, aprobación y monitoreo de componentes de terceros. Esto incluye requisitos mínimos de madurez del proyecto (actividad de commits, tamaño de la comunidad, cobertura de pruebas), evaluación de licencias para asegurar compatibilidad legal, y criterios de seguridad como historial de vulnerabilidades y tiempo de respuesta ante incidentes.
Las organizaciones maduras implementan listas de componentes aprobados (allowlists) y restringidos (blocklists). Los componentes que han demostrado ser seguros y bien mantenidos se agregan a la allowlist, mientras que aquellos con problemas conocidos de seguridad o mantenimiento se bloquean. Las herramientas de SCA pueden configurarse para hacer cumplir automáticamente estas políticas, bloqueando builds que incluyan componentes no aprobados.
5.2 Contexto regulatorio chileno: Ley Marco de Ciberseguridad
En Chile, la entrada en vigencia de la Ley Marco de Ciberseguridad (Ley 21.663) en marzo de 2025 establece nuevas obligaciones para las organizaciones en materia de gestión de riesgos cibernéticos. Según el Reporte de Ciberseguridad 2025 de Entel Digital, Chile concentra el 7% de los ataques en Latinoamérica, ubicándose cuarto en frecuencia. El ransomware lidera las amenazas con un 38% de incidencia, afectando sectores críticos como infraestructura, banca y agricultura.
Esta realidad regulatoria hace que la gestión de dependencias sea no solo una buena práctica de desarrollo, sino una obligación de cumplimiento. Las organizaciones chilenas deben implementar sistemas de gestión de seguridad de la información que incluyan la identificación y gestión de riesgos asociados a componentes de terceros. El incumplimiento puede resultar en multas significativas y, más importante aún, en daños reputacionales y operacionales derivados de incidentes de seguridad.
Conclusión
La gestión de dependencias ha evolucionado de ser una tarea técnica secundaria a convertirse en un componente crítico de la estrategia de seguridad empresarial. Con el 97% de las aplicaciones comerciales conteniendo componentes de código abierto y un crecimiento del 156% en paquetes maliciosos detectados, las organizaciones ya no pueden darse el lujo de ignorar este riesgo invisible.
Para las empresas chilenas, el contexto regulatorio actual añade urgencia a la implementación de prácticas robustas de gestión de dependencias. La combinación de herramientas SCA, políticas de gobernanza claras, estrategias proactivas de actualización y análisis rigurosos de decisiones de reescritura versus mantenimiento, permite a las organizaciones gestionar efectivamente estos riesgos mientras mantienen la velocidad de desarrollo que el mercado demanda.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft, nuestras células de desarrollo implementan las mejores prácticas de gestión de dependencias como parte integral de cada proyecto. Nuestros equipos utilizan herramientas de Software Composition Analysis para identificar y gestionar vulnerabilidades en componentes de terceros, generan y mantienen SBOMs actualizados, y siguen políticas estrictas de evaluación y actualización de dependencias.
Además, ofrecemos servicios de auditoría de seguridad de código que incluyen evaluación completa de dependencias, identificación de vulnerabilidades conocidas y recomendaciones priorizadas de remediación. Nuestro enfoque combina automatización con expertise humano para asegurar que tu software esté construido sobre cimientos seguros, cumpliendo con los requisitos de la Ley Marco de Ciberseguridad chilena.
Contáctanos para una conversación sobre cómo podemos asesorarte y disminuir tus riesgos.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Black Duck. (2025). Open Source Security and Risk Analysis (OSSRA) Report 2025. https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html
- Sonatype. (2024). 10th Annual State of the Software Supply Chain Report. https://www.sonatype.com/state-of-the-software-supply-chain/introduction
- Arctic Wolf. (2023). A Log4Shell Retrospective. https://arcticwolf.com/resources/blog/log4j-retrospective/
- CISA. (2024). Software Bill of Materials (SBOM) Resources. https://www.cisa.gov/sbom
- Red Hat Developer. (2025). Log4Shell: The vulnerability that shook the world of software development.
https://developers.redhat.com/articles/2024/10/23/log4shell-vulnerability-shook-world-software-development - Entel Digital. (2025). Reporte de Ciberseguridad 2025.
https://enteldigital.cl/reporte-ciberseguridad - Universidad de Chile FCFM. (2025). Chile ante una nueva era en ciberseguridad y protección de datos. https://ingenieria.uchile.cl/noticias/228298/chile-ante-una-nueva-era-en-ciberseguridad-y-proteccion-de-datos
- Entel Digital. (2025). Cibercrimen en 2025: Amenazas en aumento y estrategias para proteger tu empresa.
https://enteldigital.cl/blog/cibercrimen-2025-amenazas-y-proteccion