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 **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