Plantilla de Auditoría de Dependencias de Terceros

Usa esta plantilla para evaluar librerías antes de agregarlas o durante auditorías periódicas. Consulta la Guía de Seguridad de Aplicaciones Web para prácticas de seguridad más amplias.

Resumen

Cada dependencia de terceros es un pasivo de seguridad y mantenimiento. Las dependencias vienen con sus propios bugs, vulnerabilidades y restricciones de licenciamiento. Sin un proceso de auditoría estructurado, los equipos acumulan librerías que no están mantenidas, son vulnerables o son legalmente incompatibles con su producto.

No es hipotético. La eliminación de left-pad en 2016 rompió miles de builds porque una utilidad de 11 líneas desapareció de npm. En 2018, el paquete event-stream pasó a manos de un mantenedor nuevo que distribuyó código robador de bitcoins a millones de descargas. Y Log4Shell en 2021 mostró cómo una sola dependencia transitiva puede convertirse en un incidente a nivel empresa de la noche a la mañana. Una auditoría no predice el próximo incidente, pero sí responde las preguntas que importan cuando llega: qué ejecutamos, quién lo mantiene y con qué rapidez podemos reemplazarlo.

Esta plantilla cubre:

1. Seguridad — CVEs conocidos, cobertura SAST, firma de releases
2. Salud de mantenimiento — cadencia de releases, cantidad de contribuidores, bus factor
3. Riesgo de supply chain — dependencias transitivas, código nativo, respaldo corporativo
4. Cumplimiento de licencias — identificadores SPDX, detección de copyleft
5. Decisión — aprobado, aprobado con monitoreo, o rechazado

Plantilla

# Auditoría de Dependencia: [Nombre de Librería]

## Resumen
| Campo | Valor |
|-------|-------|
| **Librería** | [nombre] v[x.y.z] |
| **Propósito** | [qué problema resuelve] |
| **Reemplaza** | [código interno / otra librería] |
| **Auditor** | [nombre] |
| **Fecha** | [AAAA-MM-DD] |

## Seguridad

| Check | Resultado | Evidencia |
|-------|-----------|----------|
| CVEs conocidos | [ninguno / lista] | Enlace a reporte Snyk / OSV |
| SAST disponible | [sí / no] | Enlace a auditoría de seguridad |
| Programa de bug bounty | [sí / no] | Enlace |
| Releases firmados | [sí / no] | Verificación GPG / Sigstore |

## Salud de Mantenimiento

| Métrica | Valor | Umbral |
|---------|-------|--------|
| Último release | [fecha] | < 12 meses |
| Issues abiertos | [cantidad] | < 500 |
| PRs abiertos | [cantidad] | < 100 |
| Contribuidores | [cantidad] | > 2 (bus factor) |
| Licencia | [identificador SPDX] | [lista aprobada] |

## Riesgo de Supply Chain

| Check | Resultado |
|-------|-----------|
| Descargas | [stats npm / PyPI] |
| Respaldo corporativo | [sí / no — quién] |
| Dependencias transitivas | [cantidad] |
| Código nativo / binarios compilados | [sí / no] |

## Decisión

| Resultado | Condiciones |
|-----------|-------------|
| **Aprobado** | Todos los checks pasan |
| **Aprobado con monitoreo** | Riesgos menores, seguimiento trimestral |
| **Rechazado** | Riesgo crítico, buscar alternativa |

Ejemplo Completo

El ejemplo siguiente usa datos ilustrativos — obtén siempre las cifras reales de las fuentes listadas en “Cómo ejecutar la auditoría” antes de firmar una decisión.

# Auditoría de Dependencia: fast-json-stringify v3.2.0

## Resumen
| Campo | Valor |
|-------|-------|
| **Librería** | fast-json-stringify v3.2.0 |
| **Propósito** | Serialización JSON 2x más rápida para respuestas de API |
| **Reemplaza** | JSON.stringify() en rutas críticas |
| **Auditor** | Jane Doe |
| **Fecha** | 2026-07-15 |

## Seguridad

| Check | Resultado | Evidencia |
|-------|-----------|----------|
| CVEs conocidos | Ninguno | Reporte Snyk 2026-07-15 |
| SAST disponible | Sí | Workflow CodeQL en el repo |
| Programa de bug bounty | No | N/A |
| Releases firmados | Sí | Provenance Sigstore |

