Plantilla de Triage de Dependency Vulnerabilities

Overview

Esta plantilla provee un structured approach para triagear dependency vulnerabilities por severity e impact. Cubre vulnerability scoring, exploitability assessment, blast radius analysis, fix prioritization, patch testing y deployment procedures. Usa esta plantilla cuando un new CVE se reporta en un dependency que tu application usa.

---

1. Vulnerability Intake

1.1 Triage Record Template

Field                | Value
─────────────────────┼──────────────────────────────────────────
CVE ID               | CVE-2026-12345
Package              | org.apache.commons:commons-text
Affected versions    | < 1.10.0
Fixed version        | 1.10.0
CVSS score           | 9.8 (Critical)
CVSS vector          | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE                  | CWE-20 (Improper Input Validation)
Published            | 2026-06-15
Discovered in project| 2026-06-20
Reporter             | Snyk automated scan
Triage owner         | security-team
Status               | Open

1.2 Severity Classification

CVSS score | Severity  | SLA para fix  | Escalation
───────────┼───────────┼───────────────┼──────────────────────────
9.0 - 10.0 | Critical  | 24 hours      | Page on-call security
7.0 - 8.9  | High      | 7 days        | Notifica security team
4.0 - 6.9  | Medium    | 30 days       | Trackea en sprint backlog
0.1 - 3.9  | Low       | 90 days       | Trackea en backlog
0.0        | None      | No action     | Cierra ticket

---

2. Exploitability Assessment

2.1 Exploitability Checklist

- [ ] El vulnerable code path es reachable desde user input?
- [ ] La vulnerable function se called en production code?
- [ ] La vulnerable function se called solo en test/dev code?
- [ ] La vulnerability requiree authentication para exploit?
- [ ] La vulnerability requiree network access?
- [ ] Hay un public exploit available (PoC, Metasploit)?
- [ ] La vulnerability esta siendo actively exploited en the wild?
- [ ] La vulnerability requiree specific configuration para trigger?
- [ ] El vulnerable feature esta enabled en nuestro deployment?
- [ ] Hay compensating controls (WAF, network isolation)?

2.2 Exploitability Scoring

Factor                    | Weight | Score (0-2)
──────────────────────────┼──────────────────────────────────
Public exploit available  | 3      | 0=No, 1=Theoretical, 2=Active
Reachable from user input | 2      | 0=No, 1=Indirect, 2=Direct
No auth required          | 2      | 0=Auth required, 1=Low priv, 2=No auth
Network accessible        | 1      | 0=Internal only, 1=DMZ, 2=Internet
No compensating controls  | 1      | 0=Controls exist, 1=Partial, 2=None
                          |        |
Max score                 | 14     | >10 = Exploitable, 5-9 = Possible, <5 = Unlikely

---

3. Blast Radius Analysis

3.1 Impact Assessment

Impact area             | Assessment
────────────────────────┼──────────────────────────────────────────
Affected services       | Lista all services usando el vulnerable package
Affected environments   | prod, staging, dev — cuales estan impacted?
Data exposure           | Puede la vulnerability leakear sensitive data?
Data integrity          | Puede la vulnerability modificar data?
Availability            | Puede la vulnerability causar downtime?
Privilege escalation    | Puede la vulnerability granter attacker elevated access?
Lateral movement        | Puede la vulnerability ser usada para acceder other systems?
Compliance impact       | Esto viola PCI-DSS, HIPAA, SOC2, GDPR?

3.2 Dependency Tree Analysis

# Maven — find dependency tree
mvn dependency:tree | grep commons-text

# Gradle
gradle dependencies | grep commons-text

# npm
npm ls commons-text

# Python pip
pip show commons-text

# Go
go mod why github.com/apache/commons-text

3.3 Service Inventory

Service           | Version    | Environment | Exposure      | Priority
──────────────────┼────────────┼─────────────┼───────────────┼──────────
payment-api       | 1.2.3      | prod        | Internet      | P0
payment-api       | 1.2.3      | staging     | Internal      | P1
billing-worker    | 0.9.1      | prod        | Internal      | P1
admin-dashboard   | 2.0.0      | prod        | VPN only      | P2

---

4. Fix Prioritization

4.1 Decision Matrix

Exploitability | Impact   | Action                              | Timeline
───────────────┼──────────┼─────────────────────────────────────┼──────────
Exploitable    | Critical | Patchea immediately, deployea hotfix | < 24h
Exploitable    | High     | Patchea y deployea en emergency window| < 48h
Exploitable    | Medium   | Patchea en next sprint               | < 7 days
Exploitable    | Low      | Patchea en regular cycle             | < 30 days
Possible       | Critical | Patchea en emergency window          | < 48h
Possible       | High     | Patchea en next sprint               | < 7 days
Possible       | Medium   | Patchea en regular cycle             | < 30 days
Possible       | Low      | Patchea cuando convenient           | < 90 days
Unlikely       | Any      | Patchea en regular cycle             | Next release

4.2 Fix Options

Option              | Cuando usar                          | Risk
────────────────────┼──────────────────────────────────────┼──────────────────
Upgrade package     | Fixed version available, compatible  | Breaking changes
Downgrade package   | Vulnerability introduced en new ver  | Lost features
Patch in place      | No fixed version, custom patch       | Maintenance burden
Remove dependency   | Unused o replaceable dependency      | Refactoring effort
Mitigate with WAF   | No se puede patchear immediately     | Incomplete fix
Accept risk         | Low severity, not exploitable        | Documenta y monitora

---

5. Patch Testing

5.1 Testing Checklist

