从 CBOM 到回滚按钮：PQC 迁移的 6 块工程拼图

副标题：工具链是把「接标准」能力长出来的载体

全文

§1 引子：迁移做完了，工具链没跟上

前两篇分别谈了「为什么现在就要动」（标准真空期）和「混合 HTTPS 落地撞了什么墙」（5 个工程问题）。这一篇回到一个更基础的问题：做迁移，到底要先把哪些工具/流水线/平台先搭好？

这不是一个新问题，但 2026 年变得尤其尖锐。

国密 PQC 标准预期 2027 底—2028 初发布 [来源：每日资讯-2026-09-04 §6.1]。在这之前的 12—18 个月里，几乎每个工程团队都会撞到同一组症状：

• 升级公告发下去了，但没人能回答"现在还有哪些地方在用 SM2"
• 某个 PR 提交了 crypto.createCipher('des') 过了 code review 才被发现
• 算法升级上线一周，监控拿不出"今天握手里有多少走的是混合 PQ 路径"
• 迁移结束后想做端到端的密钥轮换，发现 KMS 不支持 PQC 算法
• 算法候选被淘汰时，发现它已经写死在 5 个服务的配置里，拔不掉

这些症状的共同根因只有一个：迁移被当作季度项目做完，没有把工具链当作产品投资。

这一篇按"工具链"维度拆开看——从我自己的工程实践里，能稳定复用的就 6 块拼图：算法元数据注册表、CBOM、CI 策略门禁、KAT 自测、可观测性面板、KMS/HSM/TPM 适配，第六块之外还要加一个跨拼图的能力：应急回滚。

每块拼图都不是单一工具，而是「做这件事的最小可执行动作 + 一组可复用的反模式」。

§2 第一块拼图：算法元数据注册表

为什么：第一篇提了「密码敏捷性」——既然标准未定、候选会洗牌，工程唯一确定能投资的，就是让系统能在不推翻业务代码的前提下平滑切换算法。但敏捷性的最小前提，是每个算法都得能被查询：它是什么、它现在在哪个标准号下、它的经典与量子安全强度是多少、它处于什么迁移优先级。

没有这一步，后面 5 块拼图都失去坐标系——CI 门禁不知道该 fail 哪个算法，CBOM 不知道该标哪个字段，可观测性不知道该分几个桶。

怎么做：建一个独立的算法元数据模块（独立 npm 包、独立 git 仓库、独立服务都行，关键是能被多个上下游引用），按统一 schema 描述每个算法：

字段最少 6 个：类型、经典安全强度、量子安全强度、标准号、迁移优先级、状态。replacement 是预留字段，等 NGCC 第一轮候选公布后再填。

踩坑：注册表不要嵌进业务代码库。一是标准在变、字段在变，嵌进去会让业务跟着抖；二是多个仓库需要共享同一份事实源，跨仓 import 成本比独立包高 10 倍。

fibemate 出场：算法注册表是 fibemate packages/algorithm-registry/ 模块的内容，本文不复述字段细节，仅作"可复用的元数据 schema"的实例参考。具体结构以你团队的技术栈为准。

教训：把"量子安全强度"显式化，是密码敏捷性的最小可执行动作。不做的代价，是每次算法洗牌都要重新盘点代码——而盘点本身就是迁移里最贵的部分。

§3 第二块拼图：CBOM

为什么：CBOM（Cryptographic Bill of Materials）是密码学界的 SBOM——把散落在代码、证书、依赖、配置里的算法统一成一份清单。盘资产是迁移的第一步（第一篇 §6 的「治理节奏」第一节），没有 CBOM，后面所有动作都建立在猜测上。

怎么做：CBOM 不是一次生成的快照，是 CI 流水线里的"diff 检查"。具体三层：

• 代码层：grep/regex 抓 crypto.createCipher、sm2、RSA、ECDSA 等关键字，标注文件 + 行号
• 依赖层：npm audit / cargo audit / OSV API / Dependabot，标注包名 + 版本 + 已知漏洞
• 证书层：解析服务器实际加载的证书链，标注签名算法 + 公钥算法 + 有效期

产出格式走 CycloneDX 1.5+（已有 crypto 扩展字段）或 SPDX 3.0。CBOM 不需要自己写解析器，CycloneDX CLI、cdxgen、cryptobom-fabricator 这类工具链已经成熟。

踩坑：

• 不要把 CBOM 当一次性审计——算法在升级、依赖在引入、证书在轮换，CBOM 必须每次 PR 跑一次，diff > 阈值就 fail
• 不要漏掉二进制依赖——很多团队的密码学藏在 Docker 镜像的 node_modules 里，源码 grep 抓不到
• 不要只看签名算法——同一个 ECDSA-P256 证书可能在不同节点、不同协议层（TLS / S/MIME / 代码签名）出现，盘点必须按"用法"而不是"算法"分类

