¿Sabés qué repos dependen de cuáles en tu organización?

Gestionar las dependencias entre repositorios GitLab en organizaciones con decenas o cientos de repos requiere una combinación de herramientas nativas — Dependency List, SBOM con CycloneDX y dependency scanning — junto con soluciones externas como Renovate. GitLab ofrece desde la versión 16.2 visibilidad a nivel grupo, y desde la 18.x integra atributos de seguridad que permiten priorizar vulnerabilidades por contexto de negocio.

En 30 segundos

GitLab Dependency List permite visualizar todas las dependencias de un proyecto o grupo, incluyendo versiones, vulnerabilidades conocidas y licencias, sin salir de la plataforma
El dependency scanning genera automáticamente un SBOM en formato CycloneDX que mapea el grafo completo de dependencias directas y transitivas
La estrategia monorepo centraliza dependencias pero escala peor en repos grandes; multirepo da autonomía a equipos pero complica el rastreo cruzado
Renovate se integra con GitLab para crear merge requests automáticos cuando hay actualizaciones disponibles, cubriendo más de 90 package managers
Combinar dependency scanning en CI/CD con políticas de aprobación permite bloquear merge requests que introduzcan dependencias vulnerables

GitLab es una plataforma DevOps basada en Git, desarrollada por GitLab Inc., que permite gestionar repositorios de código, integración continua, despliegue continuo y colaboración en el ciclo de vida completo del desarrollo de software. Fue creada en 2011 por Dmitriy Zaporozhets y Valery Sizov.

El problema de las dependencias en organizaciones con muchos repositorios

Cualquier organización que supere los 50 repositorios activos enfrenta el mismo problema: nadie tiene claro qué repo consume qué biblioteca, y mucho menos quién mantiene esas bibliotecas internas. Actualizás una dependencia compartida en un repo y tres pipelines se rompen en silencio. Peor todavía, descubrís que una vulnerabilidad crítica afecta a un paquete que usás en 12 proyectos, pero no tenés forma rápida de saber cuáles son.

El desafío no es solo técnico. Es organizacional. Equipos que trabajan en silos, lock files desactualizados, versiones pinneadas de hace dos años que nadie se anima a tocar. Sin visibilidad centralizada, cada actualización es una apuesta. Y cuando llega una auditoría de seguridad o cumplimiento, armar el inventario de dependencias a mano es una pesadilla que consume días.

GitLab atacó este problema con un enfoque progresivo: primero dependency scanning a nivel proyecto, después Dependency List a nivel grupo, y ahora un ecosistema completo que incluye SBOM, políticas de seguridad y atributos de contexto. La pregunta no es si necesitás rastrear dependencias, sino qué combinación de herramientas te da la visibilidad que tu organización necesita.

Dependency List de GitLab: visibilidad a nivel proyecto y grupo

La Dependency List es la herramienta nativa de GitLab para ver qué dependencias usa cada proyecto. Está disponible a nivel proyecto desde hace varias versiones, pero el salto real fue cuando se habilitó a nivel grupo en GitLab 16.2 (y alcanzó GA en 16.5). Eso significa que un líder técnico puede ver, desde un solo lugar, todas las dependencias de todos los repos de su grupo.

La lista muestra nombre del paquete, versión actual, vulnerabilidades conocidas asociadas y tipo de licencia. No es un dashboard sofisticado, pero resuelve la pregunta básica: “¿dónde estamos usando esta biblioteca?”. Para habilitarla, necesitás que el proyecto tenga dependency scanning o container scanning corriendo en la rama default. Sin eso, la lista queda vacía.

Ejemplo concreto: una empresa con 80 repos en GitLab descubre que la biblioteca log4j (o su equivalente en el ecosistema que usen) tiene una vulnerabilidad crítica. Sin Dependency List, alguien tiene que revisar manualmente cada package.json, requirements.txt o pom.xml. Con la lista a nivel grupo, filtrás por nombre de paquete y en segundos sabés qué 15 repos la usan y en qué versión. Esa diferencia puede ser de horas — o días — en la respuesta a un incidente.

Eso sí, la Dependency List tiene limitaciones. No muestra relaciones entre repos (es decir, si el repo A depende del paquete que genera el repo B). Para eso necesitás un SBOM más completo o herramientas externas.

