尧图网页设计 
【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇技术指南围绕 GSD Core 仓库中的决策记录 .out-of-scope/npm-audit-retry-backoff.md 展开剖析 npm-audit CI 门禁在registry 端点慢/不可达时的失败模式、为何该提案未作为独立增强承接、以及当前仓库如何将重试退避、超时错误分类与基线 diff 真正落地为可运行的实现。读完本文你将掌握这套门禁的完整设计脉络从单次尝试、无退避的原始缺陷到isTimeoutKill谓词、共享超时错误构造器、有界指数退避调度再到基于 git 基线树的漏洞差异判定并能对照源码与测试验证每个关键结论。背景npm-audit 门禁的原始失败模式GSD Core 的 CI 中有一个强制性的 npm 依赖安全门禁源自 #3588其职责是生产依赖树中不得引入新的高危/中危 npm 公告advisory。门禁通过执行npm audit --omitdev --json并解析 JSON 输出来判定。这套机制的早期实现存在两类缺陷正是 决策记录 中 issue #4260 所描述的核心问题单次尝试、无退避在 POSIX CI 上审计恰好只尝试一次。所谓候选循环迭代的是 npm 二进制名npm/npm.cmd而不是重试次数——因此一次 registry 抖动就会让整个门禁失败。失败即阻断当registry.npmjs.org的 bulk-advisories 端点变慢或不可达时门禁直接抛错并阻断所有未合入的 PR。然而一次从未完成的网络请求并不能证明存在漏洞——把传输失败与真实漏洞混为一谈正是 #4260 反对的语义混淆。issue 中提出的具体机制是两条带退避的重试retry with backoff与缓存公告路径cached-advisory path。前者用于容忍端点抖动后者用于在端点长期降级时仍能给出判定。问题的另一半代码双重实现#4260 还指出一个工程隐患真正把 CI 变红的门禁逻辑tests/npm-integrity-gate.test.cjs中的auditProductionVulns携带了一份runPackageLockAudit的近似副本near-copy。因此即便只在scripts/npm-audit-baseline.cjs里加上重试也不会触及真正失败的路径——修复必须落在两个地方或者先完成提取extraction让修复只落在一处。这个修复位置隐患是 #4260 除了传输弹性之外的第二个关切。决策记录为什么单独承接被拒绝决策记录 给出的结论是wontfix——重定向到 #4251audit-gate 硬化工作日期为 2026-09-04。判定理由如下维护者认定该诉求已被在途工作覆盖#4251修复 #4250为两个审计调用点引入isTimeoutKill谓词与共享的超时错误构造器使超时的审计报告其真实原因而非一个令人困惑的Unexpected end of JSON input解析错误。因此把 retry/backoff 设计作为独立的增强 issue另行承接被婉拒硬化工作正在 #4251 中推进。范围备注2026-09-04 核实#4251并不完成提取——auditProductionVulns在tests/npm-integrity-gate.test.cjs中仍是runPackageLockAudit的独立近似副本带自己的候选循环与超时配置。因此 #4260 标记的修复位置隐患当时仍然存在任何未来的重试工作都必须同时触及两处或先完成提取。值得强调的是决策记录 明确承认该提案有两点判断正确、并未否认的观察其一单次尝试、无退避的观察是准确的其二半途提取只修好错误分类一半、重复本身未消除的观察是准确的——#4251 只处理了错误分类的一半而非重复本身。这份记录登记的是一个重定向而非对诊断的否定。明确不覆盖的范围决策记录的边界声明同样重要避免未来被错误引用不否认 #4251 工作流内部采纳 retry/backoff 或公告缓存如果该 PR 的后续工作采纳了这些机制本记录视为满足而非违反。不否认未来重新提交若 #4251 落地后门禁在传输错误上仍然无重试地硬失败则那个残余缺口是一个新 issue引用本记录即可。不涉及门禁对真实已发布公告的正常拦截——那正是门禁在正常工作从未被质疑#4260 明确声明不涉及。当前仓库中的实际落地从决策到实现决策记录描述的是 2026-09-04 时点的状态。而当前仓库快照本文撰写时的 scripts/npm-audit-baseline.cjs 已经将这套设计的核心全部落地为可运行代码且文件头注释明确以 #4196 与 #4260 为上下文。下面逐项对照源码。重试参数与退避调度参数定义区 给出了三个核心常量注释直接引用 #4260 的实测数据常量值语义AUDIT_ATTEMPT_TIMEOUT_MS60_000单次尝试超时。60s 可覆盖该端点实测过的最坏正常延迟43.41s见 #4260且在乘以AUDIT_MAX_ATTEMPTS后仍远低于旧的一次性 180s 预算AUDIT_MAX_ATTEMPTS3有界重试而非无界重试——registry 侧故障最终仍须让门禁失败#4260 自身的告诫在传输错误上静默解除强制安全检查比让它失败更糟AUDIT_BACKOFF_BASE_MS2_000指数退避基数尝试 1→2 等待 2s2→3 等待 4s退避的调度公式在重试循环中体现为AUDIT_BACKOFF_BASE_MS * (2 ** (attempt - 1))runNpmAuditWithRetry且两次尝试之间的睡眠由无外部依赖的sleepSyncMs基于SharedArrayBufferAtomics.wait的阻塞式同步睡眠实现见此处完成——因为execFileSync体系本身是同步的退避睡眠也必须同步。isTimeoutKill 谓词与共享超时错误构造器决策记录中提到 #4251 引入的isTimeoutKill谓词与共享超时错误构造器在 scripts/npm-audit-baseline.cjs 中已经存在并被导出isTimeoutKill当error.killed true或设置了error.signal时返回真。它区分两类失败——经execFileSync的timeout选项被 kill 的子进程慢/降级的 npm registry与正常退出但非零码npm audit发现漏洞时的正常形态。区别至关重要被杀进程的 stdout 在写入中途被截断不是完整 JSON把它当作可恢复的 JSON 会产生误导性的Unexpected end of JSON input而非点名真实原因。buildTimeoutKillError标准化的超时-kill 错误消息构造器供所有在耗尽重试后分类被 kill 的审计进程的调用方共享避免消息在调用方之间独立漂移。它还会附带 kill 前捕获的 stderr最多 2000 字符否则这些诊断信号会被直接丢弃无法回答为什么超时触发时 npm 仍在运行。有界重试语义核心函数 runNpmAuditWithRetry 实现了完整的重试语义仅重试确认的超时-kill只有isTimeoutKill为真的尝试会进入退避重试非超时失败如带可恢复 stdout 的真实非零退出或不可恢复的错误不重试因为重试确定性失败只会浪费预算而不改变结果。候选循环与重试循环分离内层候选循环遍历 npm 二进制Windows 为[npm.cmd, npm]POSIX 为[npm]一旦某个候选超时立即跳出候选循环进入下一次重试尝试不浪费备用候选槽位。stdout 恢复规则npm audit发现公告时以非零码退出但 JSON 仍在 stdout此时恢复 stdout 交给调用方分类——但仅当 stdout 确实携带 JSON 时被杀/中止的审计可以非零退出且 stdout 为空此时必须抛出捕获的错误而非空串否则解析处会露出裸的SyntaxError: Unexpected end of JSON input掩盖真实错误2026-09-03 在 CI 双 lane 上观测到过。耗尽所有尝试仍失败这是有界设计的核心——在传输错误上静默跳过强制安全检查是比重跑 CI 更糟的失败模式#4260 自身的告诫。共享审计路径与双重实现问题的解决决策记录标记的修复位置隐患auditProductionVulns是近似副本在当前仓库中已经解决runPackageLockAudit对仅凭锁文件的树执行npm audit --package-lock-only --omitdev --json不需要node_modules让基线树可以从解压出的 package.json package-lock.json 直接审计缺 package.json 或 package-lock.json 时返回null。runInstalledTreeAudit对真实已安装的 node_modules执行npm audit --omitdev --json缺 node_modules 时返回null。两者共享同一个runNpmAuditWithRetry重试与退避只实现一次。tests/npm-integrity-gate.test.cjs 中的auditProductionVulns如今只是runInstalledTreeAudit的薄包装return runInstalledTreeAudit(cwd, opts);独立的候选循环与旧AUDIT_TIMEOUT_MS常量已不存在——决策记录所担心的任何未来重试工作必须同时触及两处的隐患在当前仓库中已被消除。测试文件同时复用了AUDIT_ATTEMPT_TIMEOUT_MS、AUDIT_MAX_ATTEMPTS、AUDIT_BACKOFF_BASE_MS三个常量计算最坏耗时预算SINGLE_AUDIT_WORST_CASE_MS避免测试超时与真实退避调度独立漂移。基线 diff区分新引入与既有漏洞与 retry/backoff 配套的是基线 diff 机制源自 #4196 的教训PR #4188 在合并时通过门禁约 15 分钟后因新公告披露而在相同 commit 上失败。其思想是门禁只拦截 PR实际引入的漏洞未触碰的既有传递依赖中的已知漏洞不再阻断无关工作。四个关键函数全部在 scripts/npm-audit-baseline.cjs 中diffNewVulnerablePackages纯 diff返回 head 中脆弱但基线中不脆弱的包名集合仅按包名匹配不按公告 ID 或严重级别匹配——同一包在不同新公告下持续脆弱仍算既有严重级别升级则交给定时 Dependabot 通道处理#4196 / PR #4200 的自动合并工作流。evaluateAuditDiff类型化裁决返回{ ok, reason, newlyIntroduced }或{ ok: true, reason: OK_NO_NEW_VULNERABILITIES, preExisting }。extractBaselineTree在 git 对象层面用git show解出指定 ref 的 package.json package-lock.json 到临时目录无需工作树检出、无需npm ciref 不可解析或文件缺失时返回null。resolveBaselineRef按优先级解析基线 ref——①AUDIT_BASELINE_REF环境变量主机制②GITHUB_BASE_REF解析到origin/branch活期 tip降级回退③ push 事件的HEAD~1仅当 push 恰好单 commit 时正确rebase-merge 会使其落在同一 push 内更早的 commit 上而掩盖漏洞④origin/next或本地next分支全部失败返回调用方回退到严格的零容忍检查而非静默跳过。CI 环境变量接线.github/workflows/test.yml 为相关 job 显式设置基线 ref示例AUDIT_BASELINE_REF: ${{ github.event_name pull_request github.event.pull_request.base.sha || (github.event_name push github.event.before) || (github.event_name merge_group github.event.merge_group.base_sha) || }}三个事件分支分别取base.shaPR 事件运行期间固定、github.event.beforepush 事件git 对 push 前 ref 状态的记录即使 rebase-merge 落地为多 commit 也正确、merge_group.base_shamerge_group 事件补上 #4241 的缺口否则会落到resolveBaselineRef文档标注的不可达的origin/next活期 tip 回退重开 #4196 的竞态。工作流注释解释了为何不能用HEAD~1或活期origin/next作为基线。测试证据如何验证这套设计scripts/npm-audit-baseline.cjs 与 tests/npm-integrity-gate.test.cjs 由 tests/npm-audit-baseline.test.cjs 提供系统性的单元覆盖纯函数直测 真实临时 git 仓库无网络、无真实 registry 往返纯 diff/裁决diffNewVulnerablePackages的空集、新增、删除、双 undefined 不抛错等边界evaluateAuditDiff的ok:true/ok:false与newlyIntroduced精确集合。ref 解析优先级AUDIT_BASELINE_REF最高优先级、GITHUB_BASE_REF → origin/next、push 事件的HEAD~1父 commit、NULL_SHA哨兵40 位全零git 文档化的该 ref 在此 push 前不存在标志、无历史/无origin/next/非 git 目录时的逐级回落。基线树提取根目录与sdk/子目录提取、不存在 ref 返回null、ref 存在但从未提交锁文件返回null。文件系统级跳过条件缺 package.json、缺 package-lock.json、缺 node_modules 时返回null不可审计树而非错误。超时-kill 分类#4250/#4260用注入的execFileSyncImpl模拟每轮被 kill 的错误含截断的 stdout 与真实形态的 stderr断言最终抛出的错误消息匹配/npm audit timed out after \d attempts/、包含status.npmjs.org提及与Captured stderr before the last kill且不匹配Unexpected end of JSON input——这正是 #4250/#4260 要求的报告真实原因而非 JSON 解析错误另有前两次超时、第三次成功则整体成功且恰好调用 3 次的恢复用例以及正常非零退出且 stdout 完整 JSON 仍可恢复的无回归用例。退避时序#4260注入sleepImpl收集退避调用序列断言一次超时-恢复序列恰好睡眠一次且值为AUDIT_BACKOFF_BASE_MS * 1即 2s验证退避公式与实现一致。重新开启标准与残余风险决策记录 给出了两条重新开启标准对照当前仓库可以逐条评估PR #4251 落地且合并后的门禁在传输错误上仍无重试地关闭失败超时、连接拒绝、DNS且无重试、退避或缓存公告路径——此时残余弹性缺口是门禁的实存缺陷而非被重定向的增强。当前仓库中重试与退避已经落地runNpmAuditWithRetry覆盖runPackageLockAudit与runInstalledTreeAudit两条路径auditProductionVulns已收敛为薄包装因此这一条的无重试前提在当前快照中不再成立。npm bulk-advisories 端点的降级变得足够长期使缓存公告路径成为可靠性需求而非锦上添花。当前仓库尚未实现缓存公告路径——npm audit每次仍实时查询 registry。若端点进入长期降级期这一条仍可能触发新的独立 issue。此外决策记录中#4251 不完成提取、双重实现风险仍存在的备注属于记录时点2026-09-04的判定当前仓库快照中该隐患已通过auditProductionVulns → runInstalledTreeAudit的收敛消除这是后续工作按预期推进的直接证据。若要继续跟踪可关注 scripts/npm-audit-baseline.cjs 的改动历史与 .github/workflows/test.yml 中AUDIT_BASELINE_REF的接线。总结从 .out-of-scope/npm-audit-retry-backoff.md 这份重定向而非拒绝的决策记录出发本文还原了 GSD Core npm-audit 门禁传输弹性的完整演进原始的单次尝试失败模式 → #4260 提案区分无漏洞与未能查询、带退避重试、缓存公告路径→ 判定由 #4251 硬化工作覆盖 → 当前仓库中isTimeoutKill、共享超时错误构造器、有界指数退避、共享审计路径、基线 diff 与 CI 环境变量接线的全部落地。这套设计的三条核心经验可直接迁移到其他依赖 registry 的强制安全检查传输错误必须与真实告警分类对待用错误分类而非解析错误掩盖真相、重试必须是有界的且只针对可恢复的超时避免静默解除安全检查、修复必须落在共享路径上杜绝近似副本带来的双重维护与遗漏。当前仓库中唯一尚未落地的提案部分是缓存公告路径其未来是否推进取决于 npm bulk-advisories 端点的长期可用性——这正是决策记录预留的重新开启通道。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core 生产依赖零漏洞治理从 3588 修复到 npm audit 基线差异门gsd core 生产依赖零漏洞治理从 3588 修复到 npm audit 基线差异门 本篇技术指南以 gsd core 仓库归档的安全修复记录 fix 3opencodex 三轮审计驱动修复Cursor 上下文连续性、错误分类与传输加固的 AUDIT-LOOP 实践opencodex 三轮审计驱动修复Cursor 上下文连续性、错误分类与传输加固的 AUDIT LOOP 实践 本文以 审计第三轮合成报告 https://reconFTW 弹性恢复与超时安全设计模式解析断点续跑、磁盘看门狗与并行任务超时机制的落地地图reconFTW 弹性恢复与超时安全设计模式解析断点续跑、磁盘看门狗与并行任务超时机制的落地地图 reconFTW 的 Phase 1Resilient R渗透测试网络安全应用安全上一篇终极指南如何在Windows/Linux/macOS上编译sh1/sh shell工具下一篇流式账单全归零Spring AI 流式 Token 用量一行配置救回创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 npm-audit 门禁的传输弹性设计：GSD Core 中 retry/backoff、超时错误分类与基线 diff 的工程落地
【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇技术指南围绕 GSD Core 仓库中的决策记录 .out-of-scope/npm-audit-retry-backoff.md 展开剖析 npm-audit CI 门禁在registry 端点慢/不可达时的失败模式、为何该提案未作为独立增强承接、以及当前仓库如何将重试退避、超时错误分类与基线 diff 真正落地为可运行的实现。读完本文你将掌握这套门禁的完整设计脉络从单次尝试、无退避的原始缺陷到isTimeoutKill谓词、共享超时错误构造器、有界指数退避调度再到基于 git 基线树的漏洞差异判定并能对照源码与测试验证每个关键结论。背景npm-audit 门禁的原始失败模式GSD Core 的 CI 中有一个强制性的 npm 依赖安全门禁源自 #3588其职责是生产依赖树中不得引入新的高危/中危 npm 公告advisory。门禁通过执行npm audit --omitdev --json并解析 JSON 输出来判定。这套机制的早期实现存在两类缺陷正是 决策记录 中 issue #4260 所描述的核心问题单次尝试、无退避在 POSIX CI 上审计恰好只尝试一次。所谓候选循环迭代的是 npm 二进制名npm/npm.cmd而不是重试次数——因此一次 registry 抖动就会让整个门禁失败。失败即阻断当registry.npmjs.org的 bulk-advisories 端点变慢或不可达时门禁直接抛错并阻断所有未合入的 PR。然而一次从未完成的网络请求并不能证明存在漏洞——把传输失败与真实漏洞混为一谈正是 #4260 反对的语义混淆。issue 中提出的具体机制是两条带退避的重试retry with backoff与缓存公告路径cached-advisory path。前者用于容忍端点抖动后者用于在端点长期降级时仍能给出判定。问题的另一半代码双重实现#4260 还指出一个工程隐患真正把 CI 变红的门禁逻辑tests/npm-integrity-gate.test.cjs中的auditProductionVulns携带了一份runPackageLockAudit的近似副本near-copy。因此即便只在scripts/npm-audit-baseline.cjs里加上重试也不会触及真正失败的路径——修复必须落在两个地方或者先完成提取extraction让修复只落在一处。这个修复位置隐患是 #4260 除了传输弹性之外的第二个关切。决策记录为什么单独承接被拒绝决策记录 给出的结论是wontfix——重定向到 #4251audit-gate 硬化工作日期为 2026-09-04。判定理由如下维护者认定该诉求已被在途工作覆盖#4251修复 #4250为两个审计调用点引入isTimeoutKill谓词与共享的超时错误构造器使超时的审计报告其真实原因而非一个令人困惑的Unexpected end of JSON input解析错误。因此把 retry/backoff 设计作为独立的增强 issue另行承接被婉拒硬化工作正在 #4251 中推进。范围备注2026-09-04 核实#4251并不完成提取——auditProductionVulns在tests/npm-integrity-gate.test.cjs中仍是runPackageLockAudit的独立近似副本带自己的候选循环与超时配置。因此 #4260 标记的修复位置隐患当时仍然存在任何未来的重试工作都必须同时触及两处或先完成提取。值得强调的是决策记录 明确承认该提案有两点判断正确、并未否认的观察其一单次尝试、无退避的观察是准确的其二半途提取只修好错误分类一半、重复本身未消除的观察是准确的——#4251 只处理了错误分类的一半而非重复本身。这份记录登记的是一个重定向而非对诊断的否定。明确不覆盖的范围决策记录的边界声明同样重要避免未来被错误引用不否认 #4251 工作流内部采纳 retry/backoff 或公告缓存如果该 PR 的后续工作采纳了这些机制本记录视为满足而非违反。不否认未来重新提交若 #4251 落地后门禁在传输错误上仍然无重试地硬失败则那个残余缺口是一个新 issue引用本记录即可。不涉及门禁对真实已发布公告的正常拦截——那正是门禁在正常工作从未被质疑#4260 明确声明不涉及。当前仓库中的实际落地从决策到实现决策记录描述的是 2026-09-04 时点的状态。而当前仓库快照本文撰写时的 scripts/npm-audit-baseline.cjs 已经将这套设计的核心全部落地为可运行代码且文件头注释明确以 #4196 与 #4260 为上下文。下面逐项对照源码。重试参数与退避调度参数定义区 给出了三个核心常量注释直接引用 #4260 的实测数据常量值语义AUDIT_ATTEMPT_TIMEOUT_MS60_000单次尝试超时。60s 可覆盖该端点实测过的最坏正常延迟43.41s见 #4260且在乘以AUDIT_MAX_ATTEMPTS后仍远低于旧的一次性 180s 预算AUDIT_MAX_ATTEMPTS3有界重试而非无界重试——registry 侧故障最终仍须让门禁失败#4260 自身的告诫在传输错误上静默解除强制安全检查比让它失败更糟AUDIT_BACKOFF_BASE_MS2_000指数退避基数尝试 1→2 等待 2s2→3 等待 4s退避的调度公式在重试循环中体现为AUDIT_BACKOFF_BASE_MS * (2 ** (attempt - 1))runNpmAuditWithRetry且两次尝试之间的睡眠由无外部依赖的sleepSyncMs基于SharedArrayBufferAtomics.wait的阻塞式同步睡眠实现见此处完成——因为execFileSync体系本身是同步的退避睡眠也必须同步。isTimeoutKill 谓词与共享超时错误构造器决策记录中提到 #4251 引入的isTimeoutKill谓词与共享超时错误构造器在 scripts/npm-audit-baseline.cjs 中已经存在并被导出isTimeoutKill当error.killed true或设置了error.signal时返回真。它区分两类失败——经execFileSync的timeout选项被 kill 的子进程慢/降级的 npm registry与正常退出但非零码npm audit发现漏洞时的正常形态。区别至关重要被杀进程的 stdout 在写入中途被截断不是完整 JSON把它当作可恢复的 JSON 会产生误导性的Unexpected end of JSON input而非点名真实原因。buildTimeoutKillError标准化的超时-kill 错误消息构造器供所有在耗尽重试后分类被 kill 的审计进程的调用方共享避免消息在调用方之间独立漂移。它还会附带 kill 前捕获的 stderr最多 2000 字符否则这些诊断信号会被直接丢弃无法回答为什么超时触发时 npm 仍在运行。有界重试语义核心函数 runNpmAuditWithRetry 实现了完整的重试语义仅重试确认的超时-kill只有isTimeoutKill为真的尝试会进入退避重试非超时失败如带可恢复 stdout 的真实非零退出或不可恢复的错误不重试因为重试确定性失败只会浪费预算而不改变结果。候选循环与重试循环分离内层候选循环遍历 npm 二进制Windows 为[npm.cmd, npm]POSIX 为[npm]一旦某个候选超时立即跳出候选循环进入下一次重试尝试不浪费备用候选槽位。stdout 恢复规则npm audit发现公告时以非零码退出但 JSON 仍在 stdout此时恢复 stdout 交给调用方分类——但仅当 stdout 确实携带 JSON 时被杀/中止的审计可以非零退出且 stdout 为空此时必须抛出捕获的错误而非空串否则解析处会露出裸的SyntaxError: Unexpected end of JSON input掩盖真实错误2026-09-03 在 CI 双 lane 上观测到过。耗尽所有尝试仍失败这是有界设计的核心——在传输错误上静默跳过强制安全检查是比重跑 CI 更糟的失败模式#4260 自身的告诫。共享审计路径与双重实现问题的解决决策记录标记的修复位置隐患auditProductionVulns是近似副本在当前仓库中已经解决runPackageLockAudit对仅凭锁文件的树执行npm audit --package-lock-only --omitdev --json不需要node_modules让基线树可以从解压出的 package.json package-lock.json 直接审计缺 package.json 或 package-lock.json 时返回null。runInstalledTreeAudit对真实已安装的 node_modules执行npm audit --omitdev --json缺 node_modules 时返回null。两者共享同一个runNpmAuditWithRetry重试与退避只实现一次。tests/npm-integrity-gate.test.cjs 中的auditProductionVulns如今只是runInstalledTreeAudit的薄包装return runInstalledTreeAudit(cwd, opts);独立的候选循环与旧AUDIT_TIMEOUT_MS常量已不存在——决策记录所担心的任何未来重试工作必须同时触及两处的隐患在当前仓库中已被消除。测试文件同时复用了AUDIT_ATTEMPT_TIMEOUT_MS、AUDIT_MAX_ATTEMPTS、AUDIT_BACKOFF_BASE_MS三个常量计算最坏耗时预算SINGLE_AUDIT_WORST_CASE_MS避免测试超时与真实退避调度独立漂移。基线 diff区分新引入与既有漏洞与 retry/backoff 配套的是基线 diff 机制源自 #4196 的教训PR #4188 在合并时通过门禁约 15 分钟后因新公告披露而在相同 commit 上失败。其思想是门禁只拦截 PR实际引入的漏洞未触碰的既有传递依赖中的已知漏洞不再阻断无关工作。四个关键函数全部在 scripts/npm-audit-baseline.cjs 中diffNewVulnerablePackages纯 diff返回 head 中脆弱但基线中不脆弱的包名集合仅按包名匹配不按公告 ID 或严重级别匹配——同一包在不同新公告下持续脆弱仍算既有严重级别升级则交给定时 Dependabot 通道处理#4196 / PR #4200 的自动合并工作流。evaluateAuditDiff类型化裁决返回{ ok, reason, newlyIntroduced }或{ ok: true, reason: OK_NO_NEW_VULNERABILITIES, preExisting }。extractBaselineTree在 git 对象层面用git show解出指定 ref 的 package.json package-lock.json 到临时目录无需工作树检出、无需npm ciref 不可解析或文件缺失时返回null。resolveBaselineRef按优先级解析基线 ref——①AUDIT_BASELINE_REF环境变量主机制②GITHUB_BASE_REF解析到origin/branch活期 tip降级回退③ push 事件的HEAD~1仅当 push 恰好单 commit 时正确rebase-merge 会使其落在同一 push 内更早的 commit 上而掩盖漏洞④origin/next或本地next分支全部失败返回调用方回退到严格的零容忍检查而非静默跳过。CI 环境变量接线.github/workflows/test.yml 为相关 job 显式设置基线 ref示例AUDIT_BASELINE_REF: ${{ github.event_name pull_request github.event.pull_request.base.sha || (github.event_name push github.event.before) || (github.event_name merge_group github.event.merge_group.base_sha) || }}三个事件分支分别取base.shaPR 事件运行期间固定、github.event.beforepush 事件git 对 push 前 ref 状态的记录即使 rebase-merge 落地为多 commit 也正确、merge_group.base_shamerge_group 事件补上 #4241 的缺口否则会落到resolveBaselineRef文档标注的不可达的origin/next活期 tip 回退重开 #4196 的竞态。工作流注释解释了为何不能用HEAD~1或活期origin/next作为基线。测试证据如何验证这套设计scripts/npm-audit-baseline.cjs 与 tests/npm-integrity-gate.test.cjs 由 tests/npm-audit-baseline.test.cjs 提供系统性的单元覆盖纯函数直测 真实临时 git 仓库无网络、无真实 registry 往返纯 diff/裁决diffNewVulnerablePackages的空集、新增、删除、双 undefined 不抛错等边界evaluateAuditDiff的ok:true/ok:false与newlyIntroduced精确集合。ref 解析优先级AUDIT_BASELINE_REF最高优先级、GITHUB_BASE_REF → origin/next、push 事件的HEAD~1父 commit、NULL_SHA哨兵40 位全零git 文档化的该 ref 在此 push 前不存在标志、无历史/无origin/next/非 git 目录时的逐级回落。基线树提取根目录与sdk/子目录提取、不存在 ref 返回null、ref 存在但从未提交锁文件返回null。文件系统级跳过条件缺 package.json、缺 package-lock.json、缺 node_modules 时返回null不可审计树而非错误。超时-kill 分类#4250/#4260用注入的execFileSyncImpl模拟每轮被 kill 的错误含截断的 stdout 与真实形态的 stderr断言最终抛出的错误消息匹配/npm audit timed out after \d attempts/、包含status.npmjs.org提及与Captured stderr before the last kill且不匹配Unexpected end of JSON input——这正是 #4250/#4260 要求的报告真实原因而非 JSON 解析错误另有前两次超时、第三次成功则整体成功且恰好调用 3 次的恢复用例以及正常非零退出且 stdout 完整 JSON 仍可恢复的无回归用例。退避时序#4260注入sleepImpl收集退避调用序列断言一次超时-恢复序列恰好睡眠一次且值为AUDIT_BACKOFF_BASE_MS * 1即 2s验证退避公式与实现一致。重新开启标准与残余风险决策记录 给出了两条重新开启标准对照当前仓库可以逐条评估PR #4251 落地且合并后的门禁在传输错误上仍无重试地关闭失败超时、连接拒绝、DNS且无重试、退避或缓存公告路径——此时残余弹性缺口是门禁的实存缺陷而非被重定向的增强。当前仓库中重试与退避已经落地runNpmAuditWithRetry覆盖runPackageLockAudit与runInstalledTreeAudit两条路径auditProductionVulns已收敛为薄包装因此这一条的无重试前提在当前快照中不再成立。npm bulk-advisories 端点的降级变得足够长期使缓存公告路径成为可靠性需求而非锦上添花。当前仓库尚未实现缓存公告路径——npm audit每次仍实时查询 registry。若端点进入长期降级期这一条仍可能触发新的独立 issue。此外决策记录中#4251 不完成提取、双重实现风险仍存在的备注属于记录时点2026-09-04的判定当前仓库快照中该隐患已通过auditProductionVulns → runInstalledTreeAudit的收敛消除这是后续工作按预期推进的直接证据。若要继续跟踪可关注 scripts/npm-audit-baseline.cjs 的改动历史与 .github/workflows/test.yml 中AUDIT_BASELINE_REF的接线。总结从 .out-of-scope/npm-audit-retry-backoff.md 这份重定向而非拒绝的决策记录出发本文还原了 GSD Core npm-audit 门禁传输弹性的完整演进原始的单次尝试失败模式 → #4260 提案区分无漏洞与未能查询、带退避重试、缓存公告路径→ 判定由 #4251 硬化工作覆盖 → 当前仓库中isTimeoutKill、共享超时错误构造器、有界指数退避、共享审计路径、基线 diff 与 CI 环境变量接线的全部落地。这套设计的三条核心经验可直接迁移到其他依赖 registry 的强制安全检查传输错误必须与真实告警分类对待用错误分类而非解析错误掩盖真相、重试必须是有界的且只针对可恢复的超时避免静默解除安全检查、修复必须落在共享路径上杜绝近似副本带来的双重维护与遗漏。当前仓库中唯一尚未落地的提案部分是缓存公告路径其未来是否推进取决于 npm bulk-advisories 端点的长期可用性——这正是决策记录预留的重新开启通道。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core 生产依赖零漏洞治理从 3588 修复到 npm audit 基线差异门gsd core 生产依赖零漏洞治理从 3588 修复到 npm audit 基线差异门 本篇技术指南以 gsd core 仓库归档的安全修复记录 fix 3opencodex 三轮审计驱动修复Cursor 上下文连续性、错误分类与传输加固的 AUDIT-LOOP 实践opencodex 三轮审计驱动修复Cursor 上下文连续性、错误分类与传输加固的 AUDIT LOOP 实践 本文以 审计第三轮合成报告 https://reconFTW 弹性恢复与超时安全设计模式解析断点续跑、磁盘看门狗与并行任务超时机制的落地地图reconFTW 弹性恢复与超时安全设计模式解析断点续跑、磁盘看门狗与并行任务超时机制的落地地图 reconFTW 的 Phase 1Resilient R渗透测试网络安全应用安全上一篇终极指南如何在Windows/Linux/macOS上编译sh1/sh shell工具下一篇流式账单全归零Spring AI 流式 Token 用量一行配置救回创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考