fibemate 出场：fibemate 用 tools/cbom-diff.js 做 CI 集成（PR 阶段自动 diff CBOM 变化），用 CycloneDX 1.5 + 自定义 crypto 扩展字段（量子安全强度、迁移优先级直接关联算法注册表）。本文不复述工具调用方式，以你团队的目标工具链为准。

教训：CBOM 的核心价值不是"它存在"，是"它会 diff"。一份静态 CBOM 文档，不如一个能在 PR 里 fail 的 CBOM diff 流水线。

§4 第三块拼图：CI 策略门禁

为什么：靠人记得"别用 SM2 / 别用 RSA-1024"是不可靠的。Code review 漏看是常态，特别是新员工、跨团队 PR、依赖升级——而这些恰恰是引入量子脆弱算法的高发场景。靠人记，迟早翻车；靠流水线强制，才有可能稳定。

怎么做：CI 门禁分四档，从软到硬：

Lint 规则示例：

• no-js-bigint-in-hotpath：禁止 BigInt 进入密码学热路径（侧信道风险）
• no-md5 / no-sha1 / no-rc4：硬禁用已知弱算法
• no-createCipher：强制走 createCipheriv

CBOM diff 门禁示例：算法注册表中 status: "deprecated-by-pqc" 且被新 PR 引入 = warning；status: "forbidden" = fail。

踩坑：

• 门禁太严会卡正常 PR——比如 no-createCipher 一刀切会让所有 cipher = crypto.createCipher('aes-256-cbc', key) 这种「旧但还能用」的代码全部 fail，但业务侧没人力立刻改完。要分级：先 warning 跑半年，等存量清得差不多再升级到 fail
• 门禁要可绕过——合规/特殊业务确实需要用某个禁用算法时，PR 里加 # cryptography-waiver: <理由> 注解 + 责任人 approve 才能合，这是工业实践（GitHub 自身在 Dependabot 里就是这么做的）
• 门禁必须可观测——fail 了多少次、哪种 fail 最常见，需要面板；否则半年后没人记得为啥有这个规则

fibemate 出场：fibemate 用 ESLint + 自定义规则 + --max-warnings 0 强制（CI 红就 fail），配套 no-js-bigint-in-hotpath 规则覆盖 PQC 热路径；同时跑 CodeQL 周扫 + Dependabot 周更。这是 6 块拼图里 fibemate 投入最重的一块，但不是"移植即用"的——每团队的目标环境差异大，规则集要按实际资产调整。

教训：CI 门禁不是"装上 ESLint 就完事"。它是一个持续治理的产品——规则集、阈值、豁免流程、观测面板，每个都要单独维护。把它当一次配置，是放弃它最常见的方式。

§5 第四块拼图：KAT 与自测

为什么：算法实现经常微妙错——一个比特位移、一行错位、一个 magic number 多一位，就能让整个算法的 roundtrip 全失败，或者更糟：通过随机测试但在生产流量下统计性失败。第二篇 §2 的"延迟被低估"本质上是性能侧的问题，但密码学侧有一类更危险的失败：算法"看起来在工作"但输出错。

怎么做：KAT（Known Answer Tests）是密码学自测的最小可执行动作。三层：

• NIST 标准向量：FIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）官方 test vectors，逐字节对比
• 跨实现交叉验证：与独立实现（noble、liboqs、Bouncy Castle）做 round-trip 交叉，确保自己不是唯一实现
• 长跑稳定性测试：1000—100,000 轮连续 keygen + encaps + decaps，验证无内存泄漏、无状态污染、无随机性退化

KAT 数据集本身不大（一个 NIST vector 文件几百 KB 到几 MB），完全可以塞进 CI。每跑一次 PR < 30 秒。

踩坑：

• 多个副本的"同源不同实现"——同一种算法在不同目录下出现 4 份实现是常态（fibemate 实战里有过），其中一份错的概率不低；KAT 必须覆盖所有副本
• 实现对，但 KAT 测的不全——encapsulate(decapsulate(...)) roundtrip 过了不代表实现正确，比如 2-bit vs 1-bit 编码错位能让 roundtrip 全过（因为高位的 noise 被 compress(_, 1) 抹掉了），但跨实现交叉就会暴露（第二份实现按 1-bit 解，自然错位）
• KAT 只测 happy path——必须额外加 negative test：篡改密文 → 不同 ss；篡改签名 → verify 失败；错误 key → decaps 失败。这些比 happy path 更能抓实现错

fibemate 出场：fibemate 在 ML-KEM-768 上跑过 10,000 轮 KAT（含 noble、liboqs、wasm 三实现交叉），SM2 上跑过 100,000 轮（含 TVLA 侧信道）。KAT 数据 + 自测脚本都在 packages/pqc-kem/test/ 与 packages/sm2-ref/test/。KAT 实践几乎是 fibemate 投入产出比最高的一块——一次写好，长跑有效。

教训：KAT 是密码学项目的"安全网"，不是"测试通过证书"。它防的不是"算法错"（标准里定义了），是"实现错"（人手写的错）。两类错都需要 KAT 兜住。