SBOM con GitLab: generar el mapa completo de dependencias entre repositorios

Un Software Bill of Materials (SBOM) es el equivalente a la lista de ingredientes de un producto alimenticio, pero para software. Detalla cada componente, versión y origen de lo que tu aplicación usa. GitLab genera SBOMs automáticamente en formato CycloneDX cuando corrés dependency scanning.

El proceso tiene dos fases. Primero, la fase de detección: GitLab parsea los lock files del proyecto (package-lock.json, Gemfile.lock, poetry.lock, go.sum, etc.) y construye un grafo de dependencias que incluye tanto las directas como las transitivas. El resultado es un documento CycloneDX en formato JSON. Segundo, la fase de análisis: ese grafo se cruza contra bases de datos de vulnerabilidades para identificar componentes afectados.

Lo interesante es que podés exportar el SBOM tanto desde la UI de GitLab como vía API. Si tenés una herramienta de gestión de riesgos centralizada (como Dependency-Track), podés consumir esos SBOMs programáticamente y tener un dashboard unificado de toda tu organización. Según la guía oficial de GitLab sobre SBOMs, el formato CycloneDX fue elegido por su adopción en la industria y compatibilidad con herramientas de seguridad.

El caveat: el SBOM refleja el estado de la rama default en el momento del último pipeline exitoso. Si un equipo no mergea hace semanas, su SBOM queda desactualizado. No es un problema de la herramienta, sino de disciplina de equipo, pero vale tenerlo en cuenta. Si te interesa, podés leer más sobre el reciente ataque a Trivy en GitHub Actions.

Monorepo vs multirepo: cómo impacta en el rastreo de dependencias

La decisión entre monorepo y multirepo no es solo arquitectónica — tiene un impacto directo en lo fácil (o difícil) que resulta rastrear dependencias cruzadas. Según el análisis de ThoughtWorks, no hay una respuesta universal, pero cada enfoque tiene trade-offs claros.

En un monorepo, todas las dependencias están centralizadas. Si actualizás una biblioteca interna, ves inmediatamente qué se rompe porque todo está en el mismo árbol de código. Google, Meta y Twitter usan monorepos a escala masiva. El problema es que git se pone lento con repos de varios GB, los pipelines crecen en complejidad, y necesitás herramientas como Bazel o Nx para que la cosa funcione.

En multirepo, cada equipo tiene su espacio. Los permisos son granulares, los pipelines son independientes y la autonomía es alta. Pero rastrear dependencias cruzadas se vuelve un problema real. Si el repo “auth-library” actualiza su API, ¿quién se entera? Sin Dependency List o un bot como Renovate, nadie. Y ahí es donde empiezan las roturas en cascada.

Aspecto	Monorepo	Multirepo
Visibilidad de dependencias	Alta — todo en un lugar	Baja sin herramientas adicionales
Actualizaciones cruzadas	Inmediatas, un solo commit	Requiere MRs en cada repo afectado
Autonomía de equipos	Limitada — conflictos frecuentes	Alta — cada equipo decide su ritmo
Permisos y acceso	Requiere CODEOWNERS granular	Nativos por repo
Escalabilidad de git	Problemas con repos grandes (+5 GB)	Sin limitaciones prácticas
Tooling adicional requerido	Bazel, Nx, Turborepo	Renovate, Dependency-Track, SBOM
Ideal para	Equipos muy integrados, libs compartidas	Equipos autónomos, microservicios

dependencias entre repositorios gitlab diagrama explicativo

Mi opinión: para la mayoría de las organizaciones medianas en Latinoamérica, el multirepo con buenas herramientas de rastreo termina siendo más práctico que forzar un monorepo. El monorepo requiere una inversión fuerte en tooling que muchos equipos no tienen.

Herramientas complementarias: Renovate, Dependency-Track y Dependency Proxy

Renovate para actualizaciones automáticas

Renovate es la alternativa multiplataforma a Dependabot, y funciona nativamente con GitLab. Soporta más de 90 package managers — desde npm y pip hasta Helm charts y Dockerfile. Lo que hace es escanear tus repos, detectar dependencias desactualizadas y crear merge requests automáticos con la actualización.

