Summary
osv-scanner (required check Secrets, deps, and workflow scan → Dependency scan (osv-scanner)) fails on main's yarn.lock, so every PR in the repo fails that check regardless of its contents. main carries browserslist@4.28.5, which two HIGH advisories published on 2026-09-01 apply to.
Same shape as #636: the advisories landed after PRs were last scanned, so a PR that was green at open time goes red on its next run with no change to the branch. Observed on #681 (otherwise approved) and #831; #831's security-pr passed at 13:42 and #681's failed at 17:28 on the same lockfile state.
Affected package
osv-scanner scan --lockfile agent/uv.lock --lockfile yarn.lock — 1 package, 2 known vulns (2 High):
Fix
Lockfile-only re-resolve, as in #636/#637. browserslist is transitive — no direct entry in any package.json and no resolutions pin — so yarn upgrade browserslist is a no-op under yarn v1. Dropping the pinned stanza and reinstalling lets it resolve within the existing ^4.24.0 range, landing 4.28.8.
No package.json change, so no resolutions entry and nothing to mirror into integrations/jira-forge-app (that project's overrides are brace-expansion/fast-uri/undici and it does not consume browserslist). The 56-line delta is confined to browserslist and the five data packages it pins: baseline-browser-mapping, caniuse-lite, electron-to-chromium, node-releases, update-browserslist-db.
Acceptance
Notes
Filed retroactively to give #844 the audit trail #636 set for #637 — the fix was written first because main was red and blocking the queue. Raised as a review nit on #844 by @ayushtr-aws.
Residual noted in that review, recorded here rather than acted on: with no resolutions pin, a forced re-resolution could float browserslist again. That is ordinary transitive-dependency behaviour — the lockfile pins the exact version for all installs — so no pin is warranted.
Summary
osv-scanner(required checkSecrets, deps, and workflow scan→Dependency scan (osv-scanner)) fails onmain'syarn.lock, so every PR in the repo fails that check regardless of its contents.maincarriesbrowserslist@4.28.5, which two HIGH advisories published on 2026-09-01 apply to.Same shape as #636: the advisories landed after PRs were last scanned, so a PR that was green at open time goes red on its next run with no change to the branch. Observed on #681 (otherwise approved) and #831; #831's
security-prpassed at 13:42 and #681's failed at 17:28 on the same lockfile state.Affected package
osv-scanner scan --lockfile agent/uv.lock --lockfile yarn.lock— 1 package, 2 known vulns (2 High):Fix
Lockfile-only re-resolve, as in #636/#637.
browserslistis transitive — no direct entry in anypackage.jsonand noresolutionspin — soyarn upgrade browserslistis a no-op under yarn v1. Dropping the pinned stanza and reinstalling lets it resolve within the existing^4.24.0range, landing 4.28.8.No
package.jsonchange, so noresolutionsentry and nothing to mirror intointegrations/jira-forge-app(that project'soverridesare brace-expansion/fast-uri/undici and it does not consume browserslist). The 56-line delta is confined to browserslist and the five data packages it pins:baseline-browser-mapping,caniuse-lite,electron-to-chromium,node-releases,update-browserslist-db.Acceptance
mise run security:depsreports no issuesmise run buildgreen, including the Astro docs build (the actual consumer of browserslist)security-prandbuild (agentcore)green on the fix PRNotes
Filed retroactively to give #844 the audit trail #636 set for #637 — the fix was written first because
mainwas red and blocking the queue. Raised as a review nit on #844 by @ayushtr-aws.Residual noted in that review, recorded here rather than acted on: with no
resolutionspin, a forced re-resolution could float browserslist again. That is ordinary transitive-dependency behaviour — the lockfile pins the exact version for all installs — so no pin is warranted.