| name | cve-remediation |
| description | Verify if a CVE affects the project and remediate it. Checks dependencies, identifies vulnerable versions, suggests/applies fixes, and validates changes. Use when analyzing security vulnerabilities or responding to CVE reports. |
CVE Remediation Skill
Systematic process for verifying and remediating CVE (Common Vulnerabilities and Exposures) impacts on Rundeck.
When to Use
- Security team reports a CVE
- Automated security scan identifies vulnerability
- Upstream dependency announces security issue
- Proactive security review
- Before major releases
Process Overview
1. CVE Analysis → 2. Dependency Check → 3. Impact Assessment → 4. Fix Strategy → 5. Implementation → 6. Validation → 7. Documentation
Phase 1: CVE Analysis
Input Required
- CVE ID: e.g.,
CVE-2024-1234
- CVE Details: Description, affected versions, severity
- Source: Where the CVE was reported (scanner, security team, upstream)
Gather Information
curl -s "https://cve.circl.lu/api/cve/${CVE_ID}" | jq
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=${CVE_ID}"
What to extract:
- Affected library/component
- Vulnerable version ranges
- Fixed versions available
- CVSS score and severity
- Attack vector and exploitability
Phase 2: Dependency Check
Step 1: Identify Dependency Locations
Check these files for dependency definitions:
cat gradle.properties
find . -name "build.gradle" -not -path "*/node_modules/*"
cat rundeckapp/grails-spa/packages/ui-trellis/package.json
Step 2: Search for Vulnerable Dependency
Use Grep to find the dependency across the codebase:
rg "log4j" gradle.properties build.gradle
rg "log4jVersion" --type gradle
rg "jackson" gradle.properties
Step 3: Check Transitive Dependencies
./gradlew dependencies > dependency-tree.txt
grep -i "vulnerable-library" dependency-tree.txt
./gradlew :module-name:dependencies
Step 4: Frontend Dependencies
cd rundeckapp/grails-spa/packages/ui-trellis
npm list <vulnerable-package>
npm audit
npm audit --json | jq '.vulnerabilities'
Phase 3: Impact Assessment
Determine Impact Level
Critical Impact:
- Direct dependency
- Used in production code paths
- Exploitable in our deployment
- High CVSS score (7.0+)
Medium Impact:
- Transitive dependency
- Used in non-critical paths
- Requires specific conditions to exploit
- Medium CVSS score (4.0-6.9)
Low Impact:
- Test-only dependency
- Not used in production
- Difficult to exploit in our context
- Low CVSS score (<4.0)
Document Findings
Create a summary:
## CVE Impact Assessment: ${CVE_ID}
**Affected Component:** [library name and version]
**Current Version:** [version in project]
**Vulnerable Versions:** [range from CVE]
**Fixed Version:** [recommended upgrade]
**Severity:** [Critical/High/Medium/Low]
**Impact on Rundeck:** [Direct/Transitive/Not Affected]
**Usage in Project:**
- Location: [file paths]
- Modules affected: [list]
- Production impact: [Yes/No - explain]
**Exploitability:**
- Attack vector: [Local/Network/Adjacent]
- Requires: [Authentication/User interaction/etc]
- Impact on us: [likely/unlikely - explain]
Phase 4: Fix Strategy
Strategy A: Version Upgrade (Preferred)
When to use:
- Fixed version available
- Upgrade is backward compatible
- No breaking changes
Steps:
- Identify fixed version from CVE report
- Check for breaking changes in changelog
- Plan upgrade path
- Update version in
gradle.properties or build.gradle
Strategy B: Dependency Exclusion + Alternative
When to use:
- Fixed version not available
- Upgrade has breaking changes
- Vulnerability is in transitive dependency we don't use
Steps:
- Identify which direct dependency pulls in vulnerable library
- Exclude vulnerable transitive dependency
- Add explicit dependency on fixed version
- Verify functionality
Strategy C: Workaround/Mitigation
When to use:
- No fix available yet
- Upgrade not feasible immediately
- Need temporary protection
Options:
- Configuration changes to disable vulnerable features
- Network/firewall rules
- Input validation
- WAF rules
- Runtime monitoring
Strategy D: Accept Risk (Documented)
When to use:
- Low impact
- Not exploitable in our environment
- Fix causes more issues than vulnerability
Requirements:
- Document decision in a GitHub issue
- Get security team approval
- Add to risk register
- Set reminder to revisit
Phase 5: Implementation
Write Tests First
Even for dependency upgrades, write a test first:
// Example: Test that vulnerable version is NOT present
def "should not use vulnerable log4j version"() {
when:
def dependencies = project.configurations.runtimeClasspath.resolvedConfiguration.resolvedArtifacts
then:
!dependencies.any { it.name == 'log4j-core' && it.moduleVersion.id.version.startsWith('2.14') }
}
Update Dependencies
For gradle.properties:
# Before
log4jVersion=2.14.1
# After (with comment explaining why)
# Updated from 2.14.1 to fix CVE-2021-44228 (Log4Shell)
log4jVersion=2.17.1
For build.gradle:
// Exclude vulnerable transitive dependency
dependencies {
implementation('some-library:1.0') {
exclude group: 'vulnerable-lib', module: 'vulnerable-module'
}
// Add fixed version explicitly
implementation 'vulnerable-lib:vulnerable-module:fixed-version'
}
For package.json:
{
"dependencies": {
"vulnerable-package": "^fixed.version"
},
"overrides": {
"transitive-vulnerable": "^fixed.version"
}
}
Run Formatting and Compilation
./gradlew spotlessApply
./gradlew compileGroovy compileJava
Phase 6: Validation
Step 1: Verify Dependency Updated
./gradlew dependencies | grep -i "vulnerable-library"
npm list vulnerable-package
./gradlew build --info | grep "vulnerable-library"
Step 2: Run Test Suite
./gradlew test
./gradlew :affected-module:test
CORE_UI=rundeckapp/grails-spa/packages/ui-trellis
npm run --prefix "$CORE_UI" ci:test:unit
Step 3: Functional Testing
./gradlew :functional-test:apiTest
./gradlew :functional-test:seleniumTest
Step 4: Build and Smoke Test
./gradlew build
./gradlew bootRun
Step 5: Security Verification
./gradlew dependencyCheckAnalyze
./gradlew dependencies | grep -i "CVE"
npm audit
npm audit fix --dry-run
Phase 7: Documentation
Create a GitHub Issue
If not already created:
Title: Fix CVE-XXXX-XXXX in [library]
Labels: security
Body:
CVE: CVE-XXXX-XXXX
Affected: [library] version [X.X.X]
Severity: [CVSS score and rating]
Fix: Upgrade to version [Y.Y.Y]
Impact: [Description of impact on Rundeck]
Links:
- NVD: https://nvd.nist.gov/vuln/detail/CVE-XXXX-XXXX
- Vendor advisory: [link]
Commit Message
Fix CVE-XXXX-XXXX in [library]
Upgrade [library] from [old-version] to [new-version] to address
security vulnerability CVE-XXXX-XXXX.
Vulnerability Details:
- Severity: [Critical/High/Medium/Low]
- CVSS: [score]
- Impact: [brief description]
Changes:
- Updated [library]Version in gradle.properties
- Ran full test suite - all passing
- Verified no functional regressions
Create Pull Request
gh pr create --title "Fix CVE-XXXX-XXXX in [library]" --body "..."
PR Description (in addition to template):
## Security Fix
**CVE:** CVE-XXXX-XXXX
**Severity:** [Critical/High/Medium/Low] (CVSS [score])
**Affected:** [library] [version-range]
**Fix:** Upgrade to [new-version]
**Impact Assessment:**
- [X] Direct dependency / [ ] Transitive dependency
- [X] Production code / [ ] Test code only
- Exploitable: [Yes/No - explanation]
**Testing:**
- [X] All unit tests pass
- [X] All functional tests pass
- [X] Manual smoke test completed
- [X] Security scan shows CVE resolved
**References:**
- NVD: https://nvd.nist.gov/vuln/detail/CVE-XXXX-XXXX
- Vendor advisory: [link]
Update Security Documentation
If the project has a security changelog or vulnerability log, update it:
## [Date] - CVE-XXXX-XXXX
**Fixed in:** Version X.Y.Z
**CVE:** CVE-XXXX-XXXX
**Severity:** [level]
**Component:** [library] [old-version] → [new-version]
**Impact:** [description]
**Credit:** [who reported it]
Common Scenarios
Scenario 1: Gradle Dependency CVE
1. Search for dependency in gradle.properties
2. Update version
3. Run ./gradlew dependencies to verify
4. Run ./gradlew test
5. Create PR
Scenario 2: Transitive Dependency CVE
1. Find which direct dependency pulls it in
2. Add explicit dependency with fixed version
3. Or exclude vulnerable transitive and add fixed version
4. Verify with ./gradlew dependencies
5. Run tests and create PR
Scenario 3: Frontend NPM Package CVE
1. cd to package directory
2. Run npm audit
3. Update package.json or use overrides
4. Run npm test
5. Commit and create PR
Scenario 4: No Fix Available Yet
1. Document the issue in a GitHub issue
2. Assess actual risk/exploitability
3. Implement workarounds if needed
4. Set up monitoring/alerts
5. Schedule re-assessment when fix available
Checklist
Use this checklist for every CVE remediation:
Quick Reference Commands
rg "library-name" gradle.properties build.gradle
./gradlew dependencies | grep "library-name"
vim gradle.properties
./gradlew spotlessApply
./gradlew compileGroovy compileJava
./gradlew test
./gradlew dependencyCheckAnalyze
npm audit
git checkout -b fix-cve-xxxx-xxxx
git add gradle.properties
git commit -m "Fix CVE-XXXX in library"
gh pr create --web
See Also
- Testing:
.claude/docs/testing-guidelines.md
- Conventions: CLAUDE.md - Code conventions, git workflow, dependency management
- Build Commands:
.claude/docs/build-commands.md