fix-vulnerabilities_skill

Overview

This skill automates fixing Dependabot security vulnerabilities in Java/Gradle projects with severity-aware workflows and CI-validated verification. It focuses on choosing the right repair strategy—BOM updates, version catalog changes, substitution, constraints, or force rules—and ensures the dependency graph no longer reports vulnerable versions. Use it to produce safe, reviewable PRs that pass dependency-review checks.

How this skill works

The skill inspects open Dependabot alerts by severity and processes one severity level at a time, creating separate PRs for CRITICAL, then HIGH, then MEDIUM, then LOW. It applies a hierarchy of fixes (BOM, version catalog, substitution, constraints, force rules, exclude+add) and verifies outcomes by generating the Gradle dependency graph snapshot to confirm patched versions are the only ones present. The workflow includes CI validation guidance and a recommended commit/PR pattern for traceability.

When to use it

• Resolving open Dependabot security alerts in a Java/Gradle repo
• Fixing CVEs flagged by Dependabot that affect direct or transitive dependencies
• When dependency-review CI checks fail due to old versions appearing in the dependency graph
• When you need a conservative, severity-driven remediation plan with CI verification
• When creating reproducible PRs that must reference a Jira ticket

Best practices

• Process only one severity level per PR to isolate risk and simplify review
• Prefer BOM or version-catalog updates for direct dependency fixes before substitution
• Use dependency substitution to remove transitive vulnerable versions reported by the dependency graph
• Always run the dependency-graph verification step and confirm only patched versions appear
• Create a Jira ticket first and include the ticket key in commit messages and PR titles

Example use cases

• A CRITICAL CVE in a transitive gRPC dependency—apply BOM update or substitution and verify graph shows patched version
• Multiple HIGH alerts—process HIGHs only after confirming no CRITICALs remain, update libs.versions.toml where applicable
• dependency-review CI failing because the graph lists old versions—use substitution or constraints to eliminate those versions and rerun verification
• Quick mitigation for a low-risk vulnerability by adding a force rule combined with substitution as a short-term fix