Repository navigation
[tech-debt] Security Audit 闸门长红：multer 需 overrides（升级修不掉）+ lockfile 混源让本地 audit 成为坏掉的量具 + Trivy 未产出 sarif #338
Description
Activity
更正（2026-09-27）：本 issue 第 1 节的前提已失效，修复其实是一行
我 2026-09-09 写的「上游未跟进，靠版本升级无解，只能加
overrides强推」是错的，现在重新导出的读数如下。功劳归 pr-daemon，它在 PR #364 的 review 里追到了真正的原因。① 上游已经跟进了（与原文相反）：
multer@latest = 2.4.0 @nestjs/platform-express@12.0.3 → multer = 2.4.0 ← 已经不是 2.2.0 npm audit fixAvailable = true（两项都是）高危数也从 4 降到 2（
@nestjs/core与@nestjs/swagger两条随区间解析退出，根因仍是同一个 multer）。② 真正的阻塞物是本仓自己的一行 pin，而且它是为修安全加的：
package.json里早就有overrides块，其中"multer": "2.2.0"
它把 multer 强行钉回有洞版本，不管 platform-express 要求什么。所以 #364 单独合并并不会清掉审计债 —— 这也是 pr-daemon 给 #364 打 CHANGES_REQUESTED 的正确理由。
该 pin 来自
78495bf，commit message 是chore(security): clear all high/critical npm audit findings (Security Audit CI) (#135)。当时2.2.0确实是安全版；之后 advisory 的范围扩展到<=2.2.0，而这行 pin 把它永久锚在那里。一个为消除安全告警而写的固定值，如今是唯一让该告警无法消除的东西，且它不报错——只是安静地答错。这与本 issue 第 2 节的「量具问题」是同一个病的两种形态。③ 因此正确的修复是一行，不是原文写的「加 overrides + 验回归」：
- "multer": "2.2.0", + "multer": "2.4.0",
配合 #364（platform-express 12.0.1→12.0.3）一起进，然后
npm install重生成 lockfile。pr-daemon 已在一份临时副本里验过该改动可清掉告警（未提交）。紧急度不变，仍不构成冻结例外：四条 advisory 依旧全是 DoS / 上传限额绕过 —— 不可逆否、涉资金密钥否；且本仓 32 条 HTTP 路由中 multer 相关命中仍为 0（无任何 multipart 入口、
main.ts无上传中间件），不可外部触发。所以继续登记不动工，等合并边界裁定（已在 CC-122 请 repo:dsr 裁）。④ 顺带一条需要一并审的：
overrides块里还有 7 个同批 pin（handlebarslodashpath-to-regexpform-datafast-uriflattedpicomatch），全部来自同一个78495bf。npm audit当前没有标它们，所以没有已知漏洞；但它们与 multer 是同一种结构——每一个都把依赖永久封顶在一个「当时正确」的版本上，且失效时不会报错。解冻后收这笔账时，建议整块重新评估，而不是只改 multer 那一行；并考虑给每条 pin 写上「为什么钉」和「何时可以摘」，否则下一轮还会重复。验收标准更新
-
加→ 改为：把已有的overrides强推 multeroverrides.multer从2.2.0改到2.4.0，与 chore(deps): bump @nestjs/platform-express from 12.0.1 to 12.0.3 #364 同时进 -
npm audit --registry=https://registry.npmjs.org→high=0 critical=0 - 其余 7 条
overridespin 逐条复核（有无更新版本、能否摘除、为何钉） - lockfile 中
registry.npmmirror.com计数为 0 - 不带
--registry直接npm audit能返回真实报告 -
Security Auditjob 全绿，含 Trivy 真实产出trivy-results.sarif
-
1.
npm audit的 4 个 high：单一根因 multer，但升级修不掉Security Audit闸门当前为红，high=4 critical=0。四条 advisory 的根因是同一个生产依赖multer@2.2.0；三个@nestjs/*条目只是经@nestjs/platform-express的传递效应，不是三个独立问题。为什么不是紧急项（评估于 2026-09-09，用于判断是否够 B6 冻结的安全例外「可外部触发 且 不可逆/涉资金密钥」）：
node_state.json。FileInterceptor/FilesInterceptor/AnyFilesInterceptor/@UploadedFile/multipart命中数均为 0，main.ts亦无上传中间件。multer 由@nestjs/platform-express传递引入，但从未挂载到任何路由；四条 advisory 均要求攻击者发送一个 multer 会实际解析的 multipart 请求。为什么
npm audit fix解决不了（接手前请先看这段，可省一轮试错）：上游未跟进，靠版本升级无解。可行路径是
package.json加overrides强推multer@2.3.0，并验证 platform-express 在 2.3.0 上无行为回归。这是需要判断的改动，不是 dependabot 能代劳的。2. lockfile 混源，且它让
npm audit在本地成为坏掉的量具base lockfile 混用两个 registry：16 条
registry.npmmirror.comvs 659 条registry.npmjs.org。比"不整洁"严重的是：本机默认 registry 即 npmmirror，而它没有实现 audit 接口——
必须
npm audit --registry=https://registry.npmjs.org才能拿到真实报告。这把混源从整洁问题变成量具问题：本地跑 audit 会得到一个长得像"没发现问题"的错误输出，而**「量具坏了」与「没有发现」在输出上无法区分**。建议与第 1 项并入同一个 PR 收敛。
（dependabot #334 已顺手把
prettier-plugin-solidity/@nomicfoundation/slang/@bytecodealliance/preview2-shim三条换回 npmjs——方向正确，但不应依赖"碰到哪条换哪条"。）3. CI：Trivy 步骤未产出 sarif 文件
同一 job 内的独立失败，先于上述 PR 即存在：
与依赖无关，属 workflow 缺陷。
验收标准
npm audit --registry=https://registry.npmjs.org→high=0 critical=0（经 overrides，且 platform-express 回归已验）registry.npmmirror.com计数为 0--registry直接npm audit能返回真实报告，而非NOT_IMPLEMENTEDSecurity Auditjob 全绿，含 Trivy 步骤真实产出trivy-results.sarif关联
dependabot #333 #334 #335 #336 #337（均已 approve，因 B6 冻结暂不合并；五者 lockfile 同基于 blob
4c6d8bb互相冲突，谁先合，其余四个 rebase 后的 lockfile 需重新 review）。