fix(deps): snyk sweep console frontend

[malinskibeniamin]

What

Security sweep for Console frontend covering the May 13, 2026 TanStack supply-chain incident plus Axios/UUID follow-up.

• Removes unused direct uuid / @types/uuid dependencies and the unused rsbuild-plugin-devtools-json dev dependency.
• Adds a Snyk policy entry for remaining transitive UUID paths not reachable from frontend runtime code, with path-specific rationale.
• Hardens frontend Bun and Rspack cache keys with BUN_CACHE_SALT: 2026-05-13 and includes lock/package inputs in the Rspack cache key.
• Regenerates Bun and Yarn lockfiles after bun upgrade, bun install, and bun i --yarn.

Why

TanStack maintainers disclosed malicious npm publishes in the @tanstack/* namespace, and the sweep also reviewed Axios and UUID advisories. Console frontend did not contain exact compromised TanStack or Axios versions. UUID direct usage was unused, so it was removed; remaining UUID exposure is transitive and covered by reachability-based triage. The unused devtools plugin was also removed after review because no source/config path referenced it. The Rspack cache key also needed dependency inputs to avoid serving stale compiled dependency artifacts.

How

• Removed unused direct UUID packages first, then upgraded parent packages.
• Removed unused rsbuild-plugin-devtools-json after Claude review confirmed no config/source usage.
• Used targeted resolutions / overrides only where needed for the requested hono / fast-uri MCP/shared-transitive findings.
• Used .snyk only for remaining not-reachable UUID paths.
• Rotated frontend cache namespaces, hoisted the salt to BUN_CACHE_SALT, and expanded the Rspack key inputs.
• Ran the requested lock sync sequence: bun upgrade, then bun install, then bun i --yarn.

Acceptance Criteria

• No exact known compromised TanStack versions are present in Console frontend lockfiles.
• Snyk no longer reports active Axios / UUID / requested hono + fast-uri findings for the target scan.
• Frontend CI cache keys cannot restore the old pre-incident Rspack/Bun cache namespace via BUN_CACHE_SALT: 2026-05-13.
• Remaining unrelated Snyk/Bun findings are handled in follow-up PRs or separately triaged.
• Unused dependency feedback from review has been addressed.

Testing Steps

• bun upgrade
• bun install
• bun i --yarn
• git diff --check
• bun run type:check
• snyk test --json spot scan
• bun audit --json spot scan
• snyk monitor --target-reference=<branch> pushed branch-scoped snapshot
• Addressed Claude review: removed unused direct uuid / @types/uuid, eliminating lingering uuid@13.0.0 from the dev tree
• Addressed Claude follow-up: removed unused rsbuild-plugin-devtools-json and tightened .snyk rationale
• Hoisted frontend Bun/Rspack cache salts to BUN_CACHE_SALT: 2026-05-13
• Latest full lint / typecheck / test / build CI after final dependency cleanup

Follow-up: MCP transitive Snyk findings

Added after the initial sweep to cover newly reported Snyk findings surfaced through @modelcontextprotocol/sdk@1.29.0 and shared ajv transitive paths:

Package	Snyk ID	CVE	Fixed version applied	Result
hono	SNYK-JS-HONO-16438966	CVE-2026-44456	4.12.18	Not reported by Snyk rescan
fast-uri	SNYK-JS-FASTURI-16642394	CVE-2026-6322	3.1.2	Not reported by Snyk rescan
fast-uri	SNYK-JS-FASTURI-16642399	CVE-2026-6321	3.1.2	Not reported by Snyk rescan

Applied via targeted resolutions / overrides, which forces the fixed versions for every consumer, regenerated both lockfiles with bun install and bun i --yarn after confirming Bun is already latest with bun upgrade.

[malinskibeniamin]

@claude review

[claude]

Claude finished @malinskibeniamin's task in 3m 0s —— View job

---

Claude Code Review

• Inspect workflow cache-key changes
• Review frontend/.snyk policy entries
• Inspect frontend/package.json direct dependency bumps
• Spot-check bun.lock / yarn.lock changes
• Verify acceptance-criteria coverage
• Post final review

---

Summary

The intent is sound: bump direct/parent packages, salt CI cache keys, and use .snyk only for non-reachable transitive paths. A few things worth tightening before merging out of draft.

Findings

1. uuid and @types/uuid look unused in frontend/src — consider removing rather than bumping

grep -rn "from ['\"]uuid" frontend/src returns no hits anywhere in the codebase. The PR description even states "repository source has no direct uuid runtime imports."

If that's accurate, both "uuid": "^13.0.2" (frontend/package.json:163) and "@types/uuid": "^11.0.0" (frontend/package.json:199) are dead direct deps. Removing them would:

• shrink the surface that triggered this whole sweep (transitive-only paths are already covered by .snyk),
• remove one of the two uuid@13.0.0 resolutions still in the tree (see point 2),
• avoid the runtime/types version mismatch (uuid v13 vs @types/uuid v11; modern uuid ≥ 9 ships its own types, so @types/uuid is redundant either way).

If something does import uuid indirectly through a build step I missed, please confirm — but a bun why uuid would clarify quickly. Fix this →

2. uuid@13.0.0 (pre-patch) is still in both lockfiles via @types/uuid

@types/uuid@11.0.0 declares "uuid": "*" as a runtime dep (unusual for a @types/* package), which resolves to uuid@13.0.0 — the very version this PR is moving away from. Visible in:

• frontend/bun.lock:4083 — "@types/uuid/uuid": ["uuid@13.0.0", …]
• frontend/yarn.lock:15252 — uuid@*: version "13.0.0"

So the ^13.0.0 → ^13.0.2 bump only patches the top-level resolution; the dev-tree still installs 13.0.0. The .snyk wildcard ignore covers this for Snyk's report, but if SNYK-JS-UUID-16133035 is fixed in 13.0.2, then 13.0.0 is technically vulnerable and the policy is masking it rather than fixing it. Removing @types/uuid (point 1) is the cleaner fix.

3. .snyk uses a path wildcard - '*' — will also silence future direct paths

frontend/.snyk:5-12 ignores SNYK-JS-UUID-16133035 across all paths, including any future direct frontend > uuid@... resolution that might regress. The justification text only covers transitive paths. Two safer alternatives:

• Enumerate the actually-not-reachable transitive paths (the reason field already lists them by name: @hookform/devtools, LaunchDarkly, Storybook, SockJS, Mermaid, Dockerode), or
• Keep the wildcard but tighten the expiry to a shorter window (it's currently 90 days) so you re-examine sooner.

4. PR title vs. actual diff: no TanStack changes

The title says "snyk sweep console frontend" (good) but the body opens with "TanStack supply-chain incident." There are zero @tanstack/* version changes in the diff — the body acknowledges this. Not a blocker, just make sure the title in the merge commit doesn't read like a TanStack response or it'll be misleading in git log.

5. Cache-key date salt — works, but a few notes

.github/workflows/frontend-react-doctor.yml:29-31 and .github/workflows/frontend-verify.yml:73-75:

• The restore-keys correctly includes the same 2026-05-13 salt so it can't fall back to the pre-incident namespace. ✅
• The Rspack key now hashes bun.lock + package.json + frontend/src/** + rsbuild.config.ts. Hashing frontend/src/** means every PR invalidates the cache — this isn't introduced by this PR, but it does mean the new lockfile inputs you added rarely matter in practice because src will change first. Consider whether src/** belongs in the build-cache key at all (a separate, follow-up cleanup).
• The hard-coded date salt requires a manual edit for any future rotation. Acceptable for an incident-response sweep; just be aware.

6. Acceptance criteria — partial

From the PR body checklist:

• "No exact known compromised TanStack versions" — N/A, none were present. ✅
• "Snyk no longer reports active Axios or UUID findings" — true via policy ignore, but see points 1–3. The UUID finding is suppressed, not eliminated, until @types/uuid is gone.
• "Frontend CI cache keys cannot restore the old pre-incident cache namespace" — ✅, restore-keys are correctly salted.
• "Full bun install / lint / typecheck / test / build in CI" — still unchecked; please confirm before un-drafting.

Nits

• testcontainers 11.10.0 → 11.14.0, rsbuild-plugin-devtools-json 0.2.5 → 1.0.0 are reasonable parent bumps; 1.0.0 is a major and drops the uuid dep entirely. Sanity-check that rsbuild-plugin-devtools-json@1.0.0 still attaches to your @rsbuild/core version per its widened peer range.
• Lockfile churn is large (~4200 line yarn.lock delta) because both lockfiles were regenerated together. Hard to spot-review by eye — worth a bun audit + yarn npm audit paste in the PR description as evidence.

---

• Branch: beniamin-malinski/snyk-ux-security/console-frontend

[malinskibeniamin]

@claude review

[claude]

Claude finished @malinskibeniamin's task in 3m 4s —— View job

---

Claude PR Review

• Read repository CLAUDE.md and conventions
• Review .github/workflows/frontend-react-doctor.yml changes
• Review .github/workflows/frontend-verify.yml changes
• Review frontend/.snyk policy file
• Review frontend/package.json dependency bumps
• Spot-check frontend/bun.lock and frontend/yarn.lock deltas
• Cross-check claims in PR description against actual diff
• Post review feedback

---

Summary

Overall, this is a tightly-scoped security-hygiene PR and the approach is sound: targeted version bumps over blanket overrides, a documented Snyk ignore for non-reachable transitive paths, and a defensive cache-key rotation. The PR description matches the diff. Below are the points worth addressing or at least acknowledging before merge.

Findings

1. uuid is declared as a direct runtime dependency but is never imported anywhere in frontend/src/.

A repo-wide grep for from 'uuid' / require('uuid') in frontend/ returns zero hits outside of node_modules. The only "uuid"-related util in source is frontend/src/utils/uuid.utils.ts:9, which is a regex check that does not import the uuid package. The .snyk file's "no direct uuid runtime imports" rationale is therefore correct — but it raises the question: why keep uuid: ^13.0.2 in dependencies at all?

Options:

• If it's intentionally pinned at the root to keep transitive resolution clean, that intent should live in a comment or in the .snyk rationale.
• Otherwise this looks like a candidate for removal in a follow-up. Same applies to @types/uuid: ^11.0.0 in devDependencies (also zero usage in source).

Fix this →

2. bun.lock and yarn.lock are not in lockstep on uuid@11.x.

The bun.lock diff cleanly removes the old rsbuild-plugin-devtools-json/uuid → uuid@11.1.0 nested entry (line ~4083 removed). But yarn.lock still keeps a top-level uuid@^11.1.0 resolving to 11.1.0. The bun i --yarn step in the testing checklist was supposed to keep these aligned. Either:

• something in the yarn tree still legitimately wants 11.1.0 (worth identifying), or
• the yarn lockfile needs another pass.

Worth running yarn why uuid or bun why uuid to confirm the remaining 11.x reachability and document it (or kill it).

3. rsbuild-plugin-devtools-json is a dead dependency.

grep -r "devtools-json" across the whole frontend tree (excluding node_modules and lockfiles) returns only the package.json declaration. It's listed in devDependencies but never imported or referenced from rsbuild.config.ts or any other config. Bumping 0.2.5 → 1.0.0 (major) to drop a transitive uuid@11.1.0 is fine — but it'd be cleaner to just delete the dep. Out of scope for this PR if you want to keep it focused; worth a follow-up.

Fix this →

4. Workflow cache-key date salt is hardcoded.

.github/workflows/frontend-react-doctor.yml:29-31 and .github/workflows/frontend-verify.yml:73-75 introduce 2026-05-13 as a literal string inside both key: and restore-keys:. This works and achieves the stated goal (the old ${{ runner.os }}-bun-cache- and -rspack- prefixes can no longer be restored), but it means every future incident-driven rotation requires another workflow edit. Consider parametrizing via a top-level env.CACHE_NAMESPACE so future rotations are a one-line bump. Non-blocking.

5. The Rspack cache-key input expansion is a real correctness fix, not just hygiene.

.github/workflows/frontend-verify.yml:73 — adding frontend/bun.lock and frontend/package.json to hashFiles(...) is the right call. The pre-PR key only hashed src/** and rsbuild.config.ts, so dependency-only changes (exactly like this PR) wouldn't have busted the Rspack cache and could have served stale compiled vendor artifacts. Good catch.

6. .snyk ignore — content and scope look correct.

frontend/.snyk:5-15 — SNYK-JS-UUID-16133035 ignored with a 3-month expiry (2026-08-11) and a specific, code-grounded rationale (v3/v5/v6 external-buffer API not invoked anywhere in source). The reachability claim is consistent with what's in the tree. Two minor suggestions:

• The reason lists @redpanda-data/ui/@hookform-devtools — verify the slash there is intentional (Snyk paths typically use > separators).
• Consider linking to the upstream Snyk advisory URL in the rationale so a future reader doesn't have to guess what API the ignore is exempting.

7. Acceptance criteria status.

Of the four acceptance-criteria boxes, only the inline "Testing Steps" are checked; the criteria themselves are all unchecked, including "No exact known compromised TanStack versions are present" and "Snyk no longer reports active Axios or UUID findings." The body asserts these were verified via snyk test --json / bun audit --json — please tick those boxes (or paste the scan summary) so reviewers can sign off on the security claim, not just the mechanical bumps. The "Full lint / typecheck / test / build in CI" item should be confirmed green before merge given the rsbuild-plugin-devtools-json major bump and testcontainers 11.10 → 11.14 (transitively properties-reader 2 → 3, mkdirp 1 → 3) — these touch testcontainer-using integration test paths.

Nits

• frontend/.snyk:2 — version: v1.25.1 is the policy schema version; fine, but worth confirming Snyk's current canonical version (some teams pin to whatever Snyk emits via snyk policy).
• The PR title says "snyk sweep console frontend" while the body says "May 13, 2026 TanStack supply-chain incident" — there are no @tanstack/* changes in the diff. The body explains why (no exact compromised versions present), but a one-line callout at the top of the description like "No @tanstack/* changes were required — see §How for why" would save reviewers from grepping for it.

Verdict

LGTM on the security intent and the mechanical correctness of the bumps + cache rotation. Please address (1) the unused direct uuid declaration question and (2) the bun/yarn lockfile divergence on uuid@11.x before merge; the rest are non-blocking but worth a follow-up.

--- • branch: beniamin-malinski/snyk-ux-security/console-frontend

[malinskibeniamin]

@claude review\n\nFollow-up pushed: removed unused direct uuid / @types/uuid and regenerated Bun/Yarn locks.

[claude]

Claude finished @malinskibeniamin's task in 2m 4s —— View job

---

Claude PR Review (follow-up)

• Sync local branch and review latest commits
• Verify uuid / @types/uuid removed from frontend/package.json
• Confirm uuid@13.0.0 no longer in bun.lock / yarn.lock
• Check remaining uuid@11.x resolutions in both lockfiles
• Re-evaluate .snyk scope given direct deps removed
• Re-check workflow cache-key changes
• Post follow-up review

---

Summary

The follow-up commit (59c549f fix(deps): remove unused uuid) resolves both blocking items from my prior review. Direct uuid and @types/uuid are gone from frontend/package.json, and the pre-patch uuid@13.0.0 resolution that @types/uuid@11.0.0 was pulling in is no longer in either lockfile. The remaining UUID exposure is now genuinely transitive-only and matches the .snyk rationale.

Verification

1. Direct deps removed — confirmed

frontend/package.json no longer contains uuid or @types/uuid:

$ grep -n "uuid" frontend/package.json
(no matches)

And grep -rn "from ['\"]uuid" frontend/src still returns zero hits — i.e., nothing in source was relying on those declarations.

2. uuid@13.0.0 purged from both lockfiles — confirmed

$ grep -n "uuid@13" frontend/bun.lock frontend/yarn.lock
(no matches)

The previously-flagged @types/uuid → uuid@* → 13.0.0 chain is gone from both lockfiles. The two lockfiles are now in lockstep on the remaining UUID versions:

Version	Source(s)	Reachability
11.1.0	@a2a-js/sdk, mermaid (top-level resolution)	Transitive, dev/agent SDK
10.0.0	dockerode (nested)	Transitive, test tooling
8.3.2	@hookform/devtools, sockjs (nested)	Transitive, devtools/HMR

All three match the .snyk rationale's enumerated paths. ✅

3. .snyk policy still appropriate

frontend/.snyk:7-14 says "repository source has no direct uuid runtime imports" — now stronger than before, since there's no direct dependency in the manifest either. The - '*' wildcard is still broader than strictly needed (it would also silence a future direct regression), but with no manifest entry, accidental reintroduction would require adding uuid back to package.json and would be visible in code review. Optional tightening if you want belt-and-suspenders: enumerate the specific transitive paths or shorten the 90-day expiry — but I wouldn't block on it.

4. Workflow cache-key changes unchanged from prior review

.github/workflows/frontend-react-doctor.yml:29-31 and .github/workflows/frontend-verify.yml:73-75 — 2026-05-13 salt is correctly in both key: and restore-keys: so the old namespace cannot be restored. The Rspack key now properly invalidates on dependency changes (bun.lock, package.json included in hashFiles). ✅

Remaining items (non-blocking)

• Acceptance-criteria boxes still unchecked. Worth ticking them (or pasting the snyk test --json / bun audit --json summary in the body) before merging out of draft, so reviewers can sign off on the security claim rather than just the mechanical bumps. The "Full lint / typecheck / test / build in CI" item is the important one given rsbuild-plugin-devtools-json 0.2.5 → 1.0.0 (major) and testcontainers 11.10 → 11.14 (transitively bumps properties-reader and mkdirp majors).
• rsbuild-plugin-devtools-json is still declared but unused. frontend/package.json:209 — grep -rn "devtools-json" frontend/src frontend/rsbuild.config.ts returns nothing. Out of scope for this PR; worth a follow-up cleanup since the only thing it brought into the tree was a (now-removed) uuid path.
• PR title vs. body mismatch on TanStack still applies — title is now correctly "snyk sweep console frontend" but the body opens with the TanStack incident even though no @tanstack/* changes were required. Cosmetic.

Verdict

LGTM on the security intent and the mechanical correctness. The two blocking items from my prior review (unused direct uuid decl, lockfile divergence on uuid@11.x) are both resolved. Recommend ticking the acceptance-criteria checkboxes (or pasting scan output) before merging out of draft, and confirming green CI on the rsbuild/testcontainers majors.

--- · branch: beniamin-malinski/snyk-ux-security/console-frontend

[malinskibeniamin]

@claude review

Follow-up pushed for the requested MCP transitive Snyk findings:

• hono is now resolved to 4.12.18 for SNYK-JS-HONO-16438966 / CVE-2026-44456.
• fast-uri is now resolved to 3.1.2 for SNYK-JS-FASTURI-16642394 / CVE-2026-6322 and SNYK-JS-FASTURI-16642399 / CVE-2026-6321.
• Regenerated bun.lock and yarn.lock with bun install and bun i --yarn after bun upgrade confirmed Bun is already latest.
• Verified Snyk no longer reports those three IDs and bun audit has no hono / fast-uri findings.

[claude]

Claude finished @malinskibeniamin's task in 2m 23s —— View job

---

Claude PR Review (MCP transitives follow-up)

• Sync local branch and inspect latest commit
• Verify hono resolved to 4.12.18 in both lockfiles
• Verify fast-uri resolved to 3.1.2 in both lockfiles
• Confirm resolutions / overrides are in frontend/package.json
• Sanity-check @modelcontextprotocol/sdk@1.29.0 still resolves cleanly with the pins
• Re-check .snyk and prior items remain consistent
• Post follow-up review

---

Summary

The 08aea23 fix(deps): patch mcp transitives commit cleanly addresses the three Snyk IDs from the PR description table. Both lockfiles are in lockstep, package.json updates are symmetric across overrides (npm) and resolutions (yarn), and no new .snyk ignores were added — these were genuinely fixed via version pins rather than suppressed. LGTM on this follow-up, modulo one minor framing nit and the still-outstanding CI checkbox.

Verification

1. hono bump: 4.12.14 → 4.12.18 — confirmed in both lockfiles, single resolution

frontend/package.json:56 (overrides) and frontend/package.json:229 (resolutions) both pin ^4.12.18.

• frontend/bun.lock:2392 → hono@4.12.18
• frontend/yarn.lock:9316-9319 → hono@^4, hono@^4.11.4: 4.12.18

$ grep -nE "hono-4|hono@4\." frontend/yarn.lock
9318:  resolved ".../hono/-/hono-4.12.18.tgz"

No stale 4.12.14 left in either tree. The @modelcontextprotocol/sdk@1.29.0 constraint of hono: ^4.11.4 is satisfied. ✅

2. fast-uri bump: 3.1.0 → 3.1.2 — confirmed in both lockfiles, single resolution

frontend/package.json:71 (overrides) and frontend/package.json:249 (resolutions) both pin ^3.1.2.

• frontend/bun.lock:2218 → fast-uri@3.1.2
• frontend/yarn.lock:8574-8577 → fast-uri@^3.0.1: 3.1.2

Only one fast-uri@3.x resolution in either lockfile. ✅

3. Reachability — fast-uri comes in via ajv, not directly via MCP

The PR description groups fast-uri under "MCP transitive Snyk findings," but the actual path in frontend/bun.lock:1600 shows ajv@8.18.0 is what asks for fast-uri: ^3.0.1. MCP SDK pulls in ajv@^8.17.1 so it's one of the parents, but ajv is reachable from many other places too. The fix is correct either way — the override forces 3.1.2 for every consumer — just a framing note for whoever reads the PR body in 6 months.

4. @hono/node-server peer satisfied

frontend/bun.lock:586 — @hono/node-server@1.19.14 requires hono: ^4 (peer), satisfied by hono@4.12.18. MCP SDK's @hono/node-server: ^1.19.9 constraint is also satisfied by 1.19.14. ✅

5. .snyk policy unchanged in this commit — correct behavior

No new ignores were added for SNYK-JS-HONO-16438966, SNYK-JS-FASTURI-16642394, or SNYK-JS-FASTURI-16642399. The fixes are real, not suppressed. The existing UUID policy at frontend/.snyk:5-15 is untouched. ✅

6. Symmetry between overrides and resolutions blocks — confirmed

Both fast-uri: ^3.1.2 and hono: ^4.12.18 appear in both blocks, so npm/bun and yarn-classic consumers get identical version-locking. Good hygiene.

Remaining items (non-blocking, carried from prior reviews)

• Acceptance-criteria boxes still unchecked. The body now claims Snyk no longer reports the three new IDs and bun audit has no findings for hono / fast-uri — please tick the acceptance criteria or paste the rescan output so reviewers can sign off on the security claim rather than just the mechanical bumps.
• "Full lint / typecheck / test / build in CI" still unchecked. Especially important now that this PR bumps rsbuild-plugin-devtools-json (major) + testcontainers minor + adds fast-uri and hono overrides. Worth confirming green before un-drafting.
• rsbuild-plugin-devtools-json is still declared but unused (frontend/package.json:210). Out of scope; worth a follow-up.
• PR body title/intro vs. diff: body still leads with the TanStack incident but no @tanstack/* changes are present. Cosmetic.

Verdict

LGTM on the MCP follow-up. The two hono and three combined fast-uri Snyk IDs are addressed with real version pins (not policy ignores), both lockfiles are consistent, and MCP SDK peer/dep ranges remain satisfied. Recommend ticking the acceptance-criteria checkboxes and confirming green CI on the rsbuild/testcontainers majors before merging out of draft.

--- · branch: beniamin-malinski/snyk-ux-security/console-frontend

[malinskibeniamin]

Claude follow-up addressed:

• Clarified PR body framing for fast-uri: fixed via shared ajv transitive paths as well as MCP, not only MCP directly.
• Checked acceptance criteria now that Snyk + CI are green for the relevant frontend/security checks.
• Confirmed no extra .snyk ignores were added for these findings.

[malinskibeniamin]

@claude review

Final follow-up pushed after addressing PR/Snyk feedback:

• Removed unused rsbuild-plugin-devtools-json dependency after review confirmed no source/config usage.
• Tightened UUID .snyk reason to match actual remaining transitive paths.
• Removed empty patch: {} stanza.
• Resolved stale self-review threads and updated PR description / acceptance criteria.
  Please verify there are no remaining Snyk or review-feedback blockers.

[claude]

Claude finished @malinskibeniamin's task in 2m 1s —— View job

---

Claude PR Review (final follow-up)

• Sync local branch and inspect latest commits
• Verify rsbuild-plugin-devtools-json removed from package.json and lockfiles
• Verify .snyk reason tightened and patch: {} removed
• Confirm no new ignores added & prior hono/fast-uri/uuid status holds
• Spot-check workflow cache-key changes still consistent
• Post final review

---

Summary

The b8264b2 fix(deps): remove unused devtools plugin commit cleanly addresses every remaining non-blocking item I flagged across the prior three reviews. rsbuild-plugin-devtools-json is gone from the manifest and both lockfiles, the .snyk rationale now enumerates the actual transitive paths visible in bun.lock, and the empty patch: {} stanza is removed. No new ignores were added — the cleanup is purely subtractive. No remaining Snyk or review-feedback blockers.

Verification

1. rsbuild-plugin-devtools-json fully removed — confirmed

• frontend/package.json — grep -n "devtools-json" returns nothing in the manifest.
• frontend/bun.lock — both the top-level "rsbuild-plugin-devtools-json": "^1.0.0" entry (line 143) and the rsbuild-plugin-devtools-json@1.0.0 resolution (former line 3276) are deleted.
• frontend/yarn.lock — no remaining references.
• No source/config code referenced it (grep -rn "devtools-json" frontend/ --include="*.{ts,tsx,js,mjs,json}" excluding lockfiles → 0 hits), confirming the prior review's "dead dependency" finding. ✅

2. .snyk rationale tightened to match real lockfile paths — confirmed

frontend/.snyk:5-15 now lists: @a2a-js/sdk, Mermaid via streamdown, @hookform/devtools via @redpanda-data/ui, SockJS dev-server, Docker test tooling. Cross-checked each against bun.lock:

Claim	Lockfile evidence
@a2a-js/sdk → uuid 11.x	bun.lock:181 — @a2a-js/sdk@0.3.13 deps include "uuid": "^11.1.0" ✅
Mermaid via streamdown → uuid 11.x	bun.lock:2747 — mermaid@11.14.0 deps "uuid": "^11.1.0"; parent is streamdown@2.5.0 (line 3451) ✅
@hookform/devtools via @redpanda-data/ui → uuid 8.x	bun.lock:3921 — @hookform/devtools/uuid: uuid@8.3.2 ✅
SockJS → uuid 8.x	bun.lock:4343 — sockjs/uuid: uuid@8.3.2 ✅
Docker test tooling → uuid 10.x	bun.lock:4157 — dockerode/uuid: uuid@10.0.0 ✅

Note: the prior LaunchDarkly/Storybook references were dropped — good, since neither appears in the remaining transitive UUID resolutions. The rationale now actually matches what's in the tree. ✅

3. Empty patch: {} stanza removed — confirmed

frontend/.snyk ends at line 16; no trailing patch: {}. Minor cleanup, but correct — Snyk only emits that key when patches exist, so a dangling empty object would have been misleading. ✅

4. No new ignores added; prior fixes intact — confirmed

• frontend/package.json:56,71,228,248 — hono ^4.12.18 and fast-uri ^3.1.2 overrides/resolutions still in place.
• frontend/bun.lock:2391 → hono@4.12.18; bun.lock:2217 → fast-uri@3.1.2. Single resolutions, no drift.
• frontend/yarn.lock:9316-9318 → hono@^4, hono@^4.11.4: 4.12.18; yarn.lock:8574-8576 → fast-uri@^3.0.1: 3.1.2.
• Only SNYK-JS-UUID-16133035 is ignored; hono/fast-uri are genuinely patched, not suppressed. ✅

5. Workflow cache-key salts intact — confirmed

.github/workflows/frontend-react-doctor.yml:29-31 and .github/workflows/frontend-verify.yml:73-75 — 2026-05-13 salt still in both key: and restore-keys: in both workflows, and Rspack key still hashes frontend/bun.lock + package.json. Unchanged in this commit, as expected. ✅

Remaining items (non-blocking)

• Acceptance-criteria boxes in the PR body are now ticked per the latest comment from @malinskibeniamin — good.
• The "Full lint / typecheck / test / build in CI" line item is still unchecked in the body checklist. Worth waiting for green CI on this push (with the rsbuild-plugin removal + testcontainers 11.10 → 11.14 majors carried over) before un-drafting, but everything reviewable statically is in order.
• PR body still opens with "TanStack supply-chain incident" even though no @tanstack/* versions were changed. Cosmetic only — the body explains why later, and it's accurate context for the sweep.

Verdict

LGTM. The four commits on this branch (83838d6 sweep → 59c549f uuid removal → 08aea23 MCP transitives → b8264b2 devtools-plugin removal) form a clean, subtractive security hygiene PR with no unresolved review threads. Recommend merging once CI is green on this final commit.

--- · Branch: beniamin-malinski/snyk-ux-security/console-frontend

[malinskibeniamin]

Hoisted the frontend Bun/Rspack cache salt into workflow env:

env:
  BUN_CACHE_SALT: 2026-05-13

frontend-react-doctor.yml and frontend-verify.yml now use ${{ env.BUN_CACHE_SALT }} in cache keys/restore-keys instead of repeating the literal date. Pushed in 87114b58c and updated the PR description/checklist.