安全组那句“依赖库漏洞，建议尽快热修”，在办公室里像一根刺。

真正做过平台的人都知道：热修不是技术动作，热修是一条权力通道。

常规发布列车再慢，也有秩序；热修通道再快，也最容易被人塞进“优先”。只要有人能在热修里分出“先拿到包的人”“先过验证的人”“先被目录标绿的人”，门票就会以一种更体面的方式复活——

“我们能帮你最快过热修验证。”

“我们有安全通道，先拿到补丁。”

“不跟我们做，明天目录变红你们就麻烦。”

林远盯着陈毅发来的消息，没有立刻要求“今晚就上”。他先问了三个问题，像把热修从情绪拉回证据：

1）漏洞影响什么链路？（采集入口/签名/验真/目录）

2）有没有可复现的最小样例？（不是概念风险，是可触发风险）

3）我们能否做到“公开编号、同步发布、统一验证”？（防优先）

陈毅回得很快：“影响采集入口链路的一段依赖，可能被构造输入触发异常，最坏会导致入口崩溃或错误码污染。安全组有PoC，但不建议外传。”

林远点头：“PoC不外传没问题，但编号必须外传。不外传编号，就会变成口耳相传的‘内部消息’，内部消息最值钱。”

他拿起笔，在白板上写下这次热修的第一条铁律：

热修可以快，但热修不能私。

一、SEC-HOTFIX-01：热修也要有“公开账本”

当晚，省信息处、数科安全、银行IT旁听、审计旁听开了一个短会。没有协会、没有顾问——因为热修本来就不该被“外包成口径”。

林远把一份一页纸的规则草案投到屏幕上，标题就像运行手册：

《SEC-HOTFIX-01｜安全热修通道规则（试行）》

内容只有四段，却把“优先权陷阱”一刀切断：

1）漏洞编号强制化（vuln_id）

任何进入热修通道的安全问题必须分配vuln_id

vuln_id公开，但不公开PoC细节

同时绑定影响范围桶：影响入口/签名/验真哪一段，是否涉及隐私或证据链完整性

2）补丁制品同步发布（Artifact Sync）

补丁不发给“个别合作方”，只发“公开制品库”

公开的是制品哈希、签名与版本号（不必公开源代码）

任何入口实现按同一时间点拉取同一制品，不存在“先拿到”

3）热修验证统一跑（HotfixConform）

热修上线必须跑一套专用测试：HotfixConform

测试结果公开到目录：通过/警告/失败（仅显示条款与错误桶）

验证窗口统一（例如6小时），窗口内过不过只看结果，不看关系

4）热修公告与过渡期

热修公告必须写清：受影响版本范围、建议升级路径、紧急程度分级（S1/S2/S3）