# 我用一条持续集成流水线取代了十万美元的安全审计—

当我开发UltrafastSecp256k1——一个面向CPU、CUDA、OpenCL、Metal、ESP32以及十余种其他平台的高性能secp256k1密码学库时——我面临了一个每个严肃的密码学库作者最终都会遇到的抉择。

“你需要第三方审计。”

我收到的报价是：8万至12万美元。为期两周的审查。一份PDF报告。对下一次提交之后发生的问题没有任何合同责任。

我负担不起这笔费用。而且说实话，一旦我弄清楚自己实际上买的是什么，我就不想要它了。

于是我另辟蹊径，构建了别的东西。

快照式审计的问题

当前主流模式是：

代码 → 审计公司审查两周 → 发布PDF → 获得信任徽章

其结构性缺陷在于：这是一种快照，而非一套系统。

一份PDF只能告诉你审查那一刻代码的状态。它对下一次提交之后、新平台移植之后、新协议功能加入之后的情况只字未提。“已通过审计”的徽章即使在代码被彻底重写后依然存在。

试想一下：Heartbleed漏洞在OpenSSL中潜伏了整整两年。OpenSSL曾经过专家审查，并被广泛信任。问题不在于关注的人太少，而在于没有任何系统对出错的那个具体属性进行持续检查。

一个缺失的边界检查。两年时间。遍布所有生产环境。

持续对抗性审计系统（Continuous Adversarial Audit System）。

核心原则是：每一项安全声明都必须由一个可执行的测试来支撑，且该测试需在每次提交时运行。

不是“我们认为这段代码是恒定时间的”，而是：“针对此函数，ct-verif LLVM检查器、Valgrind污点分析和dudect统计计时测试全部通过——每次提交时，在x86-64和ARM64架构上均如此。”

以下是CAAS在UltrafastSecp256k1中的实际应用：

指标	数值
每次构建的断言数量	约100万+
漏洞概念验证测试	187个文件，171个已注册模块
CI工作流	36个GitHub Actions
每晚差异性检查	130万+次，对比libsecp256k1参考实现
恒定时间验证流水线	3套独立方案（LLVM ct-verif + Valgrind + dudect）
形式化证明	Z3 SMT（17项证明）+ Lean 4（19条定理），用于SafeGCD
构建矩阵	595种组合（7种架构 × 17种配置 × 5种操作系统）

当发现一个漏洞时——无论是我自己、贡献者、模糊测试，还是某篇新的ePrint论文指出的——它都会被转化为一个永久性回归测试：

{
  "id": "BUG-2026-0001",
  "category": "CT",
  "severity": "严重",
  "title": "ecdsa_sign_recoverable函数中低s标准化过程存在恒定时间分支泄露"

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。