---

name: cve-dependency-management compatibility: opencode completeness: 95 content-types:

• code
• guidance
• do-dont
• examples description: '"Provides Cybersecurity operations skill for automating software dependency version updates based on CVE (Common Vulnerabilities and Exposures) data, vulnerabil"' license: MIT maturity: stable metadata: domain: coding output-format: code related-skills: security-review, semver-automation, dependency-supply-chain-security role: implementation scope: implementation triggers: CVE, dependency management, vulnerability scanning, dependency updates, security patching, SCA, software composition analysis, vulnerability remediation archetypes:
  • tactical
  • generation anti_triggers:
  • brainstorming
  • vague ideation
  • code golf
  • over-engineering response_profile: verbosity: low directive_strength: high abstraction_level: operational version: "1.0.0"

---

CVE-Based Dependency Management

Implementation guide for automating software dependency vulnerability scanning, version updates based on CVE data, and policy-driven patching using Software Composition Analysis (SCA) tools, CVE databases, and CI/CD automation.

TL;DR Checklist

• Enable automated vulnerability scanning for all dependencies (npm audit, Snyk, Dependabot)
• Integrate SCA tool in CI/CD pipeline (fail on critical/high vulnerabilities)
• Define patching policy (immediate for critical, weekly for medium/low)
• Set up automated pull requests for vulnerability updates
• Configure dependency version constraints (caret ^, tilde ~, or pinned =)
• Audit transitive dependencies (nested dependencies)
• Monitor CVE databases and maintain alert subscriptions

---

When to Use This Skill

Use CVE dependency management when:

• Running production services with external dependencies
• Managing open-source libraries with security requirements
• Compliance requirements (ISO 27001, SOC2, PCI-DSS)
• Responding to CVE disclosures affecting your dependencies
• Automating security updates in CI/CD pipelines
• Auditing supply chain for vulnerable components
• Maintaining SLA for security patching (e.g., 30 days for critical)

---

When NOT to Use This Skill

Avoid full automation when:

• Offline/air-gapped systems (no ability to update)
• Extensively modified forks of dependencies
• Legacy dependencies with no security updates available
• Internal-only tools with low risk exposure
• Development-only dependencies (less critical)
• Build tools and test dependencies (lower priority)

---

Vulnerability Severity Levels

CRITICAL (CVSS 9.0-10.0)
├─ Immediate exploitation possible
├─ Example: RCE in widely-used library
├─ SLA: Patch within 24-48 hours
└─ Action: Hotfix or temporary mitigation

HIGH (CVSS 7.0-8.9)
├─ Significant impact, exploitation difficult
├─ Example: SQL injection in database driver
├─ SLA: Patch within 1 week
└─ Action: Priority update

MEDIUM (CVSS 4.0-6.9)
├─ Moderate impact, specialized attack required
├─ Example: DoS in edge case
├─ SLA: Patch within 30 days
└─ Action: Regular scheduled update

LOW (CVSS 0.1-3.9)
├─ Minor impact or difficult exploitation
├─ Example: Information disclosure
├─ SLA: Patch within 90 days
└─ Action: Batch with other updates

---

Dependency Scanning Setup

Node.js (npm/yarn)

npm audit (Built-in)

# Scan for vulnerabilities
npm audit

# Output example:
# found 5 vulnerabilities (3 high, 2 medium)
#   5 packages audited in 1.234s
#
# High    SQL Injection in sqlite3
# High    RCE in node-fetch
# Medium  DoS in lodash

# Fix automatically (where possible)
npm audit fix

# Fix only for production dependencies
npm audit fix --production

# Generate JSON report
npm audit --json > audit-report.json

Snyk (Advanced)

# Install Snyk CLI
npm install -g snyk

# Authenticate with Snyk account
snyk auth

# Test project for vulnerabilities
snyk test

# Generate detailed report
snyk test --json > snyk-report.json

# Monitor continuously (tracks changes)
snyk monitor

# Fix vulnerabilities with Snyk
snyk fix

Python

Pip-audit

# Install pip-audit
pip install pip-audit

# Scan environment
pip-audit

# Generate JSON report
pip-audit --desc --format json > audit-report.json

# Fix vulnerabilities
pip-audit --fix

Safety

# Install Safety
pip install safety

# Check dependencies
safety check

# Generate JSON report
safety check --json > safety-report.json

# Database options
safety check --db /path/to/local/db.json

Go

Govulncheck

# Install govulncheck
go install golang.org/x/vuln/cmd/govulncheck@latest

# Check project
govulncheck ./...

# Check specific module
govulncheck github.com/some/module@v1.2.3

# Format as JSON
govulncheck -json ./...

---

Automated Scanning in CI/CD

GitHub Dependabot

# .github/dependabot.yml
version: 2
updates:
  # npm dependencies
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "03:00"
    pull-request-branch-name:
      separator: "/"
    reviewers:
      - "security-team"
    assignees:
      - "dependabot-owner"
    labels:
      - "dependencies"
      - "security"
    allow:
      - dependency-type: "direct"
      - dependency-type: "indirect"
    ignore:
      - dependency-name: "dev-only-package"
    open-pull-requests-limit: 10
    rebase-strategy: "auto"
    commit-message:
      prefix: "chore(deps):"

  # Python dependencies
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Snyk Integration

