供应链信任延迟机制：从 2026 投毒事件的止损理论到产品化默认策略
2026.09.01 · 提出者 Dorothy
Issue 概览
- 状态
- 进行中
- 文章
- 2 篇
- 追踪线
- 2 条
- 更新
追踪线
2三天的冷却、一天的冷却、五分钟的扫描：信任延迟被内建成默认值
当信任延迟在 2026 年 5–7 月从社区应急止损变成 Dependabot 默认 3 天冷却、pnpm v11 默认 1 天 minimumReleaseAge、npm 发布时扫描（5–15 分钟可用性延迟）与 staged publishing 人工 2FA 批准之后，这些产品化延迟的语义分别是什么、各自覆盖哪类攻击、又继承了哪些与延迟无关的洞？
产品化把信任延迟拆成两种正交机制：消费者侧无条件时间门（Dependabot 3 天默认/pnpm 1440 分钟默认）赌社区在窗口内发现，注册表侧条件检测门（npm 扫描约 5–15 分钟）赌扫描器当场检出，两者不互相兜底；默认值的分布本身成为新的安全分界线（pnpm 默认开、Dependabot 默认 3 天仅版本更新、npm v12 默认收紧是能力性的且 CLI 无默认时间门）。pnpm trustPolicy:no-downgrade 比较信任通道等级而非内容，小沙海式同级接管不降级、不触发，证明层的边界原样搬进安装决策；冷却只延迟不裁决，残余风险是存活超过窗口的发布与等过窗口的新包投毒；dual-use 声明是新自查博弈层，但滥用仅是推断、无实证。
查看文章 →当安全工具先倒下：Trivy 凭据级联、Axios 社工与验证模型够不到的地方
当 Trivy 等安全工具本身成为投毒起点、投毒走合法发布路径时，'先验证再信任'的工件验证模型为什么拦不住，而'延迟拉取'的信任延迟却成为现实止损手段？
验证基础设施防御'工件被替换'（完整性），不防御'发布路径被劫持'（进程真实性）；安全工具按设计持高权限凭据、运行在装有不可信代码的机器上，是攻击面而非免疫；实际有效的止损是信任延迟（24h/7d 规则、靠社区12h发现兜底）、凭据隔离与发布通道加固（OIDC/不可变发布/commit SHA）。
查看文章 →
✦回复与讨论