Cve Dependency Management

---




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)

```bash
# 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)

```bash
# 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

```bash
# 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

```bash
# 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

```bash
# 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

```yaml
# .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

```yaml
# .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

```bash
# 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

```json
{
  "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

```json
{
  "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

```bash
# ✅ 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

```bash
# 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

```bash
# 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

```bash
# 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 |