fix(ci): require uv >=0.8.6 for VULN-95456

[shuningc]

Summary

Remediate VULN-95456 / CVE-2025-13327 by raising the locked uv package in root poetry.lock to ≥0.9.6 (resolved 0.12.3), exporting a durable floor via crewai/all extras, and aligning CI/subproject uv toolchain pins.

FOSSA flags uv 0.8.9 in root poetry.lock (transitive via crewai → uv >=0.4.25 under crewai/all extras). Executable-only pins do not close the ticket; the lockfile entry must change.

Dependency / lock changes

Package	main	This PR
uv (lock, crewai/all)	0.8.9	0.12.3

Root pyproject.toml floor (durable remediation):

• [project.optional-dependencies]: uv (>=0.9.6); python_version < '3.14' in crewai and all (matches crewai/litellm siblings)
• [tool.poetry.dependencies]: uv = { version = ">=0.9.6", optional = true, python = ">=3.11,<3.14" }
• Lock marker: python_version <= "3.13" and (extra == "crewai" or extra == "all") — avoids shipping uv-only on Python 3.14 when crewai/litellm are excluded

Merged from main: mcp (>=1.27.2,<2) extra retained alongside the new uv floor (no conflict with this remediation).

CI / subproject toolchain

Location	Change
.github/workflows/ci-tests-splunk-ao-a2a.yaml	setup-uv version: "0.12.1" (exact pin)
.github/workflows/ci-tests-splunk-ao-adk.yaml	setup-uv version: "0.12.1" (aligned with a2a)
splunk-ao-adk/pyproject.toml	[tool.uv] required-version = ">=0.9.6"
splunk-ao-a2a/pyproject.toml	[tool.uv] required-version = ">=0.9.6"

CI pins govern the uv executable; the poetry.lock change is what closes the FOSSA finding on the Python package artifact.

Fixed version rationale

Source	Detail
Ticket	VULN-95456
CVE	CVE-2025-13327 (ZIP parsing differential / stacked local file entries; user interaction required)
Affected	uv ≤0.8.5 (locked 0.8.9 still flagged; remediation 0.9.6+)
Pin applied	>=0.9.6 floor; lock resolves 0.12.3
Related advisory	GHSA-8qf3-x8v5-2pj8 (same class of issue; fixed in 0.9.6+)

Review follow-ups addressed

• Root poetry.lock updated so scanned uv is ≥0.9.6 (not 0.8.9)
• python_version < '3.14' marker on uv in PEP 621 + Poetry tables (matches crewai/litellm)
• CI setup-uv exact pin 0.12.1 in both adk and a2a workflows
• splunk-ao-a2a/pyproject.toml [tool.uv] structure fixed (no stray key under [project.urls])
• Merge conflict with main resolved (mcp extra + regenerated lock)

Notes

• Exporting uv>=0.9.6 via splunk-ao[crewai]/[all] intentionally prevents downstream consumers from resolving crewai's permissive uv>=0.4.25 back to a vulnerable build; alternative (Poetry group-only constraint) would fix the lock scan but not protect consumers — this PR chose the extra for ticket closure + downstream protection.
• Exact CI pin (0.12.1) vs lock resolution (0.12.3) is intentional: CI tests a known toolchain; lock picks latest satisfying >=0.9.6 at resolve time.

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — PR does not remediate VULN-95456: the flagged uv 0.8.9 in poetry.lock is untouched, and the applied floor (>=0.8.6) is below the required remediation (0.9.6).

General Comments

• 🔴 critical (bug): This PR does not actually remediate VULN-95456 and the ticket will not close.

The ticket (CVE-2025-13327) flags uv 0.8.9 with origin path poetry.lock and remediation 0.9.6. In this repo poetry.lock pins uv 0.8.9 (line 5636), pulled in transitively as an optional dependency of crewai (uv = ">=0.4.25", poetry.lock line 811) under the crewai/all extras. This PR does not modify poetry.lock at all, so the scanner will continue to report the vulnerable uv 0.8.9.

The PR body's claims that "uv is not a Python package dependency in this repo" and "No lockfile regeneration needed (poetry.lock/uv.lock unaffected)" are both incorrect. To close the ticket, poetry.lock must be regenerated so the transitive uv is >= 0.9.6 (e.g. add a floor on uv and re-lock, or constrain the transitive dependency), then verify FOSSA no longer flags it.

