[Security] Root-fix npm ci moderate-vulnerability warning instead of passing it below the high-severity gate

[seonghobae]

Detection evidence and live ownership

BandScope canonical Resource Admission PR #866 has now reproduced the same npm warning on two exact hosted heads without an intentional dependency-graph change:

• historical exact 881b4001e9634639a05c12c4a0731df7df060fdf, ci run 34652560402, ci / build-and-test job 103438030482: clean npm ci reported 3 moderate severity vulnerabilities;
• predecessor exact 600792545c8ed1f39f3d30aebf48d3926857a3bb, repository ci run 35690262503, gate / ci / rust-check job 106663752915: pinned npm 10.9.9 was verified, clean npm ci added 377/audited 380 packages and again reported 3 moderate severity vulnerabilities before frontend build/Rust compilation. That job later failed on a stale Tauri source-contract test unrelated to dependencies.

This repeat materially strengthens the warning as a current dependency-graph finding, but neither log includes npm audit --workspaces --json; package/advisory identity must therefore not be guessed from the count alone.

Live #866 has advanced by one ordinary test-only descendant to exact 7156aebd4a745cab4842d15aba319a72c80e1d98 on protected develop@314ddeae7b775a4957594b599358c8255617eb2e and remains Open / Draft / mergeable. The current delta only aligns stale source-string assertions with the already-implemented OwnedProcess API and does not intentionally alter manifests/lockfiles. The new exact-head workflows are running/queued; do not transfer 600792... npm or CI evidence to 7156... as current-head evidence.

Protected repository policy still documents/runs npm audit --workspaces --audit-level=high. That gate is useful for high/critical rejection, but a moderate advisory can remain visible in every clean install while the formal audit gate returns success. The repository policy that warnings/deprecations require root-cause work therefore still applies.

This is dependency/security ownership, not permission to add lockfile churn to #866. #783 established the canonical npm/lock-generator baseline and is already merged; this issue owns the next dependency-security RCA from the then-current protected dependency graph after the Resource Admission source lane is released.

Required RCA

Use the repository-pinned npm generator/runtime and a fresh exact protected checkout to capture clean npm ci plus npm audit --workspaces --json. For each reproduced moderate finding record:

• advisory/GHSA/CVE identity and affected installed version;
• direct vs transitive owner chain and workspace;
• production/runtime vs dev/build/test reachability;
• fixed version and whether it is reachable without a major/contract break;
• why the vulnerable code path is or is not reachable in BandScope;
• minimal compatible remediation and rollback impact.

Do not infer package identity from the repeated summary count alone. If the fresh protected graph no longer reproduces exactly three moderate findings, update this issue with the actual current set and explain the dependency ancestry that changed it.

Acceptance

• Exact advisory/package/owner-chain evidence is committed or linked from primary package/advisory sources.
• Compatible fixes are applied through the canonical dependency owner with the repository-pinned npm version and a reviewable lockfile diff; no unrelated dependency drift.
• No npm audit fix --force, audit-threshold increase, ignore/suppression, mutable install, or fix(audio): establish canonical local-audio resource policy #866-local lockfile workaround.
• A clean npm ci no longer emits the reproduced moderate vulnerability warnings. If an upstream-owned advisory is genuinely not removable yet, keep this issue open with a narrow owner-chain exception, compensating control, upstream fix/version watch and explicit removal condition rather than representing the warning as solved.
• npm audit --workspaces, repository security/supply-chain policy checks, dependency review, SBOM, SAST/CodeQL/OSV/Trivy as applicable, complete workspace tests/build and exact-head independent review pass on the remediation head.
• Doctoring/security dependency policy is updated only where the actual accepted boundary changes.

Single-writer boundary

While #866 owns the active BandScope source lane, #1206 remains read-only RCA only. Do not create a dependency branch/PR, commit/push, or edit manifests/lockfiles concurrently. Once #866 is normally integrated or its source lane is explicitly released, one bounded canonical dependency-security implementation may start from the then-current protected develop if the RCA shows a compatible repair.

This issue does not change #866 Resource Admission semantics, lower its 100% coverage requirement, or justify merging #866 with unrelated package-lock changes. It must ultimately reconcile through ordinary protected ancestry before commercial release.

[seonghobae]