## Salud de Mantenimiento

| Métrica | Valor | Umbral |
|---------|-------|--------|
| Último release | 2026-06-20 | < 12 meses PASS |
| Issues abiertos | 34 | < 500 PASS |
| PRs abiertos | 5 | < 100 PASS |
| Contribuidores | 18 | > 2 PASS |
| Licencia | MIT | Lista aprobada PASS |

## Riesgo de Supply Chain

| Check | Resultado |
|-------|-----------|
| Descargas | 12M/semana (npm) |
| Respaldo corporativo | Sí — NearForm |
| Dependencias transitivas | 3 |
| Código nativo / binarios compilados | No |

## Decisión

| Resultado | Condiciones |
|-----------|-------------|
| **Aprobado** | Todos los checks pasan. Revisar en la próxima auditoría trimestral. |

Cuándo Usar

• Antes de agregar una nueva dependencia — audita antes de instalar, no después
• Revisión trimestral de dependencias — programa auditorías recurrentes para todas las dependencias
• Después de un incidente de seguridad — audita todas las dependencias del ecosistema afectado
• Antes de un release — verifica que no se introdujeron nuevas vulnerabilidades
• Durante due diligence — audita dependencias antes de adquirir o fusionar con otra empresa
• Cuando una dependencia es deprecada — audita alternativas antes de migrar
• Al heredar un codebase — un servicio nuevo, una adquisición o un traspaso empiezan con la misma pregunta: qué hay en el lockfile y si algo ya es un problema

Cómo ejecutar la auditoría

La plantilla es un registro, no un proceso — las cifras que contiene salen de un puñado de herramientas que puedes ejecutar en menos de una hora por librería.

1. Obtén el reporte de vulnerabilidades. Ejecuta npm audit --package <nombre> o pip-audit para Python, y luego cruza el resultado en osv.dev — OSV agrega GitHub Advisories, NVD y bases de datos específicas de cada ecosistema, así que detecta cosas que npm audit no ve. Registra la lista de CVEs (o “ninguno”) con el enlace.
2. Revisa la salud de mantenimiento. La fuente única más rápida es deps.dev — muestra cadencia de releases, issues abiertos y cantidad de dependencias por versión. Complétalo con OpenSSF Scorecard (scorecard --repo=github.com/org/lib), que evalúa branch protection, releases firmados y tests en CI como un porcentaje.
3. Verifica la licencia. El identificador SPDX de la página del registro es el principio, no el final — revisa el archivo LICENSE del repo y ejecuta license-checker (npm) o pip-licenses para detectar licencias transitivas que no coincidan con la declaración de nivel superior.
4. Mide la huella. npm ls <nombre> o bundlephobia.com muestran el tamaño del árbol transitivo. En bundles de frontend esto sirve también como auditoría de tamaño.
5. Rellena la fila de decisión. Aprobado / aprobado con monitoreo / rechazado, con la condición escrita como una frase sobre la que un lector futuro pueda actuar — “Aprobado con monitoreo: un solo mantenedor, re-auditar en Q3” es mejor que un check pelado.

Una primera auditoría de una librería conocida lleva 20-30 minutos. Reserva más tiempo para paquetes poco conocidos — pocas descargas significan que no puedes apoyarte en el escrutinio de la comunidad, así que lee el código real de cualquier cosa que toque credenciales, red o sistema de archivos.

Calibrando los umbrales

Los números de la plantilla son puntos de partida para un servicio de producción típico, no constantes universales. Ajústalos según dónde vaya a vivir la librería:

Contexto	Último release	Contribuidores	Deps. transitivas	Notas
Ruta de auth/pagos/datos	< 6 meses	> 5	< 20	Exigir releases firmados
API pública	< 12 meses	> 2	< 50	Umbrales estándar
Herramientas internas	< 24 meses	> 1	< 100	Tolerar cadencia más lenta
Dependencia solo-dev	< 24 meses	cualquiera	< 100	Las vulnerabilidades siguen importando — CI es un objetivo

Dos reglas se mantienen independientemente del contexto: una librería de un solo mantenedor en una ruta crítica es como mucho “aprobada con monitoreo”, y una licencia copyleft (GPL/AGPL) siempre pasa por revisión legal por sano que parezca el proyecto.

Ciclo de vida

Fase 1: Auditoría pre-adopción