Separately, the CVE in the PR body (CVE-2025-54368, fixed in 0.8.6) does not match the ticket's CVE (CVE-2025-13327, remediation 0.9.6). Please reconcile which vulnerability is being remediated; addressing only CVE-2025-54368 leaves VULN-95456 open.

[fercor-cisco]

🟠 major (bug): Same as the a2a subproject: this floor >=0.8.6 is below the ticket's required remediation of uv 0.9.6, and required-version controls the uv executable, not the uv 0.8.9 locked in poetry.lock that the scanner actually flags.

Suggested change

	required-version = ">=0.8.6"
	required-version = ">=0.9.6"

🤖 Generated by the Astra agent

[shuningc]

Resolved — splunk-ao-adk/pyproject.toml:27 is now required-version = ">=0.9.6".

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — Does not remediate the flagged poetry.lock uv 0.8.9, ships a broken TOML edit in a2a, and uses a floor below the ticket's required 0.9.6.

General Comments

• 🟠 major (security): This change does not remediate the finding VULN-95456 actually reports. The ticket flags uv 0.8.9 locked in poetry.lock (originPath=poetry.lock), which is a transitive dependency pulled in by crewai (crewai 1.6.1 → uv = ">=0.4.25", under the crewai/all optional extras). Neither the [tool.uv] required-version keys nor the CI astral-sh/setup-uv version input touch that locked package — both only govern which uv executable is used, not the uv Python distribution resolved into poetry.lock. As a result poetry.lock still pins uv 0.8.9, FOSSA will keep flagging it, and the ticket will not close. This is exactly what the existing review threads point out. To actually remediate, regenerate poetry.lock so uv resolves to >=0.9.6 (e.g. bump/relock the crewai transitive), or drop/VEX the transitive dependency. The PR body's claim that "No lockfile regeneration needed" is precisely why the fix does not land.
• 🟡 minor (question): There is a CVE mismatch between this PR and the ticket. The PR body remediates CVE-2025-54368 (uv ≤0.8.5, fixed 0.8.6) and therefore chose the >=0.8.6 floor, but VULN-95456 is CVE-2025-13327 with a mandated remediation of uv 0.9.6. Please reconcile: the floors and lockfile target should be driven by the ticket's 0.9.6 remediation, not 0.8.6.

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — The changes do not touch the root poetry.lock uv 0.8.9 entry that VULN-95456 actually flags, so the vulnerability is not remediated.

General Comments

• 🟠 major (security): This PR does not remediate VULN-95456. The ticket flags uv 0.8.9 with originPath: poetry.lock and remediation: 0.9.6. In this repo, uv 0.8.9 is locked in the root poetry.lock (lines 5635-5661) as a transitive dependency of crewai (uv >=0.4.25, line 811), gated behind the crewai/all extras. FOSSA scans that lockfile entry.

All four changed files govern the uv executable, not that locked package:

• setup-uv version: ">=0.9.6" controls which uv binary CI installs.
• [tool.uv] required-version constrains the uv binary used for local dev in the two subprojects.

Neither rewrites poetry.lock, so the scanned uv 0.8.9 entry — and therefore the finding — remains after this PR merges. The PR body's note "No lockfile regeneration needed (poetry.lock unaffected)" confirms the gap. To actually close the ticket you need to raise the locked uv to >=0.9.6 in the root project (e.g. add a direct uv = ">=0.9.6" constraint / bump the crewai resolution and run poetry lock) so poetry.lock no longer pins 0.8.9. The three prior review threads raised this same point; the version numbers were fixed but the root artifact was never changed.

• 🟡 minor (documentation): The PR body states "uv is not a Python package dependency in this repo — it is used as a CI/dev tool only." That is incorrect: uv 0.8.9 is a transitive package dependency present in the root poetry.lock (via crewai's uv >=0.4.25), and that lockfile entry is exactly what the FOSSA scan reports. This mistaken premise is why the chosen remediation (executable pins) doesn't address the finding.
• 🟡 minor (question): CVE mismatch: the PR body cites CVE-2025-54368 / GHSA-8qf3-x8v5-2pj8, but Jira VULN-95456 cites CVE-2025-13327. Both describe the same uv ZIP parsing-differential issue with remediation 0.9.6, but the identifiers should be reconciled so the ticket's VEX fields reference the correct CVE.

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-5). It may contain mistakes.

Verdict: request_changes — The core remediation (uv 0.8.9 → 0.12.1 with a >=0.9.6 floor) is correct, but the new uv dependency is missing the python_version < '3.14' marker that its sibling crewai/litellm entries carry, which ships a wrong extra in published metadata; the PR description also directly contradicts the diff.

