fix(deps): clear 7 osv advisories blocking the merge queue

[isadeks]

Clears the seven osv-scanner advisories currently failing on main's yarn.lock, which eject every PR from the merge queue — the merge_group re-scan runs against the latest main and fails whatever is queued (observed on #867).

The seventh arrived mid-flight, which is the point. GHSA-7w5x-hrqm-74c2 in smol-toml was published at 18:07:11Z and this PR's first CI run started at 18:27:21Z, so my pre-push scan twenty minutes earlier could not have seen it — and the PR whose job is to fix this failure mode was itself failed by it. That is the cadence the repo is up against, not a one-off.

Area

• cdk — infrastructure, handlers, constructs
• agent — Python runtime / Docker image
• cli — bgagent client
• docs — guides or design sources (docs/guides/, docs/design/)
• tooling — root mise.toml, scripts, CI workflows

Related

No tracking issue — filing one needs a maintainer, so please attach one (or a security / priority label) before merge. The weekly Security suite failed issues are scheduled for Sundays and the latest, #861 (2026-09-07), is a semgrep failure in which osv-scanner explicitly reported No issues found; every advisory below was published after it. The next scheduled run is ~2026-09-14, so nothing would auto-file for another five days while the merge queue stays blocked. Prior art for this exact class of change: #637 (closing #636).

Package	From	To	Advisory	CVSS
astro	7.1.3	7.2.8	GHSA-26w7-cxv4-gfx2	9.8
astro	7.1.3	7.2.8	GHSA-376h-93r7-7g6f	6.3
js-yaml	4.3.1	4.3.2	GHSA-2883-xcg3-v3hh	7.5
sharp	0.35.3	0.35.4	GHSA-rgj7-g3m4-5g8c	8.9
svgo	4.0.2	4.1.0	GHSA-w27v-7q3p-w38r	8.2
svgo	4.0.2	4.1.0	GHSA-4vpr-x523-8j87	6.1
smol-toml	1.7.0	1.8.0	GHSA-7w5x-hrqm-74c2	8.2

Changes

Two files: docs/package.json (one version string) and yarn.lock.

• astro 7.1.3 → 7.2.8 — the only manifest edit, because docs/package.json pins astro exactly.
• js-yaml 4.3.1 → 4.3.2 — lockfile-only. The root resolutions entry already reads ^4.3.1, so the caret admits the patch; no manifest change is needed, and the resolution keeps doing its job of collapsing the transitive ^3.13.1 requester onto 4.x.
• sharp 0.35.3 → 0.35.4 and svgo 4.0.2 → 4.1.0 — lockfile-only, transitive-only, already inside the declared ^0.34.0 || ^0.35.0 and ^4.0.1 ranges.
• smol-toml 1.7.0 → 1.8.0 — lockfile-only. Requested by @astrojs/internal-helpers, astro and knip under ^1.6.0 / ^1.6.1; 1.8.0 is the highest in range and past the 1.7.1 first-patched version. Present at 1.7.0 on main unchanged, so it is not fallout from the astro bump.

Re-resolved surgically, not via mise run upgrade. That task is rm -f yarn.lock && yarn install, which is right for the scheduled upgrade-main job but wrong here: run on this tree it moved 328 packages, including aws-cdk-lib, constructs, jest, eslint, and major jumps in glob (7 → 13), commander (14 → 15), chalk (5 → 6) and yargs (17 → 18). Burying seven CVE fixes in a wholesale upgrade makes the diff unreviewable and any regression unbisectable. Instead only the five advisory entries — plus the @img/sharp-* platform binaries, which are pinned to sharp's exact version — were dropped from the lockfile before yarn install, so everything else stayed pinned by the existing lockfile.

The resulting delta is 51 changed / 1 added / 1 removed, entirely within astro's own dependency closure and the five targets. No cdk or cli dependency moves. The remaining major bumps in that set (css-select 5 → 6, css-what 6 → 7, diff 8 → 9, magic-string 0.30 → 1.2) are all inside svgo's and astro's closures and are consequences of the required versions, not choices.

On version selection: MAL-2026-10726 — the malicious-release advisory that made #637 deliberately pin astro 7.1.3 instead of the 7.1.0 Dependabot proposed — was withdrawn on 2026-07-17 and no longer constrains the choice. I re-queried OSV for active malicious advisories against all five packages: none. smol-toml carries two further advisories (GHSA-pqhp-25j4-6hq9, GHSA-v3rj-xjv7-4jmq), both first-patched at 1.3.1 and 1.6.1, so 1.8.0 clears them too.

Verification

