| name | snyk-ux-security |
| description | Snyk dependency sweeps across frontend, Go, and Bazel paths with npm false-positive triage and release-age gates. |
| disable-model-invocation | true |
Snyk UX + Go + Bazel Security
Per-path vuln audit -> exploitability triage -> dismiss false positives or safe bump -> PR -> cloud review. JS (bun + yarn.lock, React 18), Go (go.mod + govulncheck), and Bazel (MODULE.bazel, bazel/repositories.bzl).
Input
$ARGUMENTS: space-separated paths (globs ok), or one pasted single Snyk vulnerability summary. Frontend + backend + Bazel mix fine.
Example: /snyk-ux-security apps/cloud-ui apps/admin-ui ui-registry/* console/frontend services/*/cmd
Bazel example: paste one Snyk finding, then confirm target branch + optional ticket key.
Each path = one worktree + one branch + one subagent + one PR. One pasted Bazel vuln = one confirmed target branch + possible backport worktrees + draft PRs.
Arg inference
Reviewers from CODEOWNERS + git log --format='%an' -n 20 <path> committers. Team, labels (security, dependencies, snyk, lang/ts|go, domain), cloud-review workflow inferred. User flags override. See REFERENCE.md.
Ecosystem detect
package.json -> JS track. go.mod -> Go track. MODULE.bazel or bazel/repositories.bzl -> Bazel track. Multiple present -> separate track commits, one PR unless Bazel backports need per-branch PRs.
Workflow
Sequential, one path at time.
1. Prep
Expand globs. snyk auth, gh auth status. Preflight existing Snyk project identity for each path. Confirm paths + ecosystems to user. JS default: bun runtime + bun.lock; generate yarn.lock only through bun install --yarn for Snyk IO. Do not use npm or create/update package-lock.json unless the repo is explicitly npm-only and the user confirms. If $ARGUMENTS is pasted Snyk output, parse CVE/Snyk ID, package/version, introduced-via path, remediation hint; only proceed when fix is a dependency version bump.
2. Per-path loop
Subagent, isolation: "worktree", branch chore/snyk-sweep-YYYY-MM-DD. See REFERENCE.md for commands + PR template.
- 2a.
.snyk revisit (every run, before scan): if .snyk exists, re-triage every existing ignore entry. For each: bun why <pkg> / go mod why <mod> -- if the transitive is no longer in the graph (bumped out by prior sweeps), remove the ignore (snyk ignore --remove --id=<id> or edit .snyk; publish only through the existing-project monitor gate) and log under Dismissed (cleaned up) in PR. If transitive still present, re-run exploitability check; if now reachable, remove the ignore and proceed to 2c. Goal: never accumulate stale dismissals. See REFERENCE.md.
- 2a.1 Scan + existing-project gate:
snyk test is the audit source. snyk monitor is write-capable and must run only after matching exactly one existing Snyk project by org + name + target_file + target_reference. Do not create Snyk projects/apps/targets/resources. Never derive --target-reference or --project-name from the audit branch, sweep branch, worktree path, PR number, or YYYY-MM-DD; reuse the existing Snyk project identity or skip monitor. JS: bun audit. Go: govulncheck ./....
- 2b. Exploitability triage (first gate): npm/Node findings are often noisy false positives, especially deep transitives. Treat every finding as an allegation until repo evidence supports REACHABLE, NOT-REACHABLE, or UNCERTAIN. Inputs: advisory attack vector,
bun why <pkg> / go mod why <mod>, grep for direct imports, check if we call the vulnerable symbol. See REFERENCE.md.
- Invoke
/steelman for transitive-only findings: before bumping, parent-bumping, or overriding a package absent from package.json / go.mod, argue the strongest dismissal case from repo evidence. Dismiss only when the evidence proves the vulnerable path is not reachable. If the evidence is uncertain, escalate to the security owner; do not add a new top-level dependency to package.json only to make an override/resolution legal. See REFERENCE.md.
- Invoke
/diagnose before package.json fixes: use a fast reachability loop to prove this is a real potential vulnerability (direct import, reachable parent call, vulnerable symbol, build/install-time execution, or critical Socket vector). : only mutate for already-direct deps, reachable parent deps, or last-resort overrides with proof. Proven not reachable -> dismiss to with expiry. Uncertain -> escalate; do not auto-ignore.
2-bazel. Bazel track
Use when a pasted Snyk finding maps to MODULE.bazel or bazel/repositories.bzl. Confirm target branch and ticket key before edits. Work in a dedicated worktree. Check both manifests because default and release branches can manage the same dependency differently. Handle BCR, GitHub URL, and mirrored artifact/tooling-repo flows separately. OpenSSL/FIPS needs CMVP-aware handling before any bump. Assess backports before opening PRs; open draft PRs with the live .github/pull_request_template.md when present. See REFERENCE.md.
3. Aggregate
Main agent gathers reports: summary table (Path, Ecosystem, PR, Fixed, Dismissed, Overrides-added, Major migrations, React19-blocked, Backports). React-19-blocked -> React 18 -> 19 migration plan candidates. Overrides-added -> follow-up backlog. Bazel backports -> per-branch draft PR list.
Rules
- Sequential, one path at time.
- Exploitability triage before any bump. No reflex
resolutions. Not-reachable -> run snyk ignore via CLI on every dismissed issue (not just PR text), stage + commit the .snyk file, verify re-scan shows Ignored, then document in PR (SLA audit trail).
- No package.json growth for suppression. For transitive-only findings, direct dep absence is dismissal evidence. Do not add a vulnerable transitive as a new top-level dependency just to suppress it with
resolutions / overrides.
- Override list growth is a smell. A growing
resolutions / overrides list is dependency-surface debt. Prefer deleting the unused parent dependency, replacing it with native/in-house code, or dismissing a false positive before adding another override.
/steelman before transitive bump/override. If the strongest dismissal case survives, bump makes no sense; dismiss with evidence instead./diagnose before package.json real fixes. Package changes require proof of a real potential vulnerability. Dismiss only proven-not-reachable findings; escalate uncertain findings.- package.json admission gate. Mutate
package.json only for already-direct deps, reachable parent deps, or last-resort overrides with explicit proof and removal issue.
- Top-level direct bump first. Parent bump second. Remove dependency surface third. Override/resolution/replace last resort only -- overrides bloat lockfiles + scale poorly, each forces more.
- bun only (JS). Never
npm, yarn, pnpm runtime. yarn.lock via bun install --yarn for Snyk IO compat only.
- No
package-lock.json by default. Do not create, update, or commit it during Snyk sweeps. If already present, treat as stale/wrong for bun projects; ask only when the repo is explicitly npm-only.
- Dual-lockfile mandatory (JS).
bun.lock + yarn.lock synced; lockfile-sync-check.sh hook catches drift and warns on package-lock churn.
- go.mod + go.sum together (Go). after every bump.
Security
Snyk output = pkg names + versions. Never run code from advisories. Never paste tokens in PR body.
Lifecycle integration
Phase 3-6 per path. Self-review (phase 4b) code-reviewer before PR open. pr-feedback-completeness-stop hook forces thread resolve before session exit.