General Comments

• 🟠 major (documentation): The PR description no longer matches the diff, and it contradicts it on exactly the points a reviewer would rely on to approve a security fix:

• "uv is not a Python package dependency in this repo — it is used as a CI/dev tool only." — False. uv is a transitive dependency of crewai (crewai 1.6.1 requires uv >= 0.4.25), which is why FOSSA flagged it via poetry.lock. This PR itself now declares it as a direct optional dependency.

• "No lockfile regeneration needed (poetry.lock / uv.lock unaffected)." — False. poetry.lock is the largest part of this diff (uv 0.8.9 → 0.12.1, plus extras and content-hash changes).

• The ## Changes section omits pyproject.toml and poetry.lock entirely — i.e. it omits the only changes that actually remediate the ticket. The two things it does list (setup-uv version, [tool.uv] required-version) are both hardening measures that, as the earlier review comments correctly noted, do not affect the scanned finding.

• The title still says require uv >=0.8.6 while every changed line says >=0.9.6.

• The rationale table cites CVE-2025-54368 / GHSA-8qf3-x8v5-2pj8; the Jira ticket cites CVE-2025-13327. These may be linked advisories, but the mismatch should be reconciled so the VEX fields on the ticket can be set against the right identifier.

Please rewrite the description and title to describe the change that is actually here. For a security remediation that will be audited against the ticket, a description that says the opposite of what the diff does is a real problem, not a cosmetic one.

• 🟡 minor (question): This PR promotes uv from a transitive dependency of crewai to a directly declared, published optional dependency of splunk-ao (via [project.optional-dependencies], which is static metadata and ships in the wheel — note [project] declares dynamic = ["dependencies"] but not dynamic optional-dependencies).

The practical consequence is that every downstream consumer of splunk-ao[crewai] / splunk-ao[all] now inherits a hard uv>=0.9.6 requirement in their resolution, forever, even after crewai itself raises its own floor. Was that intended, or is the goal only to move this repo's lockfile off the vulnerable version?

If the goal is only the latter, the narrower option is to constrain uv in [tool.poetry.dependencies] (which drives lock resolution) without adding it to the published extras lists — that fixes the scanned poetry.lock finding without permanently constraining consumers. If publishing the constraint is intended, that's a defensible choice, but it's worth stating in the description so it isn't a surprise later, and it should be revisited/removed once crewai's own uv floor is >= 0.9.6.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• splunk-ao-a2a/pyproject.toml:27-30: The [tool.uv] required-version floor is only applied to the two subprojects that have a [tool.uv] table. Several example projects also drive uv (examples/agent/langgraph-otel/README.md, examples/agent/pydantic-ai-support-agent/README.md, examples/logging-samples/openai-responses/ which is generated by uv pip compile, etc.) with no floor at all. These aren't part of the shipped package or the scanned poetry.lock, so they're out of scope for VULN-95456, but if the intent is repo-wide uv hygiene it would be worth either adding the floor to the example projects that have a pyproject.toml or documenting the minimum uv version once in a contributing guide.
• pyproject.toml:31-33: The [project.optional-dependencies] extras lists and [tool.poetry.dependencies] must be kept manually in sync (each optional package is declared twice, with the Python gate expressed two different ways: ; python_version < '3.14' vs python = ">=3.11,<3.14"). The missing-marker bug in this PR is a direct consequence of that duplication. Consider adding a small CI/pre-commit check that asserts every name in an extra has a matching [tool.poetry.dependencies] entry with optional = true and an equivalent Python constraint, so the next drift is caught mechanically.
• pyproject.toml:63-63: Once crewai's own floor for uv reaches >= 0.9.6, this direct uv declaration becomes redundant and can be dropped so the transitive dependency is managed by crewai again. Worth a note or tracking item so the workaround doesn't become permanent and keep constraining downstream consumers of splunk-ao[crewai].

[fercor-cisco]

See comment about pinning the uv version.

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-5). It may contain mistakes.

Verdict: request_changes — The agreed-upon uv pin was applied to only one of the two CI workflows, leaving adk on an unpinned range, and the PR description no longer matches what the diff actually does (wrong CVE, stale "no lockfile change" claim).

General Comments

• 🟡 minor (documentation): The PR description has drifted from what the diff actually does, which matters here because this description is the evidence trail for closing VULN-95456.

Specific contradictions against the current head:

