Dependency Vulnerability Triage Template

Overview

This template provides a structured approach for triaging dependency vulnerabilities by severity and impact. It covers vulnerability scoring, exploitability assessment, blast radius analysis, fix prioritization, patch testing, and deployment procedures. Use this template when a new CVE is reported in a dependency your application uses.

---

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 to fix    | Escalation
───────────┼───────────┼───────────────┼──────────────────────────
9.0 - 10.0 | Critical  | 24 hours      | Page on-call security
7.0 - 8.9  | High      | 7 days        | Notify security team
4.0 - 6.9  | Medium    | 30 days       | Track in sprint backlog
0.1 - 3.9  | Low       | 90 days       | Track in backlog
0.0        | None      | No action     | Close ticket

---

2. Exploitability Assessment

2.1 Exploitability Checklist

- [ ] Is the vulnerable code path reachable from user input?
- [ ] Is the vulnerable function called in production code?
- [ ] Is the vulnerable function called in test/dev code only?
- [ ] Does the vulnerability require authentication to exploit?
- [ ] Does the vulnerability require network access?
- [ ] Is there a public exploit available (PoC, Metasploit)?
- [ ] Is the vulnerability being actively exploited in the wild?
- [ ] Does the vulnerability require specific configuration to trigger?
- [ ] Is the vulnerable feature enabled in our deployment?
- [ ] Are there 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       | List all services using the vulnerable package
Affected environments   | prod, staging, dev — which are impacted?
Data exposure           | Can the vulnerability leak sensitive data?
Data integrity          | Can the vulnerability modify data?
Availability            | Can the vulnerability cause downtime?
Privilege escalation    | Can the vulnerability grant attacker elevated access?
Lateral movement        | Can the vulnerability be used to access other systems?
Compliance impact       | Does this violate 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 | Patch immediately, deploy hotfix    | < 24h
Exploitable    | High     | Patch and deploy in emergency window| < 48h
Exploitable    | Medium   | Patch in next sprint                | < 7 days
Exploitable    | Low      | Patch in regular cycle              | < 30 days
Possible       | Critical | Patch in emergency window           | < 48h
Possible       | High     | Patch in next sprint                | < 7 days
Possible       | Medium   | Patch in regular cycle              | < 30 days
Possible       | Low      | Patch when convenient               | < 90 days
Unlikely       | Any      | Patch in regular cycle              | Next release

4.2 Fix Options

Option              | When to use                          | Risk
────────────────────┼──────────────────────────────────────┼──────────────────
Upgrade package     | Fixed version available, compatible  | Breaking changes
Downgrade package   | Vulnerability introduced in new ver  | Lost features
Patch in place      | No fixed version, custom patch       | Maintenance burden
Remove dependency   | Unused or replaceable dependency     | Refactoring effort
Mitigate with WAF   | Cannot patch immediately             | Incomplete fix
Accept risk         | Low severity, not exploitable        | Document and monitor

---

5. Patch Testing

5.1 Testing Checklist

- [ ] Verify the fixed version addresses the CVE
- [ ] Check for breaking changes in the changelog
- [ ] Run unit tests with the new dependency version
- [ ] Run integration tests with the new dependency version
- [ ] Run security tests (SAST, DAST) with the new version
- [ ] Verify no new vulnerabilities introduced by the upgrade
- [ ] Test in staging environment before production
- [ ] Monitor application logs for errors after deployment
- [ ] Verify performance is not degraded
- [ ] Document the upgrade in the 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: Run Snyk scan
        uses: snyk/actions/node@master
        with:
          command: test
          args: --severity-threshold=high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Run 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: Run unit tests
        run: npm test

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

      - name: Check for new vulnerabilities
        run: npx audit-ci --high

---

6. Deployment Procedures

6.1 Hotfix Deployment

1. Create hotfix branch from main
2. Upgrade vulnerable dependency to fixed version
3. Run full test suite
4. Code review with security team (minimum 2 approvers)
5. Deploy to staging
6. Run smoke tests in staging
7. Deploy to production (canary or blue-green)
8. Monitor error rates and logs for 1 hour
9. Verify vulnerability scan shows no findings
10. Merge hotfix branch to main
11. Document in change management system
12. Post-incident review if vulnerability was exploited

6.2 Scheduled Patch Deployment

1. Create feature branch for dependency upgrades
2. Upgrade all vulnerable dependencies in batch
3. Run full test suite
4. Code review with team
5. Deploy to staging
6. Run regression tests in staging
7. Deploy to production in next release window
8. Monitor for 24 hours
9. Close vulnerability tickets
10. Update 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

FAQ

How do I know if a CVE affects my application?

Run a dependency scan with Snyk, Dependabot, or OWASP Dependency-Check. These tools compare your dependency tree against vulnerability databases (NVD, GitHub Advisory Database). They report which dependencies have known CVEs, the affected versions, and the fixed versions. Review the scan results and check whether the vulnerable code path is actually reachable in your application. A CVE in a dependency you use but don’t call is lower risk than one in a function you invoke on user input.

What if there is no fixed version available?

If no fix exists, evaluate workaround options: disable the vulnerable feature if it’s optional, add input validation or sanitization to prevent exploitation, configure a WAF rule to block exploit attempts, or isolate the vulnerable service in a restricted network segment. If none of these are feasible, document the accepted risk with business approval. Monitor for a fix release and subscribe to the package’s security advisories. If the dependency is unmaintained, consider replacing it with an alternative.

Should I upgrade a dependency in production without testing?

Never deploy a dependency upgrade directly to production without testing. Even patch-level upgrades can introduce breaking changes, regressions, or new vulnerabilities. Always run the full test suite, deploy to staging first, and monitor for errors. For critical vulnerabilities requiring immediate action, use a canary deployment — route 5% of traffic to the patched version, monitor for 15 minutes, then roll out to 100% if no errors appear.

How do I handle transitive dependency vulnerabilities?

Transitive dependencies (dependencies of your direct dependencies) are harder to fix because you don’t control their versions. Options: upgrade the direct dependency to a version that uses the fixed transitive dependency, override the transitive dependency version explicitly (Maven dependencyManagement, npm overrides, pip constraints), or replace the direct dependency with an alternative that doesn’t have the vulnerable transitive dependency. Use npm audit --fix or snyk fix for automated remediation where possible.

What is the difference between CVSS and EPSS?

CVSS (Common Vulnerability Scoring System) measures the severity of a vulnerability — how bad it would be if exploited. EPSS (Exploit Prediction Scoring System) measures the likelihood that a vulnerability will be exploited in the next 30 days. A vulnerability can have a high CVSS score (severe if exploited) but a low EPSS score (unlikely to be exploited). Use both together: prioritize vulnerabilities with high CVSS and high EPSS first. A CVSS 9.8 with EPSS 0.01 is lower priority than a CVSS 7.5 with 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