Dependabot Security

Fix Dependabot security vulnerabilities in Java/Gradle projects with proper verification.

When to use this skill

• Resolving Dependabot security alerts

• Fixing CVE vulnerabilities in dependencies

• Verifying dependency graph for CI compliance

• Choosing the right fix strategy for transitive dependencies

• Understanding why dependency-review CI check fails

• When asked to "fix dependabot vulnerabilities" or "fix security alerts"

Skill Contents

Sections

• When to use this skill

• Quick Start

• Key Concepts

• References

• Related Rules

• Related Skills

Available Resources

📚 references/ - Detailed documentation

• dependency graph

• fix strategies

• severity processing

• troubleshooting

Quick Start

1. Create Jira ticket first

See global/rules/jira-ticket-workflow.md for ticket creation.

2. Get alerts by severity

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner') gh api --paginate repos/$REPO/dependabot/alerts --jq '.[] | select(.state == "open") | { number, severity: .security_advisory.severity, package: .dependency.package.name, patched_version: .security_vulnerability.first_patched_version.identifier, cve: .security_advisory.cve_id }'

3. Fix by severity (CRITICAL first, then HIGH, MEDIUM, LOW)

See references/fix-strategies.md for strategy hierarchy.

4. Verify with dependency graph

./gradlew -I gradle/dependency-graph-init.gradle
--dependency-verification=off
:ForceDependencyResolutionPlugin_resolveAllDependencies

Check ONLY patched versions appear

grep -i "package-name" build/reports/dependency-graph-snapshots/dependency-list.txt

5. Commit and create PR

git commit -m "🤖 🛡️ fix(security): [JIRA-KEY] resolve CRITICAL vulnerabilities"

Key Concepts

Severity-Based Processing

Process ONE severity level at a time, creating separate PRs for each:

Priority Severity When to Process

1 CRITICAL Always first

2 HIGH After no CRITICAL

3 MEDIUM After no HIGH

4 LOW After no MEDIUM

Dependency Graph vs Runtime Resolution

The dependency graph plugin reports ALL versions to GitHub, not just the resolved version. Force rules alone won't fix dependency-review failures - use substitution to remove old versions.

Fix Strategy Hierarchy

• BOM Update - Update Spring Boot, gRPC, Protobuf BOM versions

• Version Catalog - Update direct dependencies in libs.versions.toml

• Dependency Substitution - Replace transitive dependencies

• Constraints - Set minimum version floors

• Force Rules - Quick fix (combine with substitution)

• Exclude + Add - Last resort

References

Reference Description

references/fix-strategies.md Detailed fix strategies with examples

references/severity-processing.md Severity-based workflow

references/dependency-graph.md Dependency graph plugin setup and verification

references/troubleshooting.md Common issues and solutions

Related Rules

• .cursor/rules/java-vulnerability-golden-paths.mdc

• Proven fix patterns for common CVEs

• .cursor/rules/java-versions-and-dependencies.mdc

• Version management policies

Related Skills

Skill Purpose

gradle-standards Gradle configuration

sonarqube-integration Code quality checks