1. Wrong CVE. The body cites CVE-2025-54368 / GHSA-8qf3-x8v5-2pj8. The ticket is CVE-2025-13327. Related advisories (both are ZIP parsing differentials), but not the same identifier.
2. Internally inconsistent fixed version. The table says Affected: uv <= 0.8.5 and Fixed in: uv 0.9.6+. Those two rows can't both be right for one advisory — if <=0.8.5 is affected, the fix is 0.8.6. The ticket's remediation field is what actually justifies the >=0.9.6 floor; cite that instead of grafting 0.8.5-era affected-range data onto it.
3. Title says >=0.8.6. Everything that landed is >=0.9.6. The title should be updated so the squashed commit message isn't wrong.
4. The "Notes" section is now false. It claims "uv is not a Python package dependency in this repo — it is used as a CI/dev tool only" and "No lockfile regeneration needed (poetry.lock / uv.lock unaffected)." The diff does the opposite: it adds uv to [tool.poetry.dependencies], to the public crewai and all extras, and regenerates poetry.lock (uv 0.8.9 → 0.12.1). That lockfile change is in fact the part that resolves the scanner finding, since originPath on the ticket is poetry.lock.
5. The "Changes" section lists only the CI workflows and the two subproject pyproject.toml files — it omits the root pyproject.toml and poetry.lock entirely.

Please refresh the description to describe the change as it now stands.

• 🟡 minor (question): Adding uv (>=0.9.6) to the public crewai and all extras (and the backing [tool.poetry.dependencies] entry) changes the published splunk-ao wheel's metadata, not just this repo's lockfile. I want to confirm that's a deliberate choice rather than the shortest path to a green scan, because there's a real trade-off either way and the description doesn't mention it.

Current approach (public extra): downstream pip install splunk-ao[crewai] now carries a hard uv>=0.9.6 requirement, so consumers are protected from resolving crewai's own uv>=0.4.25 down to a vulnerable build. The cost is that splunk-ao now dictates a floor on a tool many consumers install and pin independently, and relaxing it later requires a release.

Alternative (Poetry group constraint): uv = ">=0.9.6" in a dev/test group. Poetry resolves all groups into a single poetry.lock, so this raises the locked version — which is what FOSSA scans (originPath: poetry.lock) — without touching published metadata. The cost is that downstream consumers get no protection.

Given the ticket is scoped to poetry.lock on main, the group option is sufficient for closure and lower-blast-radius; the extra is strictly more protective. Either is defensible — I'd just like the reasoning recorded, since the current shape means splunk-ao is now opinionated about a consumer's uv install as a side effect of a CI vulnerability ticket.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• .github/workflows/ci-tests-splunk-ao-a2a.yaml:44-46: Once uv is pinned to an exact version in both CI workflows, there is no automated mechanism to bump it — the repo has no .github/dependabot.yml or renovate.json (the only dependabot reference is an allowlist entry in cla.yml:30). Pinned-without-automation means the uv toolchain, the SHA-pinned actions, and pipx install poetry==2.4.1 in ci-tests.yaml:41 all silently rot until the next vulnerability ticket forces a manual bump. Consider adding a Dependabot config covering github-actions and pip/poetry so version floors are maintained proactively rather than reactively via VULN tickets.
• splunk-ao-adk/CONTRIBUTING.md:103-113: The contributor prerequisites list "UV package manager" with no version requirement, but splunk-ao-adk/pyproject.toml:27 now hard-fails uv sync for anyone on uv < 0.9.6 via required-version. Worth documenting the minimum here (and in the a2a equivalent) so the failure is self-explanatory rather than a surprise error on first uv sync --dev.

[fercor-cisco]

🟠 major (design): This is the only remaining unpinned uv in the repo — the change agreed on in review was applied to the a2a workflow but not here.

Compare the sibling file at the same line: ci-tests-splunk-ao-a2a.yaml:46 is now version: "0.12.1". The review thread that prompted that change explicitly said "Same applies to ci-tests-splunk-ao-adk.yaml:46", and the reply on it was "It's better to follow the suggestion and pin to a version." Only one of the two files got the edit.

Two concrete consequences of leaving the range here:

• The two CI jobs now test against different uv versions. adk resolves to whatever is newest at run time; a2a is fixed at 0.12.1. A uv regression will hit adk only, and it'll look like an adk-specific failure rather than a toolchain drift.
• Non-reproducible and inconsistent with repo convention. ci-tests.yaml:41 pins pipx install poetry==2.4.1, and every action here is SHA-pinned — including setup-uv on the line directly above. This range is the odd one out, and a bad uv release breaks CI with no repo change to bisect to.

