Rank Socket remediation candidates by simplicity

[ulziibay-kernel]

Summary

• Prefer direct fixed-version Socket fix plans before transitive-only plans.
• Keep remediation batches small, but make the single selected advisory more likely to apply and confirm cleanly.
• Add a regression test covering direct-vs-transitive candidate ordering.

Test plan

• python3 -m unittest scripts.test_vuln_remediation
• Parsed reusable workflow YAML
• git diff --check

Made with Cursor

---

Note

Low Risk
Heuristic ordering in remediation helper scripts only; no auth, data, or production runtime paths.

Overview
Socket remediation build_context now orders plan-only vulnerabilities by a simplicity score instead of arbitrary dict order, so capped batches (max_fixes) favor fixes that are easier to apply and confirm.

plan_complexity_score ranks each plan entry by: direct fixedVersion bumps first, then fewer responsible packages, fewer transitive fixes, more direct updates, with vuln_id as a stable tie-break. sorted_plan_entries wraps that sort for the second pass over the fix plan.

A regression test asserts that with max_fixes=1, a direct-dependency advisory wins over a transitive-only plan even when the transitive id would sort first alphabetically.

^{Reviewed by Cursor Bugbot for commit a50ec90. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Changes the automated security bot's vulnerability selection logic to prefer simpler, more-reviewable fixes (direct dependency version bumps) over complex transitive-only plans, increasing the chance a remediation PR is created and merged cleanly.

Intended effect:

• Vulnerability Remediation Self-Test: baseline 100% success rate (11/11 recent runs); confirmed if it stays green on all subsequent pushes to main — already passed twice post-merge (20:24:55 and 20:25:16 UTC Jun 1)
• Downstream remediation PRs: baseline success conclusion on kernel/kernel-browser and other repos (May 28); confirmed if newly triggered runs complete successfully and produce PRs with direct dep bumps

Risks:

• Sorting crash on unexpected Socket API shape — Vulnerability Remediation triage job failure (conclusion = failure), alert if any downstream repo shows a new failure conclusion within 48h
• New sort order picks a harder-to-apply fix — confirm_fix failures in confirmation-result.json, surfaced as Vulnerability Remediation fix job skipping PR creation; alert if remediation runs complete success but no security/vuln-remediation PR is created for a repo that previously produced one
• Unit test regression — Self-Test conclusion = failure, alert if any run fails

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor

[firetiger-agent]

Inconclusive after 72h monitoring window — no executor telemetry received.

Per-environment outcomes:

• Self-Test workflow: monitoring data not received
• Downstream remediation workflows: monitoring data not received

Evidence:

• No telemetry signals collected within monitoring window (Jun 1 20:25 UTC — Jun 4 20:25 UTC)

The monitoring window has closed. The sorting change to vuln_remediation.py took effect on merge (Jun 1 20:25 UTC), and the Self-Test already passed twice post-merge (20:24:55 and 20:25:16 UTC). However, no automated executor check-ins arrived with downstream workflow run data or detailed signal analysis. The change appears to have caused no immediate breakage (no visible workflow failures in the GitHub events data at plan creation time), but a conclusive result requires executor telemetry.

View monitor