La diferencia con Dependabot (que está atado a GitHub) es que Renovate te da un Dependency Dashboard como issue en cada repo, donde ves el estado de todas las actualizaciones pendientes. Podés configurar reglas por tipo de dependencia: auto-merge para patches, revisión manual para majors, agrupación de updates por equipo. Segundo ejemplo concreto: un equipo con 40 repos en GitLab configuró Renovate con auto-merge para dependencias de desarrollo y revisión obligatoria para dependencias de producción. En tres meses redujeron las dependencias desactualizadas de 340 a 12.

Dependency-Track para monitoreo continuo

Dependency-Track es una plataforma open source de OWASP que consume SBOMs (CycloneDX o SPDX) y te da un dashboard centralizado de todas las vulnerabilidades en tu stack. La idea es que GitLab genere los SBOMs y Dependency-Track los agregue y monitoree continuamente contra bases como NVD, OSV y GitHub Advisory Database.

No reemplaza a GitLab — lo complementa. GitLab te dice “este proyecto tiene vulnerabilidades”. Dependency-Track te dice “de los 120 proyectos de tu organización, estos 8 tienen vulnerabilidades críticas y estos 3 usan una licencia GPL que no aceptaste”.

GitLab Dependency Proxy

El Dependency Proxy de GitLab cachea paquetes de registries upstream (Docker Hub, Maven Central) para que tus pipelines no dependan de la disponibilidad de terceros. Está disponible en el tier Premium. No es estrictamente una herramienta de rastreo, pero resuelve un problema relacionado: si un paquete upstream desaparece o se compromete, tu proxy local sigue sirviendo la versión cacheada.

Pipeline CI/CD para auditoría automática de dependencias

La teoría está bien, pero lo que cierra el circuito es un pipeline que corra todo automáticamente. Acá va un ejemplo de .gitlab-ci.yml que integra dependency scanning con generación de SBOM:

include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml dependency_scanning: stage: test variables: DS_EXCLUDED_ANALYZERS: "retired-js" artifacts: reports: dependency_scanning: gl-dependency-scanning-report.json cyclonedx: gl-sbom-*.cdx.json Si te interesa, podés leer más sobre repositorios comprometidos con malware como GlassWorm.

Con esto, cada pipeline en la rama default genera un reporte de dependencias y un SBOM. Pero el paso clave es configurar security policies para que los merge requests con vulnerabilidades críticas requieran aprobación adicional. Desde GitLab 17.x podés usar criterios como KEV (Known Exploited Vulnerabilities) y EPSS (Exploit Prediction Scoring System) para filtrar solo las vulnerabilidades que realmente representan un riesgo activo, en lugar de bloquear todo por un CVE con score CVSS alto pero sin exploit conocido.

Si tu equipo necesita infraestructura para correr estos pipelines de forma confiable, Donweb ofrece servidores y VPS con el rendimiento necesario para runners de GitLab CI/CD en el mercado latinoamericano.

Estrategia para implementar el rastreo en una organización existente

Implementar todo esto de golpe es irreal. Lo que funciona es un enfoque progresivo en cinco pasos:

1. Auditar repos existentes. Antes de automatizar, necesitás saber qué tenés. Listá todos los repos activos, identificá cuáles tienen lock files actualizados y cuáles están abandonados. Un repo muerto con dependencias vulnerables sigue siendo un riesgo.

2. Habilitar dependency scanning en grupos. Empezá por los grupos con repos críticos (los que tocan datos de usuarios o procesan pagos). Usá el template oficial de GitLab y verificá que los reportes se generen correctamente. No intentes cubrir todo de una vez.

3. Generar SBOMs de baseline. Con el scanning activo, exportá los SBOMs iniciales. Ese es tu punto de partida. Vas a ver la cantidad de dependencias transitivas que no sabías que existían — y probablemente alguna sorpresa desagradable en forma de vulnerabilidad vieja.

4. Configurar Renovate para actualizaciones automáticas. Instalá Renovate como proyecto en tu instancia de GitLab (self-hosted o SaaS). Configurá las reglas de auto-merge y agrupación. Esto reduce la fricción de mantener dependencias al día.

