Repository navigation
[finding] dependabot 报默认分支 7 个依赖漏洞(2 high / 4 moderate / 1 low)—— 请分诊定级与归属 #6090
Description
Activity
Triage: duplicate of #6088 — closing. Same 7 advisories, seen through a different reporting channel.
This issue registers the Dependabot banner (
7 vulnerabilities: 2 high, 4 moderate, 1 low). #6088, filed 17 minutes earlier at 00:15:59Z from the osv-scanner side (Validate Package Dependencies, run 31132523916), enumerates the full advisory table. The two counts reconcile exactly:GHSA CVSS GitHub severity package current patched GHSA-5p4m-2wfm-xmqj 7.5 high js-yaml 3.15.0 3.15.1 GHSA-5p4m-2wfm-xmqj 7.5 high js-yaml 4.3.0 4.3.1 GHSA-3rrr-jr9j-h3q3 6.5 moderate mermaid 11.16.0 11.16.1 GHSA-2v8p-3f2j-5mp7 5.3 moderate mermaid 11.16.0 11.16.1 GHSA-6x64-9x62-f2gx 5.3 moderate mermaid 11.16.0 11.16.1 GHSA-rhh3-jpg6-66xh 5.3 moderate mermaid 11.16.0 11.16.1 GHSA-c4c3-pg64-4m4v 2.4 low mermaid 11.16.0 11.16.1 ⇒ 2 high + 4 moderate + 1 low = 7, matching this issue's banner exactly. The severity split is not a coincidence of totals: it is the CVSS→GitHub-severity mapping of #6088's seven rows, row for row.
Independently verified against
origin/main(1eb13a0), not taken from #6088's text. The vulnerable versions are all present in the lockfile —js-yaml@3.15.0,js-yaml@4.3.0,mermaid@11.16.0(js-yaml@4.0.9/@5.2.2are also resolved but fall outside the advisory's ranges). Last lockfile commit is9c90ea0(feat(sms), #6042) — no OSV remediation has landed, so both reports describe the same live state.Note the triage seat could not read
GET /repos/.../dependabot/alertsdirectly (403,Resource not accessible by integration), so the reconciliation above is by severity arithmetic + lockfile evidence rather than by pulling the alert list. If someone with Security-tab access finds an eighth alert outside this table, reopen — the arithmetic is exact but it is arithmetic.Why close rather than cross-link: #6088 is already claimed and in flight (
pm:dispatched, sessionsession_01Wbxm29qPKnLf44AbSxizqW, branchclaude/issue-6088-osv-jsyaml-mermaid, 00:30:52Z), and its declared file surface ispnpm-lock.yaml. A lockfile fix is the canonical never-parallelize surface — two re-resolutions produce mutually unmergeable diffs (the #5032 precedent). Leaving an unassigned second entry for the same lockfile bump is precisely the shape that invites a second claim, and this issue's own body asks only for grading and routing — work #6088 has already absorbed. One thing, one dispatch entry.Nothing carried over is lost. This issue's three asks are all answered on #6088: ① the ranked list is its scan table above; ② routing — the lockfile is a shared-infrastructure surface, and the maintainer directed the
domain:clilane to take it (per the claim comment; the triage seat notes the fix touches no domain package, so nodomain:*label is warranted on a pure lockfile bump — recorded here rather than relabelling someone else's in-flight issue); ③ the "batch upgrade" shape is what #6088 is dispatched as — all seven have patch-level fixes.Maintainer may veto this closure by reopening; no restart condition is needed because the surviving issue carries the work.
本评论来自分诊座位 Routine(#5474 试点),不构成认领。 (This comment is from the triage-seat Routine; it is not a claim. Written in English per the language policy that took effect with #6029, merged 23:55:44Z.)
Generated by Claude Code
推送时 remote 提示(2026-08-06/07 夜间):
详情:https://github.com/objectstack-ai/objectstack/security/dependabot
按事实记录,unassigned,交分诊:① 读 dependabot 清单定级(哪 2 个 high、涉及哪些包、是否触达生产面);② 按落点包分车道;③ 若是纯 devDep/传递依赖的低危形态,按仓例批量升级单处理。本单只登记信号来源,不代判严重度。