CVE Fix

Automated CVE remediation for Python dependencies. Queries Jira for CVEs, updates Pipfile and Pipfile.lock, creates MRs, and updates Jira.

Critical Lessons Learned

These are hard-won from production use. Follow them strictly:

1. •Dependency cascade: Upgrading one package often breaks others (e.g., aiohttp 3.13+ broke gql, urllib3 2.x broke boto3). Always check compatibility.md BEFORE updating.
2. •Both files must update: Always update Pipfile AND Pipfile.lock together. Missing Pipfile changes causes CI failures.
3. •Branch isolation: Always create branches from origin/main, never from another feature branch. Cross-contamination has caused multiple MR issues.
4. •Error handling: Use isinstance() checks before .get() on variables that might be error strings instead of dicts (e.g., when pipenv lock fails).
5. •Local validation: Build container + run pytest --collect-only to catch import errors from missing transitive dependencies before CI.
6. •Rebase conflicts: When multiple CVE fixes are in flight, document which packages were modified to help resolve conflicts.

Required MCP Tools

Load the developer persona first:

persona_load("developer")

Tools used: jira_search, jira_view_issue, jira_assign, jira_transition, jira_add_comment, git_fetch, git_branch_list, git_branch_create, git_checkout, git_add, git_commit, git_push, gitlab_mr_list, gitlab_mr_create, podman_build, podman_run, memory_session_log, jira_attach_session

Workflow

Phase 1: Discovery and Filtering

1. •

   Query Jira for CVEs:

   code

   jira_search(jql='"Downstream Component Name" ~ "<component>" AND type = Vulnerability AND resolution = Unresolved ORDER BY created DESC', max_results=50)
   

   Default component: automation-analytics-backend

2. •

   Fetch latest from origin with prune to get up-to-date refs.

3. •

   Check git log on origin/main (last 500 commits) to find already-merged fixes.

4. •

   Check all branches for in-progress CVE work.

5. •

   Check open MRs for existing CVE fix MRs.

6. •

   Classify each CVE into one of:

   • •Merged to main - skip (already fixed)
   • •Has open MR - skip (fix in review)
   • •Has branch, no MR - resumable (prioritize these)
   • •Unfixed - needs work from scratch
7. •

   Select CVEs to process: Prioritize resumable CVEs over new ones. Default: process 1 at a time.

Phase 2: CVE Details and Validation

1. •

   Get CVE details from Jira using jira_view_issue.

2. •

   Extract CVE info - see cve-parsing.md for detailed extraction strategies. Need:

   • •CVE ID (e.g., CVE-2024-12345)
   • •Affected package name (normalized to lowercase with hyphens)
   • •Summary, CVSS score, severity
3. •

   Validate the CVE:

   • •Must have both CVE ID and affected package
   • •Reject non-pip packages (python, linux, glibc, java, nodejs, gcc, etc.) - these need different remediation (base image update)
4. •

   Check compatibility requirements - consult compatibility.md for known breaking changes when upgrading the affected package.

Phase 3: Resume Logic (for existing branches)

If resuming a CVE that already has a branch:

1. •Find the existing branch name by searching branch list for the issue key.
2. •Check it out (try local first, then origin/<branch>).
3. •Check commits ahead of origin/main to detect what's already done.
4. •Check if Pipfile/Pipfile.lock are already committed.
5. •Check if branch is already pushed to remote.
6. •Skip completed steps in subsequent phases.

Phase 4: Jira Updates

1. •Resolve Jira username from config (must be email format, e.g., user@redhat.com).
2. •Assign issue to current user.
3. •Set acceptance criteria if not already present:
   code

   * CVE-XXXX vulnerability in <package> is remediated
   * <package> is updated to a version that fixes CVE-XXXX
   * Pipfile and Pipfile.lock are updated with the new version
   * No regressions in existing functionality
   * CI pipeline passes
   

4. •Transition to In Progress.

Phase 5: Branch Creation

Skip this phase if resuming (already on feature branch).

1. •Verify working directory is clean - abort if uncommitted changes exist.
2. •Checkout main and hard reset to origin/main (critical for branch isolation).
3. •Create feature branch: <ISSUE_KEY>-<cve-id>-<package> (e.g., AAP-12345-cve-2025-69223-aiohttp).
4. •Verify branch base matches origin/main exactly (merge-base check).

Phase 6: Update Pipfile and Pipfile.lock

Skip if already committed (resume case).

This uses a container-based approach to resolve package versions with the correct Python version:

1. •

   Read Python version from the project's Pipfile [requires] section.

2. •

   Map to UBI container image:

   Python	Image
   3.9	registry.access.redhat.com/ubi9/python-39
   3.11	registry.access.redhat.com/ubi9/python-311
   3.12	registry.access.redhat.com/ubi9/python-312

3. •

   Create temp workspace in /tmp/cve-fix-* with:

   • •Minimal Pipfile containing just the target package (and any companion packages)
   • •Containerfile based on the UBI image
4. •

   Build container with podman_build (installs pip + pipenv).

5. •

   Run pipenv lock inside the container with the temp dir volume-mounted.

6. •

   Extract new version and hashes from the generated Pipfile.lock.

7. •

   Update project Pipfile:

   • •If package exists: update to >= <new_version> with CVE comment
   • •If package missing: add after [packages] header
   • •Update companion packages too if needed
8. •

   Update project Pipfile.lock:

   • •Update version and hashes for main package
   • •Update companion packages
   • •Preserve all other packages unchanged
9. •

   Clean up temp directory.

Phase 7: Commit and Push

1. •Build commit message using format: <ISSUE_KEY> - fix(deps): update <package> <old> -> <new> to fix <CVE-ID>
2. •Stage Pipfile and Pipfile.lock.
3. •Commit the changes.
4. •Push branch to origin with --set-upstream.

Phase 8: Create MR

1. •

   Build MR title: <ISSUE_KEY> - fix(security): fix <CVE-ID> in <package>

2. •

   Build MR description with sections:

   • •Summary (security fix for CVE in package)
   • •CVE Details (ID, package, severity, CVSS with NVD link)
   • •Changes (Pipfile and Pipfile.lock updates, companion packages)
   • •Compatibility Notes (if applicable)
   • •Jira link
   • •Testing checklist
   • •Completion checklist
3. •

   Create MR via gitlab_mr_create (not draft).

Phase 9: Post-MR Actions

1. •Add Jira comment with MR link and change summary.
2. •Notify team via Slack using the notify_team skill with cve_fix template.
3. •Log to session memory.
4. •Attach session context to the Jira issue for audit trail.
5. •Scan fixed image via scan_vulnerabilities skill (if commit SHA available).
6. •Restore developer persona after scan.

Dry Run Mode

When dry_run is true, show what would be done without making any changes. Display the CVE status summary table and planned steps.

Output Summary

Present results as a markdown table:

For each processed CVE, show:

• •Issue key, CVE ID, package, severity, CVSS
• •Branch name, Python version
• •Pipfile changes (old version -> new version)
• •Companion package updates
• •MR link

Additional Resources

• •Package compatibility requirements: See references/compatibility.md for known breaking changes between packages
• •CVE info extraction from Jira: See references/cve-parsing.md for multi-strategy parsing of CVE IDs and affected packages from Jira issue text