fix: address PR review feedback on CVE fixer workflow

vmrh21 · claude · vmrh21 · commit 9373f43fa9f8 · 2026-03-29T19:05:10.000-04:00
- Update JQL query: remove project=RHOAIENG, add labels=SecurityTracking
  to make workflow usable by teams outside of RHOAIENG
- Add case-insensitive component name lookup against mapping file
- Add llm-d component with inference-scheduler and routing-sidecar repos
- Add llm-d Batch Gateway and auto-scaler repos under llm-d component
- Add AI Evaluations component (eval-hub repos)
- Clean up metadata: remove stale count fields from mapping file
- Fix ambient.json startupPrompt: trim verbose FIRST TIME USER checklist
- Fix README example JSON to match actual mapping schema
- Fix README ProdSec contact to reference feature refinement process
- Remove RHOAIENG-specific references to make docs team-agnostic

Co-Authored-By: Claude Sonnet 4.6 (1M context) &lt;noreply@anthropic.com&gt;
diff --git a/workflows/cve-fixer/.ambient/ambient.json b/workflows/cve-fixer/.ambient/ambient.json
@@ -2,7 +2,7 @@
   "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\nNote: Commands will guide you through required setup steps on first use. If the user's component is not in component-repository-mappings.json, direct them to the \"Team Onboarding\" section in README.md.",
