secure-dependency-health-check

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 & Identify Candidates

If user provided candidates, note each package name, version (if specified), and ecosystem. If no candidates are specified, search for packages that meet the functional requirement and select 2–4 top candidates based on popularity/relevance.

Phase 2: Security & Health Analysis

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). The tool returns a comprehensive assessment including:

• overall_rating: "Healthy" or "Review recommended"
• security: vulnerability counts by severity (critical/high/medium/low), whether direct vulnerabilities exist, and a security rating
• maintenance: lifecycle status, latest release date, whether the package is archived or forked, and a maintenance rating ("Healthy", "Sustainable", or "Inactive")
• popularity: download counts, dependent packages/repos, and a popularity rating
• community: stargazers count, presence of README/contributing/code of conduct/funding files, and a community 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

Use the overall_rating as the primary evaluation metric. Surface the following 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

Step 3.1: Comparison Table

## Package Comparison: [Use Case]

| Criteria | Package A | Package B | Package C |
|----------|-----------|-----------|-----------|
| **Overall Rating** | | | |
| **Security Rating** | | | |
| **Critical CVEs** | | | |
| **High CVEs** | | | |
| **Maintenance** | | | |
| **Last Release** | | | |
| **Downloads** | | | |
| **Popularity** | | | |

Step 3.2: Alternative Scenarios

If no package meets the security threshold:

Phase 4: Integration Guidance

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

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 and report partial results with a disclaimer.
• No Candidates Meet Threshold: Report why each failed, suggest alternatives (in-house, fork, wait), and 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