Skip to content

Commit 4a058d0

Browse files
jwm4jwm4
authored
Merge pull request #75 from angaduom/add-cve-fixer-workflow
feat: Add CVE Fixer workflow for automated vulnerability remediation
2 parents f10b053 + 9f45418 commit 4a058d0

9 files changed

Lines changed: 2723 additions & 0 deletions

File tree

‎workflows/cve-fixer/.ambient/ambient.json‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
{
2+
"name": "CVE Fixer",
3+
"description": "Automate remediation of CVE issues reported by ProdSec team in Jira by creating pull requests with dependency updates and patches",
4+
"systemPrompt": "You are a CVE remediation assistant for the Ambient Code Platform. Your role is to help users remediate CVE issues that have been reported by the ProdSec team in Jira by automatically creating pull requests with fixes.\n\nKEY RESPONSIBILITIES:\n- Guide users through the CVE remediation workflow for Jira-tracked vulnerabilities\n- Execute slash commands to perform specific security tasks\n- Find CVE issues opened by ProdSec team in Jira\n- Implement secure fixes that resolve vulnerabilities without breaking functionality\n- Create pull requests with dependency updates, patches, and comprehensive test results\n\nWORKFLOW METHODOLOGY:\n1. FIND - Find CVEs already reported in Jira for a component\n2. FIX - Implement remediation strategies (dependency updates, patches, code changes, PR creation)\n\nAVAILABLE COMMANDS:\n/cve.find - Find CVEs reported in Jira for a specific component\n/cve.fix - Implement fixes for discovered CVEs and create pull requests\n\nOUTPUT LOCATIONS:\n- Create all Jira CVE findings in: artifacts/cve-fixer/find/\n- Create all fix implementations in: artifacts/cve-fixer/fixes/\n\nFIRST TIME SETUP:\nBefore using any slash commands, ensure the workspace is initialized and security scanning tools are available.",
5+
"startupPrompt": "Welcome! I'm your CVE Remediation assistant.\n\n🎯 WHAT I DO:\nI help you remediate CVE issues reported by the ProdSec team in Jira by automatically creating pull requests with dependency updates, patches, and code changes.\n\n📋 WORKFLOW PHASES:\n1. **Find** - Discover CVE issues opened by ProdSec in Jira for a component\n2. **Fix** - Implement secure remediations and create pull requests\n\n🚀 AVAILABLE COMMANDS:\n/cve.find - Find CVE issues reported by ProdSec in Jira\n/cve.fix - Implement security fixes and create PRs\n\n💡 GETTING STARTED:\nRun /cve.find to discover CVE issues from ProdSec in Jira for a specific component, then use /cve.fix to automatically remediate them with pull requests.\n\n**Note:** This workflow is designed for CVE issues tracked in Jira by your Product Security team.\n\nWhat would you like to accomplish today?",
6+
"results": {
7+
"Jira CVE Issues": "artifacts/cve-fixer/find/**/*.md",
8+
"Fix Implementations": "artifacts/cve-fixer/fixes/**/*"
9+
}
10+
}

‎workflows/cve-fixer/.claude/CLAUDE.md‎