# .github/workflows/snyk-security.yml
name: Snyk Security Scan

on:
  schedule:
    - cron: '0 2 * * *'  # Daily at 2 AM UTC
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: snyk/actions/setup@master

      - uses: actions/setup-node@v3
        with:
          node-version: 18

      - run: npm ci

      - name: Snyk Test
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        run: snyk test --severity-threshold=high --fail-on=all

      - name: Snyk Monitor
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        run: snyk monitor

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: snyk.sarif

---

Vulnerability Response Workflow

Detection → Remediation

1. Vulnerability Detected
   ↓
2. Severity Assessment (CRITICAL/HIGH/MEDIUM/LOW)
   ↓
3. Impact Analysis
   ├─ Is package imported?
   ├─ Is vulnerable function used?
   ├─ Can we upgrade to fixed version?
   └─ What's the exploitation risk?
   ↓
4. Remediation Decision
   ├─ Upgrade to patched version
   ├─ Downgrade if newer version breaks
   ├─ Fork & patch if upstream unmaintained
   └─ Or accept risk if update not available
   ↓
5. Testing
   ├─ Unit tests pass
   ├─ Integration tests pass
   ├─ No breaking changes
   └─ Security fix verified
   ↓
6. Deployment & Monitoring
   ├─ Merge & deploy
   ├─ Monitor for regressions
   └─ Document incident

Example: CVE in Express.js

# 1. Vulnerability detected by npm audit
# Express 4.17.0-4.17.2 has DoS vulnerability

# 2. Check current version
npm list express
# express@4.17.1

# 3. Check fix version
npm view express@latest version
# 4.18.2 (has fix)

# 4. Assess impact
grep -r "res.locals" src/  # Are we using affected API?

# 5. Attempt upgrade
npm update express@latest

# 6. Run tests
npm test
npm run build

# 7. Deploy
git add package.json package-lock.json
git commit -m "chore(security): upgrade express to fix DoS CVE"
git push origin main

---

Version Constraint Strategies

Semantic Versioning Ranges

{
  "dependencies": {
    "express": "4.18.2",              // ✅ Exact (safest)
    "lodash": "^4.17.0",              // Caret: minor/patch updates (4.17.0 → 4.x.y)
    "react": "~18.2.0",               // Tilde: patch updates only (18.2.0 → 18.2.x)
    "axios": ">=1.4.0",               // Greater than (dangerous!)
    "mongoose": "*"                   // Any version (very dangerous!)
  }
}

Recommended Strategy

{
  "dependencies": {
    "critical-lib": "1.2.3",           // ❌ Never use * or >=
    "standard-lib": "^1.2.3",          // ✅ Allow minor updates
    "well-tested-lib": "~1.2.3"        // ✅ Allow patch updates only
  },
  "devDependencies": {
    "test-framework": "^3.0.0",        // Less critical, minor updates OK
    "build-tool": "^5.1.0"
  }
}

---

Dependency Lock Files

Lock File Purpose

package.json  → Declares ranges
    ↓
package-lock.json / yarn.lock  → Pins exact versions
    ↓
npm ci / yarn install (with lock)  → Reproducible installs

Best Practices

# ✅ Always commit lock files
git add package-lock.json
git commit -m "chore(deps): update lock file"

# ❌ NEVER do this
npm update            # Changes installed versions
npm install lodash    # Uses ^ by default (wide range)

# ✅ DO THIS instead
npm install --save lodash@4.17.21    # Pins exact version
npm ci                                # Use lock file exactly

---

Supply Chain Security

Transitive Dependency Audit

# Show dependency tree
npm list

# Output example:
# ├── express@4.18.2
# │   ├── body-parser@1.20.0
# │   │   └── bytes@3.1.0
# │   └── cors@2.8.5
# └── react@18.2.0

# Check for vulnerabilities in nested deps
npm audit --all

# Audit transitive dependencies only
npm list --depth=10 | grep "vulnerable"

Dependency Provenance

# Check package integrity
npm verify-registry

# Show package source
npm view express homepage
npm view express repository

# Check maintainer
npm view express maintainers

# Verify GPG signatures (if available)
npm verify --registry https://registry.npmjs.org

Lockfile Review

# Check what changed in lock file
git diff package-lock.json

# Review all changes to dependencies
git diff --name-only | grep package
git diff package.json

---

Constraints

MUST DO

• Run vulnerability scan on every pull request (CI/CD gate)
• Address CRITICAL and HIGH severity vulnerabilities within SLA (24-48 hours)
• Maintain detailed audit logs of all dependency changes
• Keep dependencies up to date (at least quarterly review)
• Document any deliberate acceptance of known vulnerabilities
• Use exact versions (=) for critical production dependencies
• Enable software Bill of Materials (SBOM) generation

MUST NOT DO

• Never ignore CRITICAL vulnerabilities (no exceptions)
• Never use wildcard (*) or loose ranges (>=) in production
• Never bypass security scanning in CI/CD
• Never merge dependency updates without testing
• Never use deprecated or unmaintained libraries
• Never assume transitive dependencies are safe
• Never commit without lock files

---

Related Skills

Skill	Purpose
coding-security-review	Manual security assessment of code patterns related to dependencies
coding-semver-automation	Version management that works with dependency updates