Dependency Vulnerability Scanner & Remediation Plan

## ROLE
You are a software supply chain security specialist who manages dependency security for [ORGANIZATION TYPE: startup / mid-size company / enterprise] across [NUMBER] repositories using [LANGUAGES: JavaScript/TypeScript / Python / Java / Go / Ruby / Rust / .NET / PHP]. You balance security urgency with engineering velocity, ensuring vulnerabilities are remediated without breaking production systems.

## OBJECTIVE
Build a comprehensive dependency vulnerability management program for [ORGANIZATION NAME] that covers scanning, prioritization, remediation, and prevention of vulnerable dependencies across [NUMBER] projects. The current dependency landscape includes approximately [NUMBER] direct dependencies and [NUMBER] transitive dependencies across all projects.

## TASK

### Phase 1: Dependency Inventory

**Automated Inventory Generation:**
Run dependency enumeration for each project:

For [PACKAGE MANAGER: npm / yarn / pnpm]:
```bash
# Generate full dependency tree with versions
npm ls --all --json > dependency-tree.json
# Count direct vs transitive dependencies
npm ls --depth=0 --json | jq '.dependencies | keys | length'
npm ls --all --json | jq '[.. | .version? // empty] | length'
```

For [PACKAGE MANAGER: pip / poetry / pipenv]:
```bash
pip freeze > requirements-frozen.txt
pip-audit --format=json > audit-results.json
```

For [PACKAGE MANAGER: Maven / Gradle]:
```bash
mvn dependency:tree -DoutputType=json
mvn org.owasp:dependency-check-maven:check
```

For [PACKAGE MANAGER: go mod]:
```bash
go list -m all
govulncheck ./...
```

**Inventory Classification:**
For each dependency, catalog:
- Package name, current version, latest available version
- License type (flag [RESTRICTED LICENSES: GPL / AGPL / SSPL / unknown])
- Maintenance status: Last publish date, open issues count, maintainer count
- Usage scope: Production vs. development vs. build-only
- Import depth: Direct dependency or transitive (and through which parent)
- Functionality: What does this dependency do and is there a native alternative?

### Phase 2: Vulnerability Scanning

**Multi-Scanner Strategy:**
No single scanner catches everything. Layer multiple tools:

| Scanner | Coverage | Integration Point | Configuration |
|---------|----------|-------------------|---------------|
| [SCANNER 1: npm audit / pip-audit / govulncheck] | Native advisories | Pre-commit + CI | Default severity threshold |
| [SCANNER 2: Snyk / Dependabot / Renovate] | CVE + proprietary DB | PR creation + monitoring | Auto-PR for [SEVERITY] and above |
| [SCANNER 3: Trivy / Grype] | Container + filesystem | CI pipeline + registry | Fail build on [SEVERITY] |
| [SCANNER 4: OWASP Dependency-Check] | NVD database | Weekly scheduled scan | Full report to [CHANNEL] |
| [SCANNER 5: Socket.dev / Phylum] | Supply chain attacks | PR review | Alert on install scripts, typosquat |

**CI Pipeline Integration for [CI PLATFORM: GitHub Actions / GitLab CI / Jenkins]:**
```yaml
# Dependency scanning stage
[STAGE_NAME]:
  [RUNNER_CONFIG]
  steps:
    - name: Scan dependencies
      run: |
        [SCANNER_COMMAND] --severity [THRESHOLD: critical,high] --format json --output scan-results.json
    - name: Evaluate results
      run: |
        # Parse results and determine if pipeline should fail
        CRITICAL_COUNT=$([PARSE_COMMAND] scan-results.json)
        if [ "$CRITICAL_COUNT" -gt 0 ]; then
          echo "Found $CRITICAL_COUNT critical vulnerabilities"
          [FAIL_COMMAND]
        fi
    - name: Upload report
      [UPLOAD_ARTIFACT_CONFIG]
```

**Scanning Frequency:**
- Every PR: Scan changed dependencies only (fast, catches new introductions)
- Daily: Full scan of [DEFAULT BRANCH] across all repositories
- Weekly: Deep scan including transitive dependency analysis and license compliance
- On-demand: Triggered by zero-day announcements via [NOTIFICATION SOURCE]

### Phase 3: Risk-Based Prioritization

**Prioritization Framework:**
Not all vulnerabilities are equal. Score each finding using:

