feat: Add CVE Fixer workflow for automated vulnerability remediation

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

@@ -0,0 +1,10 @@
+{
+  "name": "CVE Fixer",
+  "description": "Automate remediation of CVE issues reported by ProdSec team in Jira by creating pull requests with dependency updates and patches",
+  "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.",
+  "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?",
+  "results": {
+    "Jira CVE Issues": "artifacts/cve-fixer/find/**/*.md",
+    "Fix Implementations": "artifacts/cve-fixer/fixes/**/*"
+  }
+}

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

@@ -0,0 +1,264 @@
+# CVE Fixer Workflow - Agent Guidelines
+
+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.
+
+---
+
+## 🚫 Hard Limits (NEVER Do These)
+
+### Git Operations
+- **NEVER force-push** (`git push --force`, `git push -f`, `git push --force-with-lease`)
+- **NEVER commit directly to protected branches** (main, master, rhoai-release, odh-release, or any branch listed in `protected_branches`)
+- **NEVER skip git hooks** (`--no-verify`, `--no-gpg-sign`, `-n`)
+- **NEVER use `git reset --hard`** without explicit user instruction
+- **NEVER delete remote branches** without explicit user instruction
+- **NEVER modify git history** of pushed commits (no rebase, amend, or squash on pushed branches)
+
+### Branch Safety
+- **ALWAYS create feature branches** for fixes (never work directly on main/protected branches)
+- **ALWAYS check if branch is protected** before pushing
+- **ALWAYS use branch naming convention**: `fix/cve-YYYY-XXXXX-<package>-attempt-N`
+
+### Pull Request Creation
+- **ALWAYS create separate PRs** for each CVE (never combine multiple CVE fixes in one PR)
+- **ALWAYS verify CVE exists** in vulnerability scan before creating PR (skip if already fixed)
+- **ALWAYS check for existing open PRs** before creating new ones (prevent duplicates)
+- **ALWAYS include test results** in PR description (even if tests failed or couldn't run)
+
+### Repository Operations
+- **NEVER delete user's working directories** or files
+- **ONLY clone repositories to `/tmp`** (never to user's workspace)
+- **ALWAYS clean up `/tmp` clones** after workflow completes
+- **NEVER run `rm -rf` on paths outside `/tmp`** (this is denied in settings.json)
+
+---
+
+## ✅ Safety Rules
+
+### Before Making Changes
+1. **Verify CVE presence** - Always scan the repository to confirm the CVE actually exists before attempting to fix it
+2. **Check for existing work** - Look for open PRs that might already address the CVE
+3. **Understand the scope** - Know which repositories need fixes (upstream, downstream, or both)
+4. **Validate mappings** - If component not in mapping file, ask user for repository information
+
+### During Execution
+1. **Use version-matched scanning** - For Go projects, use `GOTOOLCHAIN` to match repository's Go version
+2. **Test before PR** - Always attempt to discover and run tests before creating PRs
+3. **Document everything** - Save detailed reports to `artifacts/cve-fixer/` for every action
+4. **Handle errors gracefully** - If a step fails, document the failure and continue with next CVE/repo
+
+### Communication
+1. **Be concise** - Brief status updates during execution, detailed summary at end
+2. **Show confidence** - Indicate certainty level when making recommendations
+3. **Full URLs in output** - Always print complete PR URLs (e.g., `https://github.com/org/repo/pull/123`)
+4. **Clear status indicators** - Use ✅, ❌, ⚠️ to show success, failure, warnings
+
+---
+
+## 📋 Quality Standards
+
+### Test Execution
+**Required:** Always attempt to discover and run tests before creating PRs.
+
+**Test Failure Handling:**
+- **If tests PASS** ✅ - Proceed with PR creation, note success in PR description
+- **If tests FAIL** ❌ - **Still create PR** but:
+  - Include failure details in PR description
+  - Add warning labels if possible
+  - Document which tests failed and error messages
+  - Include note: "⚠️ Tests failed - manual review required before merge"
+- **If NO tests found** ⚠️ - Create PR with note: "No automated tests discovered - manual testing required"
+- **If tests can't run** ⚠️ - Create PR with error details: "Tests could not execute: [reason]"
+
+**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.
+
+### Commit Standards
+- **Use conventional commits** format:
+  ```
+  fix(cve): CVE-YYYY-XXXXX - <package-name>
+
+  - Update <package> from X.X.X to Y.Y.Y
+  - Addresses vulnerability in <component>
+  - Breaking changes: [if any]
+
+  Resolves: JIRA-123, JIRA-456
+  ```
+- **Include Co-authored-by** for AI assistance:
+  ```
+  Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
+  ```
+
+### PR Description Standards
+Every PR must include:
+1. **CVE Details** - ID, severity, CVSS score, affected versions
+2. **Fix Summary** - What changed and why
+3. **Test Results** - Status, command, output (even if failed)
+4. **Breaking Changes** - Analysis of compatibility impacts
+5. **Jira References** - Plain text issue IDs (no hyperlinks)
+6. **Verification Steps** - Checklist for reviewers
+7. **Risk Assessment** - Low/Medium/High with justification
+
+---
+
+## 🎯 Workflow-Specific Rules
+
+### CVE Verification
+1. **Never apply fixes blindly** - Always verify CVE exists in current code
+2. **Use correct toolchain** - For Go stdlib CVEs, use `GOTOOLCHAIN=go<version>` matching repo's go.mod
+3. **Check all repositories** - If component maps to multiple repos, verify and fix each independently
+
+### Duplicate Prevention
+1. **Check for existing PRs** with: `gh pr list --repo X --state open --base Y --search "CVE-ID"`
+2. **Use `--base` parameter** to scope search to specific target branch
+3. **Skip if PR exists** - Document in `artifacts/cve-fixer/fixes/existing-pr-CVE-*.md`
+
+### Multi-Repository Handling
+1. **Process independently** - Each repository gets its own clone, branch, scan, fix, test, and PR
+2. **Upstream first** - When fixing both upstream and downstream, process upstream first
+3. **Track separately** - Maintain separate artifacts and reports per repository
+
+### Ignored CVEs
+Respect ignore patterns in Jira comments:
+- `cve-automation-ignore`
+- `skip-cve-automation`
+- `ignore-cve-automation`
+- `automation-ignore-cve`
+
+When found, skip the CVE and document why.
+
+---
+
+## 🔧 Automation Support
+
+### Scheduled/Unattended Runs
+This workflow is designed for scheduled automation (GitHub Actions, Ambient scheduled sessions).
+
+**Automation Mode Behavior:**
+- ✅ Automatic PR creation (no manual approval gates)
+- ✅ Continue on test failures (create PR anyway with failure details)
+- ✅ Skip CVEs that are already fixed or have open PRs
+- ✅ Save all output to artifacts (user reviews PRs, not logs)
+- ✅ Clean up `/tmp` after completion
+
+**Why No Manual Approval Gate:**
+1. PRs are the review mechanism - user approves by merging
+2. Scheduled runs require unattended operation
+3. Bad PRs can simply be closed (no harm done)
+4. All context is in PR description for informed review
+
+### Interactive Runs
+When user runs `/cve.fix` interactively:
+- ✅ Same behavior as automated runs (consistency)
+- ✅ Print PR URLs to console for easy access
+- ✅ Show summary of created/skipped PRs
+- ✅ User can review PRs immediately if desired
+
+---
+
+## 📊 Success Criteria
+
+A successful workflow execution means:
+
+1. ✅ **All CVEs processed** - None skipped due to errors
+2. ✅ **Correct PRs created** - Only for CVEs that actually exist and have no open PRs
+3. ✅ **Tests attempted** - Even if they fail, results are documented
+4. ✅ **Complete artifacts** - Reports saved for every action taken
+5. ✅ **Clean state** - `/tmp` directories cleaned up
+6. ✅ **Clear output** - User knows exactly what happened and what to review
+
+---
+
+## 🛡️ Error Handling
+
+### When Things Go Wrong
+
+**Git authentication fails:**
+- Try all available credential methods (gh auth, GITHUB_TOKEN, SSH)
+- If all fail, document the issue and skip that repository
+- DO NOT prompt for credentials in automated runs
+
+**CVE scan fails:**
+- Document the error in artifacts
+- Skip that CVE/repository
+- Continue with next CVE
+
+**Test execution fails:**
+- Document test failures
+- **Create PR anyway** with failure details
+- Let user decide whether to merge
+
+**PR creation fails:**
+- Log the error
+- Save the branch name and changes
+- Include in final summary so user can manually create PR
+
+**Component not in mapping:**
+- In interactive mode: Ask user for repository information
+- In automated mode: Skip and document in artifacts
+
+---
+
+## 📝 Documentation Requirements
+
+### Artifacts to Generate
+For every CVE processed, create:
+
+1. **Fix implementation report** - `artifacts/cve-fixer/fixes/fix-implementation-CVE-*.md`
+   - Changes made
+   - Test results
+   - PR URL
+
+2. **Already-fixed report** - `artifacts/cve-fixer/fixes/already-fixed-CVE-*.md` (if CVE not present)
+   - Scan results
+   - Timestamp
+
+3. **Existing PR report** - `artifacts/cve-fixer/fixes/existing-pr-CVE-*.md` (if duplicate)
+   - Existing PR details
+   - Timestamp
+
+4. **PR summary** - `artifacts/cve-fixer/fixes/pr-creation-summary.md`
+   - All PRs created
+   - All CVEs skipped (with reasons)
+   - Test status per PR
+
+---
+
+## 🔍 Review Checklist
+
+Before completing workflow execution, verify:
+
+- [ ] No force-pushes attempted
+- [ ] No direct commits to protected branches
+- [ ] All feature branches follow naming convention
+- [ ] Every CVE has corresponding artifact (fix/skip/existing)
+- [ ] Test results documented (pass/fail/none/error)
+- [ ] PRs created only for actual fixes (not already-fixed CVEs)
+- [ ] No duplicate PRs created
+- [ ] `/tmp` directories cleaned up
+- [ ] Final summary shows all PR URLs
+- [ ] Conventional commit format used
+- [ ] PR descriptions include all required sections
+
+---
+
+## 🎓 Learning from the Bugfix Workflow
+
+This workflow draws inspiration from the [bugfix workflow](https://github.com/ambient-code/workflows/tree/main/workflows/bugfix) best practices:
+
+- Clear hard limits on dangerous operations
+- Safety-first approach to git operations
+- Comprehensive documentation requirements
+- Support for both interactive and automated execution
+- Quality standards that don't block automation
+
+---
+
+## 📞 Questions or Issues?
+
+If you encounter situations not covered by these guidelines:
+1. Err on the side of caution
+2. Document the situation in artifacts
+3. Continue with other CVEs
+4. Include the question in the final summary
+
+**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.