Run with AWS credentials unset, since the buildApp — AgentCore AZ wiring cases in cdk/test/main.test.ts assert the unpinned path and fail when auto-pin can resolve real zones (same caveat @vivibui notes on #867 and #868).

• mise run security:deps — the exact CI command — No issues found
• mise run security:retire — clean
• mise run drift-prevention — exit 0 (no transitive-pin drift into integrations/jira-forge-app; none of these five is mirrored there)
• mise //docs:build — 77 pages built clean under astro 7.2.8; mise //docs:check — 0 errors, 0 warnings, 0 hints
• mise run build — exit 0, with cdk 211 suites / 4,471 tests and cli 60 suites / 903 tests passing, plus the agent, docs, eslint and synth legs
• git status after the docs build shows only the two intended files, so the Starlight mirror is unchanged and the "Fail build on mutation" step is not in play

The bootstrap golden-baseline snapshot passes unchanged, which is the specific thing worth knowing for #867: js-yaml is what serialises the bootstrap template, and that PR tunes this dump's flowLevel. The 4.3.1 → 4.3.2 patch does not shift serialisation, so the two changes are independent.

Pre-existing failure, explicitly not mine

mise run check:deadcode-ratchet reports 111 findings against an 85 baseline (+26). I checked whether this branch caused it by restoring main's docs/package.json and yarn.lock, reinstalling, and re-running: it reports the identical 111. So the ratchet has been over baseline on main independently of this change, and CI's dead-code job is advisory and passes. Flagging it because a reviewer running the task locally will hit it and reasonably suspect this PR.

Adjacent finding, not fixed here

The root resolutions pin "@astrojs/mdx": "6.0.3" is now a major version behind its own requester: @astrojs/starlight asks for @astrojs/mdx@^7.0.5, and Yarn 1 silently collapses both descriptors onto 6.0.3, so starlight runs against an mdx it does not declare support for. yarn install says so directly:

warning Resolution field "@astrojs/[email protected]" is incompatible
  with requested version "@astrojs/mdx@^7.0.5"
warning " > @astrojs/[email protected]" has unmet peer dependency
  "astro@^6.4.0"

This is pre-existing on main, not introduced here — main has the identical conflict against starlight's ^7.0.0, and the only thing this PR changes is that starlight moved within its existing ^0.41.2 range and now asks for ^7.0.5. The pin dates to #522 and may well be deliberate, so unpicking it is a judgement call that does not belong in a security patch. Raising it rather than silently widening this PR — happy to file it separately.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[ayushtr-aws]

Review: Approve (with nits)

The change does exactly what it claims, and I verified it independently in a clean worktree. The one gap is process, not content.

Verified locally

Check	Result
osv-scanner on main's yarn.lock	7 advisories, matching the PR table exactly
osv-scanner on this branch's yarn.lock	No issues found
yarn install --frozen-lockfile	Succeeds, lockfile consistent with manifests
mise //docs:build under astro 7.2.8	Exit 0, Starlight mirror unchanged
Branch vs origin/main	Current

Supply-chain checks on the lockfile diff: all 64 new entries resolve to registry.yarnpkg.com with well-formed sha512 integrity; no residual vulnerable version remains under any descriptor for astro, sharp, svgo, js-yaml, or smol-toml; no new or bumped package defines preinstall/install/postinstall; none of the five packages appear in integrations/jira-forge-app/package-lock.json, so no #712 pin sync is needed. The eight cedar highlight warnings in the docs build are pre-existing on main.

Before merge (process, not code)

Attach an approved tracking issue. Per ADR-003 / AGENTS.md the branch should carry an issue number and the issue should carry approved. Anyone can open the issue; only the label needs a maintainer. Suggested labels to match #636 / #845: bug, dependencies, security, ci-cd, approved, P1. Given main's required check is red for every PR, this should not hold the merge beyond that.

Nits (non-blocking)

• New undici major mismatch (yarn.lock, the undici@^7.19.0, undici@^7.29.0, undici@^8.0.0 block). astro 7.2.8 pulls unifont 0.7.5, which now requests undici 8, and the root resolutions pin collapses it onto 7.29.0. The four symbols unifont imports (Agent, EnvHttpProxyAgent, getGlobalDispatcher, setGlobalDispatcher) all exist in undici 7 and docs/astro.config.mjs configures no fonts, so nothing breaks today. Worth a follow-up issue alongside the @astrojs/mdx mismatch you already flagged.
• Description accuracy. The body says starlight "now asks for @astrojs/mdx@^7.0.5". Starlight is unchanged at 0.41.3 and requests ^7.0.0 on both main and this branch.
• Ejection mechanism. The #867 failure was the pull_request run of the required check, not a merge_group run (no merge-group run has failed since 2026-08-12). Same effect, but the description overstates the merge-queue path.

Systemic finding for maintainers

The daily upgrade-main workflow has failed on every scheduled run since at least 2026-09-05 at the push step:

fatal: could not read Username for 'https://github.com': No such device or address

No open issue tracks this. It is the root reason advisories accumulate on main and PRs like this one keep being needed by hand. Recommend filing it as a P1 ci-cd bug.

Review agents run

code-review (medium) and a supply-chain security-review pass on the lockfile diff. Omitted silent-failure-hunter, type-design-analyzer, comment-analyzer, and pr-test-analyzer: the diff contains no code, types, comments, or tests.