secure-dependency-health-check

What this skill does

# Secure Dependency Health Check

Help developers and AI agents make informed decisions when selecting open-source packages by evaluating security health, vulnerability history, popularity, community, and maintenance status.

**Core Principle**: Choose dependencies wisely to minimize supply chain risk.

---

## Quick Start

When asked to recommend a package:
1. Identify the functional requirement
2. Research candidate packages
3. Run `snyk_package_health_check` on each candidate
4. Compare and recommend the healthiest, most secure option

---

## Phase 1: Understand Requirements

**Goal**: Clarify what the user needs before recommending packages.

### Step 1.1: Identify Candidates

If user provided candidates:
- Note each package name and version (if specified)
- Identify the package ecosystem

If user needs suggestions:
- Search for packages that meet the functional requirement
- Select 2-4 top candidates based on popularity/relevance

---

## Phase 2: Security & Health Analysis

**Goal**: Evaluate each candidate package's security posture and overall health.

### Step 2.1: Run Package Health Check for Each Candidate

For each candidate package, run `snyk_package_health_check` with the package name, version, and ecosystem (`npm`, `pypi`, `maven`, `nuget`, or `golang`). Key fields returned:
- **`overall_rating`**: "Healthy" or "Review recommended" — use as the primary evaluation metric
- **`security`**: vulnerability counts by severity (critical/high/medium/low) and a security rating
- **`maintenance`**: lifecycle status, latest release date, `is_archived` flag, and a maintenance rating ("Healthy", "Sustainable", or "Inactive")
- **`popularity`**: download counts, dependent packages/repos, and a popularity rating
- **`community`**: stargazers count, community file presence, and a rating ("Active" or "Sustainable")
- **`latest_version`**: the most recent published version
- **`recommendation`**: a human-readable summary of the overall assessment

### Step 2.2: Review Tool Results

Surface the following from the tool response for comparison:
- Overall rating ("Healthy" vs "Review recommended")
- Security rating and vulnerability breakdown by severity
- Maintenance rating and lifecycle status (check `is_archived`, `latest_release_published_at`)
- Popularity and community ratings

### Step 2.3: Disqualifiers

**Immediately disqualify packages regardless of overall rating if**:
- Security issues found with critical or high severity vulnerabilities
- Maintenance rating is "Inactive" or package is archived (`is_archived: true`)
- No releases in 3+ years (check `latest_release_published_at`)
- Known malicious package (supply chain attack)
- Typosquatting indicators (similar name to popular package)

---

## Phase 3: Generate Recommendation

**Goal**: Present a clear, actionable comparison.

### Step 3.1: Comparison Table

```
## Package Comparison: [Use Case]

| Criteria | Package A | Package B | Package C |
|----------|-----------|-----------|-----------|
| **Overall Rating** | Healthy | Review recommended | Healthy |
| **Security Rating** | Security issues found | Security issues found | No known security issues |
| **Critical CVEs** | 0 | 1 | 0 |
| **High CVEs** | 1 | 2 | 0 |
| **Maintenance** | Healthy | Inactive | Healthy |
| **Last Release** | 2 weeks ago | 8 months ago | 1 month ago |
| **Downloads** | 500K | 2M | 300K |
| **Popularity** | Influential project | Influential project | Influential project |

### Recommendation: **Package C**

**Reasons**:
1. "Healthy" overall rating with no known security issues
2. Healthy maintenance rating - actively maintained with recent release
3. Fewest vulnerabilities across all severity levels

**Trade-offs**:
- Fewer downloads than Package B (less battle-tested)
- Consider if specific features of Package A/B are required

**Recommended version**: Use the `latest_version` from the tool response to pin an exact version.
```

### Step 3.2: Alternative Scenarios

If no package meets the security threshold:

```
## Warning: No Secure Option Available

All evaluated packages have significant security concerns:
- Package A: 2 Critical CVEs (actively exploited)
- Package B: Abandoned - no updates in 3 years
- Package C: Multiple high-severity vulnerabilities with no fix available

### Alternatives:
1. **Implement in-house**: For simple functionality
2. **Fork and fix**: If one package is close but has fixable issues
3. **Wait**: If updates are expected soon
4. **Accept risk**: With documented justification and monitoring
```

---

## Phase 4: Integration Guidance

**Goal**: Help the user safely add the recommended package.

### Step 4.1: Post-Installation Scan

Recommend running `snyk_sca_scan` after installation to verify the full dependency tree doesn't introduce unexpected vulnerabilities.

### Step 4.2: Monitoring Recommendation

Advise committing lock files, enabling vulnerability notifications, and checking for security updates regularly.

---

## Error Handling

### Package Not Found
- Verify package name and ecosystem
- Check for typos
- Search for alternative names

### Scan Fails or Insufficient Data
- The tool may return "Snyk doesn't have sufficient information about this package" for some packages
- Retry once; if still no data, fall back to manual research
- Report partial results with disclaimer that the tool could not assess this package

### No Candidates Meet Threshold
- Report why each failed
- Suggest alternatives (in-house, fork, wait)
- Document risk if user proceeds anyway

---

## Constraints

1. **Never recommend packages with known exploits**
2. **Always specify exact version** in recommendations
3. **Disclose limitations** if full analysis isn't possible
4. **Update recommendations** if user provides new constraints