Skills DirectorySearch all skills ↗AI agent skill · by @bitwarden
Reviewing Dependencies
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.
Archived 2026-10-23 · Source updated 2026-09-18. Check the original repository for the latest version.
SKILL.md instructions
## Dependency Vulnerability Workflow
### Step 1: Gather Alerts
```bash
# 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:**
```bash
# 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.
```bash
# 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)
```bash
# 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 vulnerability profiles than .NET Core
- `PackageReference` in `.csproj` is preferred over `packages.config` for better transitive resolution
- Use `Directory.Packages.props` for centralized version management in multi-project solutions
### npm (Node.js)
```bash
# Run security audit
npm audit
# Auto-fix where possible
npm audit fix
# Force fixes (may introduce breaking changes)
npm audit fix --force
# Check lockfile integrity
npm ci # Installs exactly from lockfile, fails if lockfile is out of date
```
**npm-specific concerns:**
- `package-lock.json` must be committed and kept in sync
- Use `overrides` in `package.json` to force transitive dependency versions:
```json
{
"overrides": {
"vulnerable-package": ">=2.0.0"
}
}
```
- Beware of `postinstall` scripts in dependencies — they execute arbitrary code during `npm install`
## SBOM Concepts
A Software Bill of Materials (SBOM) is an inventory of all components in a software artifact. Understanding SBOMs helps reason about supply chain risk:
- **What it contains:** Package names, versions, licenses, relationships (direct vs. transitive)
- **Why it matters:** Enables rapid response when a new CVE is published — immediately identify which projects are affected
- **Standard formats:** SPDX, CycloneDX
- **GitHub integration:** GitHub generates dependency graphs automatically; Dependabot uses this for alerting
## Critical Rules
- **Never ignore critical/high Dependabot alerts** without documented justification. Even if the vulnerable code path seems unreachable, document why.
- **Prefer updating over pinning.** Pinning a vulnerable version and adding a workaround accumulates tech debt. Update when a fix is available.
- **Evaluate the full transitive tree.** A direct dependency may be safe, but its transitive dependencies may not be.
- **Review new dependencies before adoption.** Check health criteria above before adding any new package. More dependencies = more attack surface.
- **Lock dependencies.** Always commit lockfiles (`package-lock.json`, `packages.lock.json`). Use `npm ci` in CI/CD, not `npm install`.