Skip to content

agents-cve-autofix.md

Latest commit

 

History

History
125 lines (94 loc) · 5.39 KB

agents-cve-autofix.md

File metadata and controls

125 lines (94 loc) · 5.39 KB
Raw

CVE Autofix Agent Instructions

Instructions for the AIPCC jira-autofix bot (triage and fix agents).

Jira project glossary

  • RHOAIENG — per-image downstream vulnerability trackers filed by Product Security (one issue per container image per release branch)
  • RHAIENG — aggregate upstream tracker that groups all images for a single CVE and release; this is the ticket that should be fixed

Triage: when to reject (verdict: not_fixable)

RHOAIENG Vulnerability tickets are per-image trackers. They should NOT be fixed individually.

A parent RHAIENG tracker issue is created (or will be shortly) that groups all affected images for that CVE and release. The fix is best applied once in dependencies/constraints.txt which covers all images, rather than piecemeal per-image changes to individual pyproject.toml files.

Verdict: not_fixable with reason: "Per-image RHOAIENG CVE tracker — fix is applied via the parent RHAIENG tracker which covers all images at once through constraints.txt."

RHAIENG CVE trackers: fix on downstream release branch

RHAIENG Bug/tracker tickets for CVEs must be fixed on the downstream repository and the release branch indicated in the title:

  • Repo: https://github.com/red-hat-data-services/notebooks
  • Branch: rhoai-X.Y (extract from the [rhoai-X.Y] suffix in the title)

Do NOT fix these on opendatahub-io/notebooks main. The release branch on the downstream repo is where the vulnerable pinned dependency lives. Dependencies on main are regularly updated to latest and CVEs are typically already resolved there via AIPCC index sync — on main, only add constraints.txt entries when the resolver/index sync alone cannot guarantee the floor.

Gather context from linked issues: The RHAIENG tracker blocks multiple RHOAIENG per-image child tickets. Fetch those linked issues and read their comments — they often contain useful details about which specific packages are affected, which images have the vulnerability, version constraints from Product Security, or notes from engineers who investigated earlier.

Before creating a PR: dedup checks

  1. Check dependencies/constraints.txt on the target branch — if the package constraint already exists at the required version, the fix is already present. Verdict: already_fixed.

  2. Search open PRs for the same CVE ID on the same target branch: gh pr list --repo red-hat-data-services/notebooks --search "CVE-YYYY-NNNNN" --base rhoai-X.Y --state open If a PR already exists for this CVE on the same branch, do not create another. A PR targeting a different branch does NOT count as a duplicate. Verdict: already_fixed.

Fix pattern

CVE Python dependency fixes use a single centralized file. Do NOT add override-dependencies entries to individual pyproject.toml files unless a global constraint is insufficient (see dependencies/overrides.txt or image-specific overrides in dependencies/README.md).

  1. Add one line to dependencies/constraints.txt (CVE section): 
    # RHAIENG-NNNN: CVE-YYYY-XXXXX <description>
package>=fixed_version
    Keep one line per package (most restrictive floor). Replace existing entries for the same package; do not append a ledger of historical fixes.
  2. Run make refresh-lock-files to regenerate all image lock files.
  3. Commit both the constraint file and the regenerated locks.

One PR per CVE. Never combine multiple CVEs in one PR. See existing entries in dependencies/constraints.txt for format examples.

Iteration: when to stop

If the fix is already present on the target branch (constraint exists in constraints.txt at the required version), produce verdict: no_changes. Do not push commits, do not modify files.

Operator reference: bot labels and states

The jira-autofix bot uses Jira labels as its state machine:

Label Meaning
jira-autofix Ticket ready for bot pickup
jira-autofix-review PR created, bot is iterating on feedback
jira-autofix-merged PR merged (terminal)
jira-autofix-rejected PR closed without merge (terminal)
jira-autofix-max-retries Bot hit iteration limit (terminal)
jira-autofix-blocked Bot needs human input (terminal)
no-autofix Opt-out — bot will never process this ticket

To immediately stop the bot from iterating on a ticket, add the no-autofix label. This is the fastest escape hatch and requires no code changes or PR closures.

Operator reference: verdict values

The bot produces a verdict JSON at the end of each run. Valid verdicts:

Triage verdicts (written to .triage-verdict.json):

Verdict Effect
ready Ticket gets jira-autofix label, enters fix pipeline
needs_info Bot comments asking for clarification
not_fixable Ticket labeled unsuitable for automated fixing

Autofix verdicts (written to autofix-output/.autofix-verdict.json):

Verdict Effect
committed Changes pushed, PR created or updated
already_fixed Fix already present on target branch; no PR created
no_changes Nothing to do (iteration: silently skips)
not_a_bug Ticket describes expected behavior
insufficient_info Not enough context to proceed → jira-autofix-blocked
blocked Cannot proceed (e.g., missing repo URL) → jira-autofix-blocked
research Findings posted as Jira comment, no PR