@opencode-agent Take #1206 as the canonical dependency-security RCA lane, separate from #866. Current mode is read-only RCA only while the canonical BandScope source writer is active on #866. Do not create a branch/PR, commit, push, edit manifests/lockfiles, or otherwise become a second BandScope source writer until #866 releases the source lane. Start from a fresh protected develop checkout and use the repository-pinned Node/npm runtime and lock generator only for observation/reproduction.

First reproduce the exact warning with clean npm ci, then run npm audit --workspaces --json. Record all three current moderate findings by advisory/GHSA/CVE, installed version, direct/transitive owner chain and workspace, production vs dev/build/test reachability, fixed version, and compatibility impact. Do not infer package names from the summary count. The current #866 hosted log proves only the count (3 moderate severity vulnerabilities) and is not enough to name packages or advisories.

For this read-only phase, report the exact protected develop SHA, npm/runtime versions, audit JSON identities and owner chains, reachability, compatible remediation candidates, and any upstream blocker back on #1206. Do not run npm audit fix, do not use --force, do not raise/relax audit thresholds, add ignores/suppressions, or accept unrelated lockfile drift.

After the BandScope single-writer source lane is explicitly free, a later owner run may turn this RCA into one bounded canonical dependency-security PR from the then-current protected develop, only if the audit evidence shows a compatible remediation. That future implementation must use the pinned npm generator, minimal manifest/lock/security-doctoring delta, clean npm ci with the current warnings gone, full npm audit --workspaces, lock-generator/supply-chain checks, dependency review/SBOM/OSV/Trivy/SAST/CodeQL as applicable, complete workspace tests/build, and exact-head independent review. If any advisory is upstream-blocked or only removable through a breaking contract, keep #1206 open with the exact owner-chain exception, compensating control, upstream fixed-version watch and removal condition instead of forcing an upgrade or claiming resolution.

[seonghobae]

@cursor read-only RCA only. Fresh protected develop@314ddeae7b775a4957594b599358c8255617eb2e checkout에서 repository-pinned Node/npm (npm@10.9.9, Node 22.x contract)로 clean npm ci와 npm audit --workspaces --json을 실행해 현재 moderate finding을 실측해 주세요. Branch/PR/commit/push/manifest/lockfile 수정, npm audit fix, --force, ignore/threshold 변경은 금지합니다. 각 finding에 advisory/GHSA/CVE, installed version, direct/transitive owner chain + workspace, prod/runtime vs dev/build/test reachability, fixed version, compatible remediation 가능 여부를 남겨 주세요. Historical 3 moderate count에서 패키지명을 추정하지 말고 현재 protected graph 결과가 다르면 실제 결과와 ancestry 변화를 보고해 주세요.

[cursor]

You need to increase your spend limit or enable usage-based billing to run background agents. Go to Cursor

[seonghobae]

Additional read-only RCA evidence; no dependency/source mutation:

Project Persistence #970 exact source head 2892a43615fc29b119fefb3851d34aa511020965, repository ci run 35704190510, Ubuntu ci / build-and-test job 106717643693 performed a clean workspace npm ci and again printed 3 moderate severity vulnerabilities before later failing at the unrelated Ruff format check. This is now a third exact hosted reproduction of the same summary count on a source lane with no intentional dependency-graph change.

The log still does not contain npm audit --workspaces --json, so advisory/package identities remain unproven and I am not guessing them. #1206 remains the canonical dependency-security RCA owner; no package manifest/lockfile edit was added to #970. The new receipt strengthens reproducibility only.

[seonghobae]

Additional hosted reproduction from an independent product lane: BandScope #910 semantic head b5594975ae6d3087ca359cf76bcbb220491a7a0c, repository ci run 35731825321, Ubuntu ci / build-and-test job 106832987895 verified pinned npm 10.9.9, then clean npm ci added 384/audited 387 packages and again reported 3 moderate severity vulnerabilities. That job later failed at Ruff formatting of protected-base test_supply_chain_policy.py; the dependency warning was not causal.

This is another count-level reproduction only. The log still lacks npm audit --workspaces --json, so advisory/package identity must not be inferred. #1206 remains the canonical RCA owner; do not add dependency/lockfile churn to #910 or #866. Fresh #866 exact 7156aebd... now has repository CI/build/Security/Semgrep/SBOM plus its Windows/macOS native lane all GREEN, but CodeQL and independent approval remain unsettled, so the source-lane release condition for dependency implementation has not yet been met.