The security floor is satisfied either way (>=0.9.6 does exclude the vulnerable range), so this isn't a VULN-95456 gap — it's an unfinished edit. Pin it to match a2a so both jobs move in lockstep and a future bump is a single reviewable diff.

Suggested change

	version: ">=0.9.6"
	version: "0.12.1"

🤖 Generated by the Astra agent

[shuningc]

Resolved — ci-tests-splunk-ao-adk.yaml:46 is now version: "0.12.1", identical to ci-tests-splunk-ao-a2a.yaml:46. Both jobs now move in lockstep.

[shuningc]

🤖 This review was generated by the Astra agent (claude-opus-5). It may contain mistakes.

Verdict: approve — The lockfile bump (uv 0.8.9 → 0.12.3) genuinely closes the FOSSA finding, the pyproject floors and python_version < '3.14' markers are now internally consistent with their crewai/litellm siblings and with the regenerated lock marker, and all 11 prior review findings are correctly addressed; only minor docs/automation gaps remain.

General Comments

• 🟡 minor (design): The exact CI pins (version: "0.12.1" in both workflows) were accepted on the premise from the earlier review thread that Dependabot/Renovate would bump them. That premise doesn't hold in this repo: there is no .github/dependabot.yml and no Renovate config anywhere in the tree (the only reference to Dependabot is an allowlist entry in cla.yml). Every other pin here — pipx install poetry==2.4.1, the SHA-pinned actions — has the same problem, so this PR isn't making things worse, but it is worth being explicit that this pin now freezes uv indefinitely until someone opens a manual PR.

That matters more than usual for a security PR: the whole reason this ticket exists is that a pinned uv drifted behind a CVE fix. Pinning to 0.12.1 with no bump automation recreates exactly that failure mode, just starting from a safe version. The [tool.uv] required-version = ">=0.9.6" floors in the subprojects don't help, since 0.12.1 satisfies them.

Two options, either is fine:

• Land as-is and add a dependabot.yml with package-ecosystem: github-actions plus a uv updater in a follow-up (captured below).
• Keep the floor form (>=0.9.6) in CI, accepting run-to-run drift in exchange for automatic CVE pickup.

No change required for this PR to be safe to merge — flagging so the choice is deliberate and the follow-up doesn't get lost.

Follow-ups

Suggested follow-up work that could be tracked as Jira tickets:

• .github/workflows/ci-tests-splunk-ao-adk.yaml:43-48: Add a .github/dependabot.yml (or Renovate config) so the pinned toolchain versions get bumped automatically. There is currently no dependency-update automation in the repo, which means the newly pinned setup-uv version: "0.12.1" in both CI workflows, the SHA-pinned actions, and pipx install poetry==2.4.1 in ci-tests.yaml:41 can only be updated by hand. At minimum enable package-ecosystem: github-actions and a pip/uv updater, so the next uv CVE surfaces as an automated PR rather than another manually filed VULN ticket.
• splunk-ao-a2a/pyproject.toml:28-30: Consider committing uv.lock for the splunk-ao-a2a and splunk-ao-adk subprojects. Neither has a lockfile (no uv.lock exists anywhere in the repo), so uv sync --dev in both CI workflows resolves dependencies fresh on every run — the subproject CI is not reproducible, and a bad upstream release breaks it with no repo change to bisect to. Pre-existing and unrelated to this PR's remediation, but it is the same class of drift this ticket is about, and .gitignore:100 already notes that committing uv.lock is the recommended practice.

[shuningc]

🟡 minor (documentation): This is a hard gate, not a hint: uv aborts with error: Required uv version ... does not match the running version when a contributor's uv is below the floor. But splunk-ao-adk/CONTRIBUTING.md (line 103-106) lists prerequisites as just "Python 3.13+ (recommended)" and "UV package manager" with no minimum version, so the first thing a contributor on an older uv sees after uv sync --dev is a failure the docs never warned about.

Worth adding the floor to the prerequisites list alongside this change:

- [UV](https://docs.astral.sh/uv/) package manager (>=0.9.6)

Separately, note that required-version was only introduced in uv 0.5.x — on a uv old enough to predate it, the key is ignored rather than enforced, so the guard silently does nothing for the very oldest installs. That's an argument for documenting the floor rather than relying on required-version alone. Same applies to splunk-ao-a2a/pyproject.toml:29.

🤖 Generated by the Astra agent