/reviewing-dependencies

name: reviewing-dependencies
description: This skill should be used when the user asks to "review Dependabot alerts", "check for vulnerable dependencies", "audit third-party packages", "assess supply chain risk", "run an Aikido scan", or needs to evaluate dependency health, transitive risk, or supply chain security.

Dependency Vulnerability Workflow

Step 1: Gather Alerts

# List all open Dependabot alerts sorted by severity
gh api /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | select(.state == "open") | {number, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem, summary: .security_advisory.summary}'

# Filter by severity
gh api "/repos/{owner}/{repo}/dependabot/alerts?severity=critical&state=open"

# Get full details for a specific alert
gh api /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

Step 2: Assess Impact

For each alert, determine:

1. **Is the vulnerable code path reachable?** — Does the application actually use the vulnerable function/feature of the dependency? 2. **Is it a direct or transitive dependency?** — Transitive vulnerabilities may be harder to fix but still pose real risk. 3. **What is the CVSS score and exploit availability?** (Score with the CVSS convention `triaging-security-findings` defines for effective severity.) A high CVSS with a public exploit needs immediate action. A medium CVSS with no known exploit can be scheduled. 4. **What versions are affected and what versions fix it?** — Check if updating is a minor bump or a breaking change.

Step 3: Decide on Action

| Situation | Action | | ----------------------------------------- | ---------------------------------------------- | | Fix available, minor version bump | Update immediately | | Fix available, major version bump | Evaluate breaking changes, schedule update | | No fix available, code path reachable | Implement workaround or replace dependency | | No fix available, code path not reachable | Document and monitor, set review date | | Vulnerability in transitive dependency | Use overrides/resolutions to pin fixed version |

Transitive Dependency Risk

Direct dependencies are visible in `package.json` or `.csproj` files, but transitive dependencies (dependencies of dependencies) make up the majority of the dependency tree and are often invisible.

**Why transitive dependencies matter:**

• A vulnerability in a deeply nested dependency is just as exploitable as one in a direct dependency
• Transitive dependencies are less likely to be actively monitored
• Updating a transitive dependency may require updating the direct dependency that pulls it in

**How to investigate:**

# npm: Show full dependency tree
npm ls --all

# npm: Find which direct dependency pulls in a vulnerable transitive
npm ls <vulnerable-package>

# .NET: List all vulnerable packages including transitive
dotnet list package --vulnerable --include-transitive

# .NET: Show dependency graph
dotnet list package --include-transitive

Dependency Health Evaluation

When evaluating whether to adopt or keep a dependency, assess:

| Criterion | Green Flag | Red Flag | | ------------------------- | ----------------------------------------- | -------------------------------------------- | | **Maintenance** | Regular commits, responsive to issues | No commits in 12+ months, unresponded issues | | **Vulnerability History** | Few CVEs, quick patches | Repeated CVEs, slow response | | **Maintainer Count** | Multiple active maintainers | Single maintainer, bus factor of 1 | | **Community** | High download count, active users | Very low adoption for claimed scope | | **License** | Compatible with project (MIT, Apache-2.0) | Restrictive or ambiguous license | | **Security Practices** | Signed releases, security policy, 2FA | No security policy, no signed releases |

Aikido Integration

Aikido is Bitwarden's container and open-source dependency scanner. It continuously scans connected repositories, surfacing open-source (SCA) and container findings in the same feed as SAST, IaC, and secrets results.

Use the `aikido:issues` skill (`aikido_issues_list`) to query findings, scoping to the relevant repo and filtering `issue_types` to `open_source` (dependency CVEs) and `docker_container` (container image vulnerabilities). `cloud_instance` is a separate Aikido issue type for cloud VM/instance findings — out of scope for dependency and container review.

Use the caller-supplied Aikido evidence if you were given any. Otherwise query `aikido:issues`, and if it is unavailable, stop and tell the user rather than proceeding without this data.

# Use the aikido:issues skill, e.g.:
# issue_types: ["open_source"], repo_name: "<repo>"       -> dependency CVEs
# issue_types: ["docker_container"], repo_name: "<repo>"  -> container image vulnerabilities

**Interpreting Aikido output:**

• Each finding includes: issue title, type, severity (and severity label), remediation guidance, and SLA due date
• Use `out_of_sla: true` to focus on findings already past their remediation SLA
• Triage follows the same Jira-based flow as other Aikido findings — see the `triaging-security-findings` skill

Platform-Specific Guidance

NuGet (.NET)

# Check for vulnerable packages
dotnet list package --vulnerable

# Include transitive dependencies
dotnet list package --vulnerable --include-transitive

# Check for outdated packages
dotnet list package --outdated

**NuGet-specific concerns:**

• .NET framework packages may have different vulner