- [ ] Verifica que el fixed version addressea el CVE
- [ ] Checkea para breaking changes en el changelog
- [ ] Corre unit tests con el new dependency version
- [ ] Corre integration tests con el new dependency version
- [ ] Corre security tests (SAST, DAST) con el new version
- [ ] Verifica que no new vulnerabilities se introducidos por el upgrade
- [ ] Testea en staging environment antes de production
- [ ] Monitora application logs para errors despues de deployment
- [ ] Verifica que performance no este degradado
- [ ] Documenta el upgrade en el change management system

5.2 Automated Testing Pipeline

# GitHub Actions — dependency vulnerability patch pipeline
name: Security Patch Pipeline
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
      - 'pom.xml'
      - 'requirements.txt'

jobs:
  security-validation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Corre Snyk scan
        uses: snyk/actions/node@master
        with:
          command: test
          args: --severity-threshold=high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Corre OWASP Dependency-Check
        run: |
          wget https://github.com/jeremylong/DependencyCheck/releases/download/v8.4.0/dependency-check-8.4.0-release.zip
          unzip dependency-check-8.4.0-release.zip
          ./dependency-check/bin/dependency-check.sh --project "my-app" --scan . --failOnCVSS 7

      - name: Corre unit tests
        run: npm test

      - name: Corre integration tests
        run: npm run test:integration

      - name: Checkea para new vulnerabilities
        run: npx audit-ci --high

---

6. Deployment Procedures

6.1 Hotfix Deployment

1. Crea hotfix branch desde main
2. Upgradea vulnerable dependency a fixed version
3. Corre full test suite
4. Code review con security team (minimum 2 approvers)
5. Deployea a staging
6. Corre smoke tests en staging
7. Deployea a production (canary o blue-green)
8. Monitora error rates y logs por 1 hour
9. Verifica que vulnerability scan muestre no findings
10. Mergea hotfix branch a main
11. Documenta en change management system
12. Post-incident review si la vulnerability fue exploited

6.2 Scheduled Patch Deployment

1. Crea feature branch para dependency upgrades
2. Upgradea all vulnerable dependencies en batch
3. Corre full test suite
4. Code review con team
5. Deployea a staging
6. Corre regression tests en staging
7. Deployea a production en next release window
8. Monitora por 24 hours
9. Cierra vulnerability tickets
10. Updatea dependency inventory

---

7. Monitoring and Prevention

7.1 Continuous Scanning

# Dependabot configuration — .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    labels:
      - "security"
      - "dependencies"

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

7.2 Snyk Continuous Monitoring

# Snyk monitor — continuous tracking
snyk monitor --org=my-org --project=payment-api

# Snyk test — one-time scan
snyk test --severity-threshold=high --json > snyk-report.json

# Snyk open source fix
snyk fix --dry-run  # preview changes
snyk fix            # apply fixes

Preguntas Frecuentes

¿Cómo se si un CVE affecta mi application?

Corre un dependency scan con Snyk, Dependabot o OWASP Dependency-Check. Estos tools comparan tu dependency tree contra vulnerability databases (NVD, GitHub Advisory Database). Reportean cuales dependencies tienen known CVEs, las affected versions y las fixed versions. Reviewa los scan results y checkea si el vulnerable code path es actually reachable en tu application. Un CVE en un dependency que usas pero no llamas es lower risk que uno en un function que invocas con user input.

¿Qué hago si no hay fixed version available?

Si no fix existe, evalua workaround options: disablea el vulnerable feature si es optional, add input validation o sanitization para prevenir exploitation, configura un WAF rule para blockear exploit attempts, o isolata el vulnerable service en un restricted network segment. Si none de estos es feasible, documenta el accepted risk con business approval. Monitora para un fix release y subscribete a los security advisories del package. Si el dependency esta unmaintained, considera reemplazarlo con un alternative.

¿Deberia upgradear un dependency en production sin testing?

Nunca deployees un dependency upgrade directamente a production sin testing. Incluso patch-level upgrades pueden introducir breaking changes, regressions o new vulnerabilities. Siempre corre el full test suite, deployea a staging first y monitora para errors. Para critical vulnerabilities que requieren immediate action, usa un canary deployment — routea 5% del traffic al patched version, monitora por 15 minutes, luego roll out a 100% si no errors aparecen.

¿Cómo handleo transitive dependency vulnerabilities?

Transitive dependencies (dependencies de tus direct dependencies) son harder de fix porque no controlas sus versions. Options: upgradea el direct dependency a un version que use el fixed transitive dependency, overridea el transitive dependency version explicitamente (Maven dependencyManagement, npm overrides, pip constraints), o reemplaza el direct dependency con un alternative que no tenga el vulnerable transitive dependency. Usa npm audit --fix o snyk fix para automated remediation donde sea possible.

¿Cuál es la diferencia entre CVSS y EPSS?

CVSS (Common Vulnerability Scoring System) mide el severity de un vulnerability — que tan bad seria si exploited. EPSS (Exploit Prediction Scoring System) mide el likelihood de que un vulnerability sea exploited en los next 30 days. Un vulnerability puede tener un high CVSS score (severe si exploited) pero un low EPSS score (unlikely de ser exploited). Usa ambos juntos: prioriza vulnerabilities con high CVSS y high EPSS first. Un CVSS 9.8 con EPSS 0.01 es lower priority que un CVSS 7.5 con EPSS 0.95.

See Also

• Scan Python Packages for Known CVEs with pip-audit
• Vulnerability Management Template
• Complete Guide to OWASP Top 10 2025
• Security Best Practices Guide
• Scan Docker Images for CVEs with Trivy and Grype