Ejecuta la auditoría completa antes de agregar la dependencia. Verifica seguridad, salud de mantenimiento, riesgo de supply chain y cumplimiento de licencias. Documenta la decisión en un ADR si la dependencia es crítica.

Fase 2: Monitoreo continuo

Configura alertas automatizadas para nuevas vulnerabilidades. Dependabot, Snyk o GitHub security advisories te notifican cuando se publica un CVE para una dependencia que usas.

Fase 3: Revisión trimestral

Re-audita todas las dependencias trimestralmente. Verifica si los mantenedores siguen activos, si la librería sigue siendo la mejor opción y si nuevas alternativas ofrecen mejor seguridad o rendimiento.

Fase 4: Deprecación y reemplazo

Cuando una dependencia es deprecada o surge una mejor alternativa, planifica la migración. Audita el reemplazo, crea un plan de migración y elimina la dependencia vieja del codebase.

Cuando una dependencia es rechazada

Un rechazo solo es útil si produce un siguiente paso — si no, la misma librería se volverá a proponer en seis meses. Para cada dependencia rechazada, registra:

• Por qué falló — el check concreto (CVE sin parche, licencia GPL, sin mantenimiento desde 2023), no solo “riesgo de seguridad”.
• La alternativa aprobada — la librería que pasó la misma auditoría, o “construirla internamente” con una estimación de tamaño.
• Si ya está en el codebase — si la librería entró antes de que existiera la auditoría, el rechazo implica abrir un ticket de eliminación con responsable y fecha, no solo una nota en un documento.

Guarda las auditorías rechazadas junto a las aprobadas. Son la memoria institucional que evita repetir la misma evaluación en cada ciclo de planificación — y durante una due diligence, un rechazo documentado se lee mejor que una omisión sin documentar.

El tercer resultado merece la misma disciplina: “aprobado con monitoreo” no es una aprobación débil, es un compromiso de revisar en una fecha. Escribe la condición de monitoreo en la fila de decisión (qué dispara la re-auditoría, quién es responsable, cuándo), pon la fecha en el calendario de revisión de dependencias y trata una re-auditoría perdida igual que tratarías la revisión perdida de cualquier otro control.

Señales de alerta

Señal	Acción
Sin release en 2+ años	Buscar alternativa activamente mantenida
Un solo mantenedor	Alto riesgo de bus factor; considerar fork o reemplazo
Licencia copyleft (GPL)	Revisión legal requerida para uso comercial
Binarios nativos sin builds reproducibles	Riesgo de ataque de supply chain
> 100 dependencias transitivas	Cada una es una nueva superficie de ataque

Automatización

Dependabot (GitHub)

Configura dependabot.yml para escanear vulnerabilidades y abrir PRs automáticamente:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Snyk

Ejecuta snyk test en CI para fallar builds en vulnerabilidades de alta severidad. Usa snyk monitor para seguir nuevas vulnerabilidades a lo largo del tiempo — hace una foto del árbol de dependencias, así que un CVE publicado contra una versión ya desplegada igual dispara una alerta. snyk test --severity-threshold=high evita que los checks de PR se ahoguen en ruido de baja severidad.

OWASP Dependency-Check

Scanner self-hosted que verifica dependencias contra la base de datos NVD. Se integra con Maven, Gradle y Jenkins.

Renovate Bot

Alternativa a Dependabot con más opciones de configuración: updates agrupados, reglas de auto-merge y soporte multi-ecosystem. Las packageRules de Renovate pueden auto-fusionar updates de nivel patch tras pasar CI mientras retienen los majors para revisión manual — un punto medio razonable entre ahogarse en PRs y quedarse un año atrás.

OpenSSF Scorecard en CI

Scorecard también corre como GitHub Action sobre tu propio repo — evalúa la higiene de tu proyecto (branch protection, actions pineadas, permisos de tokens) en lugar de tus dependencias. Combínalo con osv-scanner para un escaneo del lockfile que no depende de un gestor de paquetes concreto.

Problemas comunes de la propia auditoría

El proceso de auditoría tiene sus propios modos de fallo que conviene planificar:

• Ruido de npm audit. La mayoría de las vulnerabilidades reportadas viven en dependencias dev o en rutas de código que nunca ejecutas. Triagia por alcanzabilidad — un CVE de prototype-pollution en una herramienta de build que nunca llega al bundle tiene menos prioridad que un bug de header-injection en tu cliente HTTP, aunque ambos reporten “high”. Documenta la decisión de triaje en la auditoría para que el siguiente revisor no la repita.
• Vulnerabilidades transitivas sin arreglo. A veces la dependencia directa está sana pero empaqueta una versión vulnerable de otra cosa, y ningún override lo arregla sin romper la API. Opciones, en orden: overrides/resolutions/constraints para forzar una versión parcheada, un fix con patch-package, o reemplazar la dependencia directa. Si nada funciona, es un “rechazado” legítimo con los bloqueos concretos por escrito.
• Conflictos de peer dependencies. Una librería que exige react@^17 cuando estás en 18 bloquea upgrades limpios. Comprueba si la restricción es real (la librería usa APIs eliminadas) o solo un rango de peerDependencies desactualizado — lo segundo es común y suele resolverse con un PR upstream o --legacy-peer-deps como parche documentado.
• Licencias escondidas en dependencias transitivas. El paquete de nivel superior dice MIT pero una dependencia transitiva trae GPL. license-checker --production (npm) o pip-licenses las detecta — ejecútalo sobre el árbol de producción, no sobre el de desarrollo.

Lo que funciona

• Audita antes de agregar — las auditorías retroactivas descubren problemas demasiado tarde
• Automatiza el escaneo — Dependabot, Snyk u OWASP Dependency-Check en CI. Consulta la Guía de CI/CD Pipeline para integrar los escaneos de seguridad.
• Fija versiones — los lockfiles previenen upgrades silenciosos a versiones comprometidas
• Revisa la compatibilidad de licencias — AGPL en un backend SaaS es un riesgo legal
• Sigue la deprecación — las librerías mueren lentamente; monitorea su salud trimestralmente
• Documenta la decisión — guarda los registros de auditoría junto a los ADRs en docs/audits/
• Configura alertas — suscríbete a los advisories de seguridad de las dependencias críticas

Errores Comunes

• Agregar dependencias para funcionalidad trivial — los incidentes tipo “left-pad” ocurren
• Ignorar las dependencias transitivas — el árbol de dependencias es tu superficie de ataque
• No actualizar después de la auditoría — un reporte limpio hoy no significa nada en 6 meses
• Confianza ciega en paquetes populares — la popularidad no equivale a seguridad
• No verificar la compatibilidad de licencias antes del release — el riesgo legal aparece en la due diligence
• Eliminar lockfiles para “simplificar” — pierdes builds reproducibles y el pin de versiones vulnerables
• Auditar solo las dependencias directas — npm audit reporta todo el árbol; una transitiva vulnerable a tres niveles de profundidad igual llega a producción
• Omitir las dependencias solo-dev — una herramienta de build comprometida corre en CI con tus secretos

Variantes

Auditoría de dependencias frontend

Para proyectos frontend, agrega checks para: impacto en el tamaño del bundle, tree-shakeability, riesgo de CSS injection y cumplimiento de accesibilidad. Herramientas: Bundlephobia, webpack-bundle-analyzer. El código expuesto al navegador tiene un modelo de amenaza distinto al del servidor — una dependencia frontend comprometida puede capturar campos de formulario directamente de la página, así que pondera “toca el DOM o la red” tanto como el conteo de CVEs al puntuar el riesgo.

Auditoría de imágenes container

Para imágenes Docker, escanea la imagen base y todos los paquetes instalados. Herramientas: Trivy, Grype, Snyk Container. Verifica usuario root, puertos expuestos y secretos en las capas. La receta de seguridad de contenedores cubre el lado del hardening de imágenes.

Auditoría de dependencias en monorepo

Para monorepos, audita las dependencias compartidas entre todos los paquetes. Usa lockfiles a nivel workspace (pnpm-lock.yaml, un poetry.lock en la raíz). Registra qué paquetes consumen cada dependencia para evaluar el radio de impacto — herramientas como nx graph o turbo pueden listar los paquetes afectados cuando una dependencia cambia, lo que convierte “¿quién usa esto?” de una sesión de grep en una consulta.

Ver también

• OSV — base de datos de vulnerabilidades de código abierto
• deps.dev — API de análisis de dependencias de Google
• OpenSSF Scorecard
• OWASP Dependency-Check
• Snyk Advisor