-  "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⚠️ FIRST TIME USER?\nNew teams must complete onboarding before using this workflow. See README.md section \"Team Onboarding\" for requirements:\n- Component-to-repository mapping must be configured\n- ProdSec team must set up your Jira component\n- Jira API credentials required (JIRA_API_TOKEN, JIRA_EMAIL)\n- GitHub CLI authentication required\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?",
+  "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\nFirst time? See README.md → \"Team Onboarding\" for setup requirements.\n\nWhat would you like to accomplish today?",
   "results": {
     "Jira CVE Issues": "artifacts/cve-fixer/find/**/*.md",
     "Fix Implementations": "artifacts/cve-fixer/fixes/**/*"
diff --git a/workflows/cve-fixer/.claude/commands/cve.find.md b/workflows/cve-fixer/.claude/commands/cve.find.md
@@ -99,8 +99,19 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
 
    b. Construct JQL query and execute API call:
    ```bash
+   # Normalize component name with case-insensitive lookup against mapping file
+   MAPPING_FILE="$(dirname "$0")/../component-repository-mappings.json"
+   if [ -f "$MAPPING_FILE" ]; then
+     CANONICAL_NAME=$(jq -r --arg name "${COMPONENT_NAME}" \
+       '.components | keys[] | select(ascii_downcase == ($name | ascii_downcase))' \
+       "$MAPPING_FILE" | head -1)
+     if [ -n "$CANONICAL_NAME" ]; then
+       COMPONENT_NAME="$CANONICAL_NAME"
+     fi
+   fi
+
    # Build JQL query
-   JQL="project = RHOAIENG AND component = \"${COMPONENT_NAME}\" AND summary ~ \"CVE*\""
+   JQL="component = \"${COMPONENT_NAME}\" AND summary ~ \"CVE*\" AND labels = SecurityTracking"
 
    # Append resolved filter if --ignore-resolved flag was provided
    if [ "$IGNORE_RESOLVED" = "true" ]; then
@@ -332,7 +343,7 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
    **Ignored Issues:** ${IGNORED_COUNT}
 
    ## Query Parameters
-   - **JQL Query:** project = RHOAIENG AND component = "${COMPONENT_NAME}" AND summary ~ "CVE*"$( [ "$IGNORE_RESOLVED" = "true" ] && echo ' AND status not in ("Resolved")' )
+   - **JQL Query:** component = "${COMPONENT_NAME}" AND summary ~ "CVE*" AND labels = SecurityTracking$( [ "$IGNORE_RESOLVED" = "true" ] && echo ' AND status not in ("Resolved")' )
    - **Columns:** KEY, SUMMARY, STATUS, PRIORITY, CREATED, COMPONENTS
    - **Jira Instance:** ${JIRA_BASE_URL}
 
diff --git a/workflows/cve-fixer/README.md b/workflows/cve-fixer/README.md
@@ -24,44 +24,30 @@ Before your team can use the CVE Fixer workflow, the following setup must be com
 Your team's Jira components must be mapped to GitHub repositories in `component-repository-mappings.json`.
 
 **What you need to provide:**
-- Jira component name (as it appears in RHOAIENG project)
-- GitHub repository URLs (upstream and/or downstream)
-- Primary target branch for each repository
-- Build location (directory containing go.mod, package.json, etc.)
+- Jira component name (as it appears in your Jira project)
+- GitHub repository URLs (upstream, midstream, and/or downstream)
+- Default and active release branches for each repository
 
 **Example mapping:**
 ```json
 {
   "Your Component Name": {
+    "container_to_repo_mapping": {
+      "rhoai/odh-your-container-rhel9": "org/upstream-repo"
+    },
     "repositories": {
       "org/upstream-repo": {
         "github_url": "https://github.com/org/upstream-repo",
         "default_branch": "main",
-        "protected_branches": ["main", "release"],
-        "active_release_branches": [],
-        "branch_strategy": "Fix in main, cherry-pick to release branches as needed",
-        "cve_fix_workflow": {
-          "primary_target": "main",
-          "backport_targets": "Active release branches",
-          "automation": "Auto-create PRs to main",
-          "manual_intervention": "Cherry-pick to release branches"
-        },
-        "build_location": ".",
+        "active_release_branches": ["release-1.0"],
+        "branch_strategy": "Fix in main. Release branches follow pattern release-X.Y.",
         "repo_type": "upstream"
       },
       "org/downstream-repo": {
         "github_url": "https://github.com/org/downstream-repo",
-        "default_branch": "rhoai-2.19",
-        "protected_branches": ["rhoai-2.19"],
-        "active_release_branches": ["rhoai-2.19"],
-        "branch_strategy": "Direct fixes to release branch",
-        "cve_fix_workflow": {
-          "primary_target": "rhoai-2.19",
-          "backport_targets": "rhoai-2.19",
-          "automation": "Auto-create PRs to release branch",
-          "manual_intervention": "Manual backport from upstream if needed"
-        },
-        "build_location": ".",
+        "default_branch": "main",
+        "active_release_branches": ["rhoai-3.4"],
+        "branch_strategy": "Fork of midstream. RHOAI release branches follow pattern rhoai-X.Y.",
         "repo_type": "downstream"
       }
     }
@@ -72,11 +58,11 @@ Your team's Jira components must be mapped to GitHub repositories in `component-
 #### 2. ProdSec Team Coordination
 
 The Product Security (ProdSec) team must:
-- Create Jira component for your team in the RHOAIENG project
+- Create Jira component for your team in your Jira project
 - Configure CVE issue templates for your component
 - Set up automated CVE discovery and Jira issue creation
 
-**Contact:** Your ProdSec team representative to request component setup
+**Contact:** Make sure your component repos are actively scanned by ProdSec team. If your component is not onboarded please follow the feature refinement process.
 
 #### 3. GitHub Access Configuration
 
@@ -99,7 +85,7 @@ export GITHUB_TOKEN="your-personal-access-token"
 #### 4. Jira API Access
 
 Each team member using the workflow needs:
-- Red Hat Jira account with access to RHOAIENG project
+- Red Hat Jira account with access to your Jira project
 - Jira API token for authentication
 - Read access to CVE issues for their component
 
@@ -251,18 +237,23 @@ The workflow uses `component-repository-mappings.json` to map Jira components to
 ```json
 {
   "Model as a Service": {
+    "container_to_repo_mapping": {
+      "rhoai/odh-maas-api-rhel9": "opendatahub-io/models-as-a-service"
+    },
     "repositories": {
       "opendatahub-io/models-as-a-service": {
         "github_url": "https://github.com/opendatahub-io/models-as-a-service",
-        "repo_type": "upstream",
-        "primary_target": "main",
-        "build_location": "."
+        "default_branch": "main",
+        "active_release_branches": [],
+        "branch_strategy": "Fix in main.",
+        "repo_type": "upstream"
       },
       "red-hat-data-services/models-as-a-service": {
         "github_url": "https://github.com/red-hat-data-services/models-as-a-service",
-        "repo_type": "downstream",
-        "primary_target": "rhoai-2.19",
-        "build_location": "."
+        "default_branch": "rhoai-3.0",
+        "active_release_branches": ["rhoai-3.0"],
+        "branch_strategy": "Fork of midstream. Fixes backported from upstream.",
+        "repo_type": "downstream"
       }
     }
   }
diff --git a/workflows/cve-fixer/component-repository-mappings.json b/workflows/cve-fixer/component-repository-mappings.json
@@ -374,14 +374,155 @@
           "github_url": "https://github.com/opendatahub-io/codeflare-operator"
         }
       }
+    },
+    "llm-d": {
+      "container_to_repo_mapping": {
+        "rhoai/odh-llm-d-inference-scheduler-rhel9": "opendatahub-io/llm-d-inference-scheduler",
+        "rhoai/odh-llm-d-routing-sidecar-rhel9": "red-hat-data-services/llm-d-routing-sidecar",
+        "rhoai/odh-workload-variant-autoscaler-controller-rhel9": "opendatahub-io/workload-variant-autoscaler"
+      },
+      "repositories": {
+        "llm-d/llm-d-inference-scheduler": {
+          "github_url": "https://github.com/llm-d/llm-d-inference-scheduler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release-0.5",
+            "release-0.6"
+          ],
+          "branch_strategy": "Fix in main. Release branches follow pattern release-X.Y.",
+          "repo_type": "upstream"
+        },
+        "opendatahub-io/llm-d-inference-scheduler": {
+          "github_url": "https://github.com/opendatahub-io/llm-d-inference-scheduler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release-0.2",
+            "release-0.3.1",
+            "release-v0.4",
+            "stable-2.x"
+          ],
+          "branch_strategy": "Fork of upstream llm-d/llm-d-inference-scheduler. Synced via sync branches. ODH release branches via Konflux replicator.",
+          "repo_type": "midstream"
+        },
+        "red-hat-data-services/llm-d-inference-scheduler": {
+          "github_url": "https://github.com/red-hat-data-services/llm-d-inference-scheduler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "rhoai-3.3",
+            "rhoai-3.4",
+            "rhoai-3.4-ea.1",
+            "rhoai-3.4-ea.2"
+          ],
+          "branch_strategy": "Fork of midstream. RHOAI release branches follow pattern rhoai-X.Y.",
+          "repo_type": "downstream"
+        },
+        "red-hat-data-services/llm-d-routing-sidecar": {
+          "github_url": "https://github.com/red-hat-data-services/llm-d-routing-sidecar",
+          "default_branch": "main",
+          "active_release_branches": [
+            "rhoai-2.25",
+            "rhoai-3.0",
+            "rhoai-3.2"
+          ],
+          "branch_strategy": "Fork of upstream (now archived). Downstream only — upstream code migrated into llm-d-inference-scheduler. No branches beyond rhoai-3.2.",
+          "repo_type": "downstream",
+          "notes": "Upstream llm-d/llm-d-routing-sidecar is archived; code moved to llm-d-inference-scheduler (cmd/pd_sidecar). This downstream repo may be phased out in future releases."
+        },
+        "llm-d-incubation/batch-gateway": {
+          "github_url": "https://github.com/llm-d-incubation/batch-gateway",
+          "default_branch": "main",
+          "active_release_branches": [],
+          "branch_strategy": "Fix in main. No formal release branching documented.",
+          "repo_type": "upstream"
+        },
+        "opendatahub-io/batch-gateway": {
+          "github_url": "https://github.com/opendatahub-io/batch-gateway",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release-v0.5"
+          ],
+          "branch_strategy": "Fork of upstream llm-d-incubation/batch-gateway.",
+          "repo_type": "midstream"
+        },
+        "red-hat-data-services/batch-gateway": {
+          "github_url": "https://github.com/red-hat-data-services/batch-gateway",
+          "default_branch": "main",
+          "active_release_branches": [
+            "rhoai-3.4",
+            "rhoai-3.4-ea.1",
+            "rhoai-3.4-ea.2"
+          ],
+          "branch_strategy": "Fork of midstream. RHOAI release branches follow pattern rhoai-X.Y.",
+          "repo_type": "downstream"
+        },
+        "llm-d/llm-d-workload-variant-autoscaler": {
+          "github_url": "https://github.com/llm-d/llm-d-workload-variant-autoscaler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release-0.4.2"
+          ],
+          "branch_strategy": "Fix in main. Release branches follow pattern release-X.Y.Z.",
+          "repo_type": "upstream"
+        },
+        "opendatahub-io/workload-variant-autoscaler": {
+          "github_url": "https://github.com/opendatahub-io/workload-variant-autoscaler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release-v0.5"
+          ],
+          "branch_strategy": "Fork of upstream llm-d/llm-d-workload-variant-autoscaler. Note: repo name differs from upstream (no llm-d- prefix).",
+          "repo_type": "midstream"
+        },
+        "red-hat-data-services/workload-variant-autoscaler": {
+          "github_url": "https://github.com/red-hat-data-services/workload-variant-autoscaler",
+          "default_branch": "main",
+          "active_release_branches": [
+            "rhoai-3.4",
+            "rhoai-3.4-ea.1",
+            "rhoai-3.4-ea.2"
+          ],
+          "branch_strategy": "Fork of midstream. RHOAI release branches follow pattern rhoai-X.Y.",
+          "repo_type": "downstream"
+        }
+      }
+    },
+    "AI Evaluations": {
+      "container_to_repo_mapping": {},
+      "repositories": {
+        "eval-hub/eval-hub": {
+          "github_url": "https://github.com/eval-hub/eval-hub",
+          "default_branch": "main",
+          "active_release_branches": [],
+          "branch_strategy": "Fix in main. Feature branches follow pattern feature/name or fix/issue.",
+          "repo_type": "upstream"
+        },
+        "opendatahub-io/eval-hub": {
+          "github_url": "https://github.com/opendatahub-io/eval-hub",
+          "default_branch": "main",
+          "active_release_branches": [
+            "release/odh-3.4",
+            "stable"
+          ],
+          "branch_strategy": "Fork of upstream eval-hub/eval-hub.",
+          "repo_type": "midstream"
+        },
+        "red-hat-data-services/eval-hub": {
+          "github_url": "https://github.com/red-hat-data-services/eval-hub",
+          "default_branch": "main",
+          "active_release_branches": [
+            "rhoai-3.4",
+            "rhoai-3.4-ea.1",
+            "rhoai-3.4-ea.2"
+          ],
+          "branch_strategy": "Fork of midstream. RHOAI release branches follow pattern rhoai-X.Y.",
+          "repo_type": "downstream"
+        }
+      }
     }
   },
   "metadata": {
     "description": "Component to repository and branch mappings for CVE fix workflow automation",
-    "purpose": "Maps RHOAI Jira components to GitHub repositories and their branch strategies for automated CVE patching",
-    "last_updated": "2026-03-16",
-    "components_analyzed": 7,
-    "components_with_branch_info": 1,
-    "components_pending_branch_analysis": 6
+    "purpose": "Maps Jira components to GitHub repositories and their branch strategies for automated CVE patching",
+    "last_updated": "2026-03-29"
   }
 }
