Plantilla de Reporte de Vulnerabilidades en Dependencias

Descripcion General

Una Plantilla de Reporte de Vulnerabilidades en Dependencias captura hallazgos de seguridad provenientes de herramientas de Software Composition Analysis (SCA). Convierte la salida del escaneo en un documento util que desarrolladores, ingenieros de seguridad y product owners pueden usar para priorizar la remediacion.

Cuando Usar

• For alternatives, see Vulnerability Scan Report Template.

• Despues de un escaneo SCA programado en CI/CD.

• Cuando se publica un nuevo CVE en una libreria ampliamente usada.

• Antes de un release o auditoria de seguridad.

• Despues de agregar una nueva dependencia a un proyecto.

• Para reportar hallazgos a un programa de gestion de vulnerabilidades.

Prerequisitos

• Un escaneo SCA completado con una herramienta como Snyk, OWASP Dependency-Check o GitHub Advanced Security.
• Acceso al repositorio afectado y al manifesto de dependencias.
• Un framework de puntuacion de vulnerabilidades, como CVSS o tu propia matriz de riesgo.
• Un SLA de remediacion definido por severidad.

Solucion

Plantilla

1. Resumen del Hallazgo

Campo	Descripcion	Ejemplo
ID del reporte	Identificador unico	VULN-2026-0042
Fecha descubierta	Cuando se identifico el hallazgo	2026-06-27
Reportado por	Persona o herramienta que lo encontro	Snyk bot / Equipo de seguridad
Proyecto	Repositorio o servicio afectado	payment-service
Ambiente	Donde corre la dependencia	Produccion, CI, Dev

2. Detalles de la Vulnerabilidad

Campo	Descripcion	Ejemplo
ID CVE	Identificador de vulnerabilidad	CVE-2026-12345
Severidad	Puntuacion CVSS o severidad personalizada	Alta (8.1)
Paquete afectado	Libreria y ecosistema	log4j-core (Maven)
Version instalada	Version actual en el proyecto	2.14.0
Version parchada	Primera version corregida	2.17.1
Vector de ataque	Como se puede explotar la vulnerabilidad	Ejecucion remota de codigo via log message
Disponibilidad de exploit	Existe un exploit publico?	PoC publico disponible

3. Evaluacion de Impacto

Pregunta	Respuesta
La funcion vulnerable es alcanzable?	Si, via logging de requests
La dependencia esta expuesta a internet?	Si, servicio edge
La dependencia procesa input no confiable?	Si, contenido proporcionado por usuarios
Existe un control compensatorio?	WAF bloquea patrones maliciosos
Impacto de negocio estimado	Interrupcion del flujo de pagos

4. Plan de Remediacion

Paso	Responsable	Fecha Limite	Estado
Actualizar dependencia a 2.17.1	Equipo backend	2026-07-01	No iniciado
Ejecutar pruebas de regresion en staging	QA	2026-07-02	No iniciado
Desplegar en produccion	DevOps	2026-07-03	No iniciado
Verificar correccion via re-scan	Seguridad	2026-07-05	No iniciado

5. Aceptacion de Riesgo

Campo	Valor
Se puede aceptar el riesgo?	No
Justificacion	RCE publico con exploit publico
Dueno del riesgo	Engineering manager
Fecha de aprobacion	N/A
Fecha de revision	N/A

Explicacion

El reporte conecta los datos crudos del CVE con el proyecto especifico, contexto de ejecucion e impacto de negocio. Esto evita que los equipos traten todas las vulnerabilidades de igual manera y ayuda a priorizar aquellas que realmente son explotables en produccion.

Variantes

• Reporte ejecutivo: Version de una pagina con solo severidad, cantidad y tendencia de riesgo para liderazgo.
• Reporte de fallo en CI/CD: Captura por que se bloqueo un pipeline y rastrea los pasos para desbloquearlo.
• Reporte para mantenedores open source: Formateado para divulgacion upstream y publicacion de CVE.
• Reporte de tendencia historica: Agrega hallazgos a lo largo de meses para rastrear la mejora de la postura de seguridad.

Lo que funciona

• Manten un reporte por hallazgo o por par CVE/proyecto para evitar duplicados.
• Incluye siempre analisis de explotabilidad, no solo puntuacion CVSS.
• Asigna un dueno y fecha limite antes de cerrar el reporte.
• Linkea la salida del escaneo SCA, SBOM y pull request para trazabilidad.
• Re-escanea despues de la remediacion para verificar el fix.
• Revisa riesgos aceptados trimestralmente.

Errores Comunes

• Remediar solo por puntuacion CVSS sin considerar explotabilidad.
• Olvidar probar la dependencia actualizada en una carga real.
• Cerrar reportes antes de que un re-scan confirme la correccion.
• Ignorar dependencias transitivas porque el reporte solo lista directas.
• Aceptar riesgo sin documentar la justificacion de negocio.

Soluciones Avanzadas

Escaneo SCA automatizado en GitHub Actions

Integra Snyk y Trivy en un workflow de GitHub Actions para escanear dependencias en cada PR:

name: Dependency Security Scan
on:
  pull_request:
    paths:
      - "package.json"
      - "package-lock.json"
      - "requirements.txt"
      - "pom.xml"
  schedule:
    - cron: "0 6 * * 1"  # Escaneo semanal los lunes

jobs:
  sca-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --json > snyk-results.json

      - name: Run Trivy filesystem scan
        run: |
          trivy fs --format json --output trivy-results.json .
          trivy fs --format table --exit-code 1 --severity HIGH,CRITICAL .

      - name: Generate vulnerability report
        run: |
          node -e "
            const snyk = require('./snyk-results.json');
            const trivy = require('./trivy-results.json');
            const findings = [
              ...snyk.vulnerabilities.map(v => ({
                source: 'snyk', cve: v.identifiers.CVE?.[0] || 'N/A',
                package: v.name, severity: v.severity,
                fixedVersion: v.fixInfo?.[0]?.version || 'N/A'
              })),
              ...trivy.Results.flatMap(r => r.Vulnerabilities || []).map(v => ({
                source: 'trivy', cve: v.VulnerabilityID,
                package: v.PkgName, severity: v.Severity,
                fixedVersion: v.FixedVersion || 'N/A'
              }))
            ];
            console.log('| Source | CVE | Package | Severity | Fixed Version |');
            console.log('|--------|-----|---------|----------|---------------|');
            findings.forEach(f => {
              console.log('| ' + f.source + ' | ' + f.cve + ' | ' + f.package + ' | ' + f.severity + ' | ' + f.fixedVersion + ' |');
            });
          " > vulnerability-report.md

      - name: Upload report as artifact
        uses: actions/upload-artifact@v4
        with:
          name: vulnerability-report
          path: vulnerability-report.md

Generacion de SBOM con CycloneDX

Genera un Software Bill of Materials (SBOM) para rastrear todas las dependencias incluyendo las transitivas:

#!/bin/bash
set -euo pipefail

# Generate SBOM for Node.js project
npx @cyclonedx/cyclonedx-npm --output-format json --output-file sbom.json

# Generate SBOM for Python project
pip install cyclonedx-bom
cyclonedx-py requirements.txt --format json --output - > sbom-python.json

# Enrich SBOM with vulnerability data using Trivy
trivy sbom --format json --output sbom-enriched.json sbom.json

# Extract vulnerable packages from enriched SBOM
jq '.Results[] | select(.Class=="sbom") | .Vulnerabilities[] | {
  cve: .VulnerabilityID,
  package: .PkgName,
  severity: .Severity,
  fixed_version: .FixedVersion
}' sbom-enriched.json

Script de analisis de dependencias transitivas

Identifica que dependencias transitivas introducen vulnerabilidades en un proyecto Node.js:

#!/bin/bash
set -euo pipefail

echo "=== Direct vs Transitive Vulnerable Dependencies ==="
echo ""

# Get all vulnerable packages
npm audit --json > audit-output.json 2>/dev/null || true

# Extract vulnerable packages and their dependency paths
jq -r '.vulnerabilities | to_entries[] | {
  package: .key,
  severity: .value.severity,
  is_direct: (.value.isDirect | tostring),
  via: (.value.via | map(.name // .source | tostring) | join(", ")),
  fixAvailable: (.value.fixAvailable | tostring)
}' audit-output.json

echo ""
echo "=== Transitive dependency chains ==="
# Show the full path from direct dependency to vulnerable transitive
npm ls --all --json 2>/dev/null | \
  jq -r '
    def walk_deps($name):
      .. | objects | select(.name == $name) | path;
    .vulnerabilities // {} | keys[] as $pkg |
    "Vulnerable: \($pkg)"
  ' audit-output.json 2>/dev/null || true

Mejores Practicas Adicionales

1. Usa analisis de alcanzabilidad para reducir falsos positivos. Herramientas como Snyk Code y OWASP Dep-Check pueden determinar si la funcion vulnerable es realmente llamada en tu codigo. Suprime hallazgos de codigo inalcanzable con justificacion documentada:

# Snyk reachability analysis
snyk test --json --reachable-vulns | \
  jq '.vulnerabilities[] | {
    name: .name,
    reachable: .reachable,
    functions: .reachableFunctions
  }'

2. Configura comentarios automaticos en PRs para nuevas vulnerabilidades. Configura Dependabot o Snyk para comentar en PRs que introducen dependencias vulnerables, bloqueando el merge hasta que se revisen:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      - dependency-type: "all"
    labels:
      - "security"
      - "dependencies"
    open-pull-requests-limit: 10

Errores Comunes Adicionales

1. Ignorar dependencias de desarrollo en escaneos de vulnerabilidad. Las dependencias dev pueden ser explotadas en entornos CI o por PRs maliciosos. Escanea todas las dependencias, no solo las de produccion:

# Scan both production and dev dependencies
npm audit --production=false
snyk test --dev

2. No rastrear vulnerabilidades en imagenes base Docker. Los escaneos de dependencias de aplicacion no detectan paquetes a nivel SO en tu imagen base de contenedor. Escanea la imagen por separado:

# Scan Docker image for OS-level vulnerabilities
trivy image --severity HIGH,CRITICAL myapp:latest
grype myapp:latest --fail-on high