5. Definir políticas de aprobación. Usá las security policies de GitLab para requerir revisión en MRs que introduzcan dependencias con vulnerabilidades. Si usás GitLab 18.x, aprovechá los security attributes para agregar contexto de negocio — no es lo mismo una vulnerabilidad en un servicio interno que en la API pública.

Errores comunes

Confiar solo en la Dependency List sin correr dependency scanning. La lista se alimenta de los reportes que genera el scanner. Si no tenés dependency scanning habilitado en la rama default, la lista va a estar vacía y vas a pensar que no tenés dependencias. Habilitá el scanning primero, siempre. Si te interesa, podés leer más sobre integrar herramientas de IA en tus proyectos.

Ignorar las dependencias transitivas. Muchos equipos revisan sus dependencias directas (lo que declaran en package.json o requirements.txt) pero ignoran las transitivas — las dependencias de las dependencias. El 80% de las vulnerabilidades en la práctica viene de dependencias transitivas. El SBOM de GitLab las incluye, pero si solo mirás el lock file a ojo, se te escapan.

Configurar Renovate y no revisar los merge requests. Renovate puede generar decenas de MRs por semana. Si nadie los revisa, se acumulan y el equipo empieza a ignorarlos. La solución es configurar auto-merge para updates menores y de desarrollo, y agrupar los updates mayores en un solo MR semanal para revisión manual. Sin esa configuración, Renovate genera más ruido que valor.

Pensar que el monorepo elimina el problema. El monorepo centraliza las dependencias externas, pero no elimina las dependencias internas entre módulos. Si tu monorepo tiene 15 paquetes internos, seguís necesitando herramientas (Nx, Bazel, Turborepo) para entender el grafo de dependencias internas y correr solo los tests afectados por un cambio.

Preguntas Frecuentes

¿Cómo puedo ver qué repositorios dependen de cuáles en GitLab?

Habilitá dependency scanning en cada proyecto y usá la Dependency List a nivel grupo para ver todas las dependencias de todos los repos en un solo lugar. Podés filtrar por nombre de paquete para identificar qué proyectos consumen una biblioteca específica. Para dependencias entre repos internos, necesitás complementar con un SBOM centralizado o Dependency-Track.

¿GitLab genera SBOM automáticamente?

Sí. Cuando corrés dependency scanning en un pipeline, GitLab genera automáticamente un SBOM en formato CycloneDX que incluye dependencias directas y transitivas. El archivo se guarda como artefacto del pipeline y podés descargarlo desde la UI o consumirlo vía API para alimentar herramientas externas.

¿Es mejor usar monorepo o multirepo para gestionar dependencias en una organización grande?

Depende de tu estructura de equipos. El monorepo simplifica la visibilidad de dependencias pero requiere tooling especializado (Bazel, Nx) y escala mal con repos muy grandes. El multirepo da más autonomía a los equipos pero necesita herramientas como Renovate y Dependency List de GitLab para mantener visibilidad. Para la mayoría de las organizaciones medianas, multirepo con buen tooling es más pragmático.

¿Cómo integrar Renovate con GitLab para actualizar dependencias automáticamente?

Creá un proyecto en tu instancia de GitLab que ejecute Renovate como job de CI/CD programado. Renovate escanea los repos configurados, detecta dependencias desactualizadas y abre merge requests con las actualizaciones. Podés definir reglas de auto-merge por tipo de update y agrupar actualizaciones para reducir el ruido.

Conclusión

Rastrear dependencias entre repositorios GitLab dejó de ser un problema sin solución. Con Dependency List a nivel grupo, SBOMs automáticos en CycloneDX y herramientas como Renovate, una organización con 100+ repos puede tener visibilidad real de su grafo de dependencias sin invertir meses en tooling interno.

Lo que cambió concretamente es que GitLab pasó de ofrecer visibilidad solo a nivel proyecto a dar una vista unificada por grupo, y las funcionalidades de seguridad (políticas de aprobación, filtros KEV/EPSS, security attributes) permiten priorizar lo que realmente importa en vez de ahogarse en alertas. Si todavía no habilitaste dependency scanning en tus repos, ese es el primer paso. Después, configurar Renovate para que las actualizaciones dejen de ser una tarea manual que nadie hace. La inversión inicial son unas horas de configuración de CI/CD; el retorno es no enterarte de una vulnerabilidad crítica por un mail de un auditor tres meses después.