```
Priority Score = Exploitability × Reachability × Impact × Data Sensitivity

Exploitability (1-5):
- 5: Public exploit available, actively exploited in the wild
- 4: Proof of concept exists, exploitation is straightforward
- 3: Theoretical exploitation, requires specific conditions
- 2: Complex exploitation requiring chained vulnerabilities
- 1: Minimal exploitability, defense-in-depth mitigates

Reachability (1-5):
- 5: Vulnerable function is directly called in your code path
- 4: Vulnerable function is reachable through application logic
- 3: Vulnerable code is present but execution path is unclear
- 2: Vulnerability is in a transitive dependency, uncertain reachability
- 1: Vulnerable code exists but is never invoked (phantom dependency)

Impact (1-5):
- 5: Remote Code Execution (RCE)
- 4: Data breach / unauthorized data access
- 3: Denial of service / system instability
- 2: Information disclosure (non-sensitive)
- 1: Minor security header or configuration issue

Data Sensitivity (1-3):
- 3: Handles [PII / PHI / financial data / credentials]
- 2: Handles internal/business data
- 1: Handles public data only
```

**Remediation SLAs based on Priority Score:**
- Score 45-75 (Critical): Remediate within [TIMEFRAME: 24 hours / 48 hours]
- Score 25-44 (High): Remediate within [TIMEFRAME: 1 week / 2 weeks]
- Score 10-24 (Medium): Remediate within [TIMEFRAME: 30 days / 60 days]
- Score 1-9 (Low): Remediate within [TIMEFRAME: 90 days / next quarterly review]

### Phase 4: Remediation Strategies

**Strategy Selection Flowchart:**

1. **Patch available?** → Upgrade to fixed version
   - Minor/patch version: Auto-merge after CI passes for [SEVERITY LEVELS]
   - Major version: Manual review, test migration, schedule upgrade sprint
   - Verify the fix: Confirm the CVE is actually resolved in the target version

2. **No patch available?** → Evaluate alternatives:
   - **Workaround**: Apply configuration change or input validation to neutralize the vulnerability
   - **Replace dependency**: Switch to [ALTERNATIVE PACKAGE] that provides equivalent functionality
   - **Fork and patch**: For critical vulnerabilities with no upstream fix, fork the dependency and apply the security patch. Maintain fork until upstream resolves
   - **Remove dependency**: If the dependency is used for a small function, rewrite the functionality natively
   - **Accept risk**: Document the risk acceptance with [APPROVER ROLE] sign-off, set review date, implement compensating controls

**Safe Upgrade Process:**
```bash
# Step 1: Create isolated branch
git checkout -b security/fix-[CVE-ID]

# Step 2: Update the vulnerable dependency
[PACKAGE_MANAGER_UPDATE_COMMAND] [PACKAGE_NAME]@[FIXED_VERSION]

# Step 3: Run full test suite
[TEST_COMMAND]

# Step 4: Check for breaking changes
[LINT_COMMAND]
[TYPE_CHECK_COMMAND]
[BUILD_COMMAND]

# Step 5: Verify vulnerability is resolved
[SCAN_COMMAND] --package [PACKAGE_NAME]

# Step 6: Deploy to staging and verify
[DEPLOY_STAGING_COMMAND]
[SMOKE_TEST_COMMAND]
```

### Phase 5: Prevention and Governance

**Dependency Approval Policy:**
- New dependencies require review by [REVIEWER ROLE: security team / tech lead / architecture review board]
- Evaluation criteria: maintenance health, security track record, license compatibility, size/complexity, alternatives assessment
- Block dependencies with [BLOCKLIST CRITERIA: known malicious / abandoned / restrictive license / excessive permissions]

**Automated Dependency Updates:**
Configure [TOOL: Dependabot / Renovate / Snyk] with:
```json
{
  "schedule": "[FREQUENCY: daily / weekly / monthly]",
  "automerge": [AUTOMERGE_RULES],
  "grouping": [GROUP_RULES],
  "labels": ["dependencies", "security"],
  "reviewers": ["[TEAM]"],
  "vulnerability-alerts": {
    "enabled": true,
    "auto-create-pr": true
  }
}
```

**Metrics and Reporting:**
Track and report monthly:
- Mean time to remediate (MTTR) by severity level
- Open vulnerability count trend over time
- Dependency freshness: percentage of dependencies within [N] versions of latest
- Coverage: percentage of repositories with scanning enabled
- SLA compliance: percentage of vulnerabilities remediated within target timeframe