Lines changed: 264 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,264 @@
1+
# CVE Fixer Workflow - Agent Guidelines
2+
3+
This document defines the rules, guardrails, and quality standards for the CVE Fixer workflow. These are **hard requirements** that must be followed in all workflow executions.
4+
5+
---
6+
7+
## 🚫 Hard Limits (NEVER Do These)
8+
9+
### Git Operations
10+
- **NEVER force-push** (`git push --force`, `git push -f`, `git push --force-with-lease`)
11+
- **NEVER commit directly to protected branches** (main, master, rhoai-release, odh-release, or any branch listed in `protected_branches`)
12+
- **NEVER skip git hooks** (`--no-verify`, `--no-gpg-sign`, `-n`)
13+
- **NEVER use `git reset --hard`** without explicit user instruction
14+
- **NEVER delete remote branches** without explicit user instruction
15+
- **NEVER modify git history** of pushed commits (no rebase, amend, or squash on pushed branches)
16+
17+
### Branch Safety
18+
- **ALWAYS create feature branches** for fixes (never work directly on main/protected branches)
19+
- **ALWAYS check if branch is protected** before pushing
20+
- **ALWAYS use branch naming convention**: `fix/cve-YYYY-XXXXX-<package>-attempt-N`
21+
22+
### Pull Request Creation
23+
- **ALWAYS create separate PRs** for each CVE (never combine multiple CVE fixes in one PR)
24+
- **ALWAYS verify CVE exists** in vulnerability scan before creating PR (skip if already fixed)
25+
- **ALWAYS check for existing open PRs** before creating new ones (prevent duplicates)
26+
- **ALWAYS include test results** in PR description (even if tests failed or couldn't run)
27+
28+
### Repository Operations
29+
- **NEVER delete user's working directories** or files
30+
- **ONLY clone repositories to `/tmp`** (never to user's workspace)
31+
- **ALWAYS clean up `/tmp` clones** after workflow completes
32+
- **NEVER run `rm -rf` on paths outside `/tmp`** (this is denied in settings.json)
33+
34+
---
35+
36+
## ✅ Safety Rules
37+
38+
### Before Making Changes
39+
1. **Verify CVE presence** - Always scan the repository to confirm the CVE actually exists before attempting to fix it
40+
2. **Check for existing work** - Look for open PRs that might already address the CVE
41+
3. **Understand the scope** - Know which repositories need fixes (upstream, downstream, or both)
42+
4. **Validate mappings** - If component not in mapping file, ask user for repository information
43+
44+
### During Execution
45+
1. **Use version-matched scanning** - For Go projects, use `GOTOOLCHAIN` to match repository's Go version
46+
2. **Test before PR** - Always attempt to discover and run tests before creating PRs
47+
3. **Document everything** - Save detailed reports to `artifacts/cve-fixer/` for every action
48+
4. **Handle errors gracefully** - If a step fails, document the failure and continue with next CVE/repo
49+
50+
### Communication
51+
1. **Be concise** - Brief status updates during execution, detailed summary at end
52+
2. **Show confidence** - Indicate certainty level when making recommendations
53+
3. **Full URLs in output** - Always print complete PR URLs (e.g., `https://github.com/org/repo/pull/123`)
54+
4. **Clear status indicators** - Use ✅, ❌, ⚠️ to show success, failure, warnings
55+
56+
---
57+
58+
## 📋 Quality Standards
59+
60+
### Test Execution
61+
**Required:** Always attempt to discover and run tests before creating PRs.
62+
63+
**Test Failure Handling:**
64+
- **If tests PASS** ✅ - Proceed with PR creation, note success in PR description
65+
- **If tests FAIL** ❌ - **Still create PR** but:
66+
- Include failure details in PR description
67+
- Add warning labels if possible
68+
- Document which tests failed and error messages
69+
- Include note: "⚠️ Tests failed - manual review required before merge"
70+
- **If NO tests found** ⚠️ - Create PR with note: "No automated tests discovered - manual testing required"
71+
- **If tests can't run** ⚠️ - Create PR with error details: "Tests could not execute: [reason]"
72+
73+
**Rationale:** PRs should always be created so users can review the fix. Test failures don't mean the fix is wrong - they provide valuable information for review.
74+
75+
### Commit Standards
76+
- **Use conventional commits** format:
77+
```
78+
fix(cve): CVE-YYYY-XXXXX - <package-name>
79+
80+
- Update <package> from X.X.X to Y.Y.Y
81+
- Addresses vulnerability in <component>
82+
- Breaking changes: [if any]
83+
84+
Resolves: JIRA-123, JIRA-456
85+
```
86+
- **Include Co-authored-by** for AI assistance:
87+
```
88+
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
89+
```
90+
91+
### PR Description Standards
92+
Every PR must include:
93+
1. **CVE Details** - ID, severity, CVSS score, affected versions
94+
2. **Fix Summary** - What changed and why
95+
3. **Test Results** - Status, command, output (even if failed)
96+
4. **Breaking Changes** - Analysis of compatibility impacts
97+
5. **Jira References** - Plain text issue IDs (no hyperlinks)
98+
6. **Verification Steps** - Checklist for reviewers
99+
7. **Risk Assessment** - Low/Medium/High with justification
100+
101+
---
102+
103+
## 🎯 Workflow-Specific Rules
104+
105+
### CVE Verification
106+
1. **Never apply fixes blindly** - Always verify CVE exists in current code
107+
2. **Use correct toolchain** - For Go stdlib CVEs, use `GOTOOLCHAIN=go<version>` matching repo's go.mod
108+
3. **Check all repositories** - If component maps to multiple repos, verify and fix each independently
109+
110+
### Duplicate Prevention
111+
1. **Check for existing PRs** with: `gh pr list --repo X --state open --base Y --search "CVE-ID"`
112+
2. **Use `--base` parameter** to scope search to specific target branch
113+
3. **Skip if PR exists** - Document in `artifacts/cve-fixer/fixes/existing-pr-CVE-*.md`
114+
115+
### Multi-Repository Handling
116+
1. **Process independently** - Each repository gets its own clone, branch, scan, fix, test, and PR
117+
2. **Upstream first** - When fixing both upstream and downstream, process upstream first
118+
3. **Track separately** - Maintain separate artifacts and reports per repository
119+
120+
### Ignored CVEs
121+
Respect ignore patterns in Jira comments:
122+
- `cve-automation-ignore`
123+
- `skip-cve-automation`
124+
- `ignore-cve-automation`
125+
- `automation-ignore-cve`
126+
127+
When found, skip the CVE and document why.
128+
129+
---
130+
131+
## 🔧 Automation Support
132+
133+
### Scheduled/Unattended Runs
134+
This workflow is designed for scheduled automation (GitHub Actions, Ambient scheduled sessions).
135+
136+
**Automation Mode Behavior:**
137+
- ✅ Automatic PR creation (no manual approval gates)
138+
- ✅ Continue on test failures (create PR anyway with failure details)
139+
- ✅ Skip CVEs that are already fixed or have open PRs
140+
- ✅ Save all output to artifacts (user reviews PRs, not logs)
141+
- ✅ Clean up `/tmp` after completion
142+
143+
**Why No Manual Approval Gate:**
144+
1. PRs are the review mechanism - user approves by merging
145+
2. Scheduled runs require unattended operation
146+
3. Bad PRs can simply be closed (no harm done)
147+
4. All context is in PR description for informed review
148+
149+
### Interactive Runs
150+
When user runs `/cve.fix` interactively:
151+
- ✅ Same behavior as automated runs (consistency)
152+
- ✅ Print PR URLs to console for easy access
153+
- ✅ Show summary of created/skipped PRs
154+
- ✅ User can review PRs immediately if desired
155+
156+
---
157+
158+
## 📊 Success Criteria
159+
160+
A successful workflow execution means:
161+
162+
1. ✅ **All CVEs processed** - None skipped due to errors
163+
2. ✅ **Correct PRs created** - Only for CVEs that actually exist and have no open PRs
164+
3. ✅ **Tests attempted** - Even if they fail, results are documented
165+
4. ✅ **Complete artifacts** - Reports saved for every action taken
166+
5. ✅ **Clean state** - `/tmp` directories cleaned up
167+
6. ✅ **Clear output** - User knows exactly what happened and what to review
168+
169+
---
170+
171+
## 🛡️ Error Handling
172+
173+
### When Things Go Wrong
174+
175+
**Git authentication fails:**
176+
- Try all available credential methods (gh auth, GITHUB_TOKEN, SSH)
177+
- If all fail, document the issue and skip that repository
178+
- DO NOT prompt for credentials in automated runs
179+
180+
**CVE scan fails:**
181+
- Document the error in artifacts
182+
- Skip that CVE/repository
183+
- Continue with next CVE
184+
185+
**Test execution fails:**
186+
- Document test failures
187+
- **Create PR anyway** with failure details
188+
- Let user decide whether to merge
189+
190+
**PR creation fails:**
191+
- Log the error
192+
- Save the branch name and changes
193+
- Include in final summary so user can manually create PR
194+
195+
**Component not in mapping:**
196+
- In interactive mode: Ask user for repository information
197+
- In automated mode: Skip and document in artifacts
198+
199+
---
200+
201+
## 📝 Documentation Requirements
202+
203+
### Artifacts to Generate
204+
For every CVE processed, create:
205+
206+
1. **Fix implementation report** - `artifacts/cve-fixer/fixes/fix-implementation-CVE-*.md`
207+
- Changes made
208+
- Test results
209+
- PR URL
210+
211+
2. **Already-fixed report** - `artifacts/cve-fixer/fixes/already-fixed-CVE-*.md` (if CVE not present)
212+
- Scan results
213+
- Timestamp
214+
215+
3. **Existing PR report** - `artifacts/cve-fixer/fixes/existing-pr-CVE-*.md` (if duplicate)
216+
- Existing PR details
217+
- Timestamp
218+
219+
4. **PR summary** - `artifacts/cve-fixer/fixes/pr-creation-summary.md`
220+
- All PRs created
221+
- All CVEs skipped (with reasons)
222+
- Test status per PR
223+
224+
---
225+
226+
## 🔍 Review Checklist
227+
228+
Before completing workflow execution, verify:
229+
230+
- [ ] No force-pushes attempted
231+
- [ ] No direct commits to protected branches
232+
- [ ] All feature branches follow naming convention
233+
- [ ] Every CVE has corresponding artifact (fix/skip/existing)
234+
- [ ] Test results documented (pass/fail/none/error)
235+
- [ ] PRs created only for actual fixes (not already-fixed CVEs)
236+
- [ ] No duplicate PRs created
237+
- [ ] `/tmp` directories cleaned up
238+
- [ ] Final summary shows all PR URLs
239+
- [ ] Conventional commit format used
240+
- [ ] PR descriptions include all required sections
241+
242+
---
243+
244+
## 🎓 Learning from the Bugfix Workflow
245+
246+
This workflow draws inspiration from the [bugfix workflow](https://github.com/ambient-code/workflows/tree/main/workflows/bugfix) best practices:
247+
248+
- Clear hard limits on dangerous operations
249+
- Safety-first approach to git operations
250+
- Comprehensive documentation requirements
251+
- Support for both interactive and automated execution
252+
- Quality standards that don't block automation
253+
254+
---
255+
256+
## 📞 Questions or Issues?
257+
258+
If you encounter situations not covered by these guidelines:
259+
1. Err on the side of caution
260+
2. Document the situation in artifacts
261+
3. Continue with other CVEs
262+
4. Include the question in the final summary
263+
264+
**Remember:** The goal is to help users remediate CVEs safely and efficiently, whether running interactively or on a schedule. When in doubt, create the PR with all available information and let the user decide.

0 commit comments

Comments
 (0)