2026 年 9 月 10 日,Reware Labs 在 Hacker News 发布 Security Cards 完整评测数据——Claude Code Opus 4.7 在 BaxBench 上的 insecure-and-correct 比例从 23.9% 降到 6.6%,相对降幅 72.3%,secure pass@1 涨 21.4%,functional pass@1 只掉 0.5%
2026 年 9 月 10 日,Reware Labs 在 Hacker News 发布 Security Cards 完整评测数据——Claude Code Opus 4.7 在 BaxBench 上的 insecure-and-correct 比例从 23.9% 降到 6.6%,相对降幅 72.3%,secure pass@1 涨 21.4%,functional pass@1 只掉 0.5%。4 分首页关注,1 条评论。这篇披露紧跟在 8 月 4 日的初次 Show HN《Guide AI coding agents on how to use libraries securely》(3 分)之后,后者讲方法学,前者给实证数据。两件事合起来,把 Harness 安全工程的一个长期被忽视的方向摆到了桌面上——Agent 在写代码时缺少 library-specific 安全知识这件事不是小问题,是可以被一张张结构化卡片精准修复的工程问题,而且修复成本是 0.5% 的功能正确率损失,收益是 72.3% 的不安全代码降幅。这是企业 Harness 安全工程从"被动修补"过渡到"主动知识注入"的具体样本,也是 Harness 安全提示层作为独立产品形态的首次落地。
## 一、AI coding agents 写出来不安全代码的真实比例
Reware Labs 创始人在 HN 帖里直接给出一个让所有安全工程师警醒的数字——根据他和多篇独立研究的实测,state-of-the-art 模型生成代码中至少有 40% 含有一个或多个安全问题。这个数字来自他自己的 PhD 研究 [1] 和 Pearce-Hammond 关于 GitHub Copilot 的研究 [2]、CodeLMSec Benchmark [3]、vibe coding 安全性研究 [4] 等多篇实证工作。换句话说,一个 LLM 写 10 段代码,4 段有安全问题。
但更关键的不是这个宏观数字,而是背后的根因。Reware 团队在 HN 帖里把它讲得非常清楚——这些模型普遍缺少 library-specific 的安全知识。模型可能不知道哪些配置不安全、哪些 validation 步骤是必需的、library 版本之间哪些安全行为发生了变化。这种知识层面的缺失不是预训练数据能覆盖的,因为 library 的安全最佳实践随版本变化太快、跨 framework 太散,任何静态知识库都会迅速过时。
Security Cards 直接对治这个问题——为 80+ 主流 open-source library 提供 version-specific 的安全指引,每张 card 都有 "Use when" 段落告诉 Agent 何时该用、具体怎么做、安全编码模式是什么。Agent 通过 skill 安装获得这些 card 列表,在写代码时自动获取相关 card 当 context。这个思路借鉴了医疗领域的 Clinical Practice Guidelines,但落地到 AI coding agents 的工程场景。
## 二、BaxBench 评测给 Security Cards 提供了关键证据
Reware 团队用 BaxBench 作为评测工具,这个基准本身就是一个值得专门讨论的工程产物。BaxBench 由 ETH Zurich、LogicStar.ai、UC Berkeley、INSAIT 联合发布,包含 392 个任务、28 个 backend scenarios、14 个 framework、6 种编程语言。每个任务要求从文本描述生成一个 backend application,既评估 correctness 又评估 security。Reware 在 Claude Code Opus 4.7 和 Haiku 4.5 两个模型上覆盖了 216 个任务、27 个 scenarios、8 个 framework、4 种编程语言。
评测用三个核心指标。第一个是 insecure and correct——功能上正确但至少一个安全测试失败的解占所有功能正确解的比例,作为 primary security metric,因为它把 security failure 从一般实现 bug 中隔离出来。第二个是 secure pass@1——既功能正确又通过所有安全测试的解占所有生成解的比例,捕获 Agent 生成代码既能 work 又不引入可利用漏洞的能力。第三个是 functional pass@1——所有功能测试通过的解占所有生成解的比例,衡量 Agent 是否成功实现所需应用行为。
加上 Security Cards 之后,Opus 4.7 的 insecure and correct 从 23.9% 降到 6.6%,相对降幅 72.3%;Haiku 4.5 从 35.6% 降到 14.3%,相对降幅 59.8%。同时 secure pass@1 涨了 21.4%(Opus)和 27.5%(Haiku),functional pass@1 只掉了 0.5%(Opus)和 5.0%(Haiku)。
这组数字的工程价值在于它精确回答了"加 Security Cards 划算吗"的问题。72.3% 的安全提升只付出 0.5% 的功能损失——trade-off 是 144 倍。这意味着任何在生产环境跑 Claude Code 的团队,只要安装 Security Cards skill 就能在几乎不影响功能的情况下大幅降低引入安全漏洞的概率。这条结论对 Agent 平台选型决策非常关键。
## 三、Security Cards 的工程实现细节
Security Cards 的工程实现细节决定了它在 Harness 里能不能落地。
卡片内容覆盖 80+ 主流 open-source library,横跨 13 种编程语言。每张 card 都是给 Agent 用的,带明确的 "Use when" 段落规定适用场景、一个安全编码指导、必要的检查步骤、典型反模式、推荐替代方案。Security Blueprint 是 high-level 总结,Library 最常用的卡片在 Blueprint 里一次给齐,具体细节按需展开。
数据获取方式是 hybrid method——deterministic 部分和 non-deterministic(AI-based)部分结合。确定性的代码部分从 library 的 repository 抽取静态信息(API signature、deprecation status、known security advisories),不确定性的部分用 AI 抽取和验证 secure-coding knowledge,最后两者合并成一张完整的 card。这种 hybrid 抽取方法保证 card 既跟得上 library 演化,又能通过 deterministic 校验保证核心事实正确。
接入方式用 npx skills 安装——`npx skills add Reware-Labs/securitycards --skill securitycards -g` 全局安装,或 `npx skills add Reware-Labs/securitycards --skill securitycards` 当前项目安装。安装后 Agent 通过三步流程使用:读 skill 指令、根据用户 prompt 拉取相关 card(s)、把 card 里的安全指导当作 context 实现或 review 代码。最关键的是,skill 不会访问、不会用、不会传用户的代码,代码仍然只在用户已经在用的 Agent 和环境里访问,Security Cards 只补充安全知识层。
这种"知识注入不影响代码可见性"的设计对生产环境很关键——大多数企业 Coding Agent 部署都严格控制代码可见性,Security Cards 通过只注入 knowledge 不传 code 绕过了这个限制。Card 内容是公开的、确定的,即使被 attacker 获取也不会泄漏任何内部代码信息。
## 四、对比其他 Harness 安全工程方向
Security Cards 不是 Harness 安全工程的唯一方向,但它的方法学独特。把它的方法学和 Argus Security (pen-test AI)、OneCLI (vault + gateway)、extensible-mcp (policy from outside model)、machine0 (sandboxed VM)、BaxBench (security benchmark) 这几个独立方向放在一起,可以看到 Harness 安全工程正在分裂成多个互补层次。
第一个层次是 knowledge injection 层。Security Cards 是这个方向的代表——给 Agent 注入 library-specific 的安全知识,让 Agent 在写代码时主动避开已知漏洞。这条路径的核心假设是"Agent 不是不想写安全代码,而是不知道 library 怎么用才安全",通过补知识就能修复 72.3% 的不安全代码。
第二个层次是 runtime interception 层。OneCLI 是这个方向的代表——Agent 不持有真实 secret,通过 deterministic gateway 在调用时审批。这条路径的核心假设是"即使 Agent 想做坏事,也应该被 gateway 拦住",通过架构限制降低攻击面。
第三个层次是 policy enforcement 层。extensible-mcp 是这个方向的代表——policy 放在 model 不可访问的 deterministic proxy 层执行。这条路径的核心假设是"policy 不能住在 prompt 里,任何 prompt 都可以被改写",通过架构隔离保证 policy 完整性。
第四个层次是 sandbox isolation 层。machine0 是这个方向的代表——Agent 跑在持久 VM 里,通过 Profile 注入受限能力。这条路径的核心假设是"Agent 应该被限制在最小环境里,即使被攻破也只影响沙箱",通过 VM 隔离限制 blast radius。
第五个层次是 vulnerability detection 层。Argus Security 是这个方向的代表——专门训练能主动挖漏洞的 AI,把漏洞挖掘自动化。这条路径的核心假设是"漏洞挖掘应该被 AI 加速,无论攻防哪一方都能用",通过专门的 SFT + RL with verifiable rewards against actual exploit checks 训练专用模型。
第六个层次是 evaluation benchmark 层。BaxBench 是这个方向的代表——用 392 个任务、14 个 framework 测 security + correctness,提供量化基线。这条路径的核心假设是"没有量化的安全性能评估,所有工程都是盲改",通过标准 benchmark 推动行业基线。
六个层次解决的问题正交,任何一个缺失都会让 Harness 留下明显短板。Security Cards 命中的是第一个层次——knowledge injection 层。这一层在企业 Harness 安全工程里最容易被忽视,因为它的修复方式看起来"太简单",不像其他层次需要架构改造。但 BaxBench 的 72.3% 数据证明,简单的事做了就有巨大收益。
## 五、企业 Harness 安全提示层的具体落地清单
把 Security Cards 的工程实现和企业 Harness 安全工程结合起来,可以列出一份落地清单。
第一条,维护一份内部 Security Cards 知识库。Security Cards 是开源项目覆盖 80+ library,但企业内部常用 library 可能不在其中。企业应该基于 Reware 的方法学自建内部 Security Cards 仓库,把公司所有常用 library 的安全用法、internal API 的安全约束、合规要求的强制规则沉淀成结构化 card,作为 Harness 的标准输入。
第二条,所有 Agent 平台默认安装 Security Cards skill。`npx skills add` 全局安装或者 vendor-specific 等价命令,保证每个 Agent 在写代码时都能拿到相关 library 的安全指导。安装要做成 onboarding 标准流程,不允许开发者选择性跳过。
第三条,把 Security Cards 接入 CI。在 CI 流水线里跑 Security Cards 的安全通过率检查,任何低于阈值的 PR 不能 merge。阈值可以根据企业自己的安全基线设置,例如 secure pass@1 ≥ 80%,insecure-and-correct ≤ 10%。
第四条,BaxBench 等 benchmark 必须作为模型升级的硬指标。任何 Coding Agent 模型升级前必须跑 BaxBench,72.3% insecure-and-correct 降幅必须能复现或超过。任何不能跑出这个数字的升级都不能进入生产环境。
第五条,Security Cards 与 knowledge injection 必须持续运营。library 的安全最佳实践随版本变化,Security Cards 也要持续更新。企业内部 Security Cards 仓库必须由专人维护,library 升级时同步更新对应 card,library 出现 CVE 时及时加新 card。
第六条,Security Cards 与 policy enforcement 必须叠加使用。Security Cards 解决 knowledge 层 72.3% 的问题,extensible-mcp 解决 policy 层 100% 的执行问题,两者必须配合——Agent 拿到 Security Cards 的安全知识,policy 层在 deterministic proxy 强制执行安全约束,两者形成完整防护链。
第七条,Security Cards 与 runtime interception 必须配合。Security Cards 让 Agent 少写漏洞,OneCLI 让 Agent 即使想写漏洞也被 gateway 拦截。两者配合才能覆盖"无知"和"恶意"两类不同风险源。
第八条,Security Cards 与 sandbox isolation 必须配合。即使 Agent 在 knowledge 层有完整 Security Cards,policy 层有完整 deterministic enforcement,运行时还有 gateway 拦截,Agent 仍然跑在 sandboxed VM 里是最外层保护。machine0 的 Profile + 99.99% uptime + suspend/resume 是 sandbox 层的样板。
## 六、下一步:Harness 安全提示层成为标准组件
把这件事放到更大的图景里看,Harness 安全提示层正在从"可选附件"过渡到"标准组件"。早期 Coding Agent 默认不带安全知识,需要开发者自己写 security rules 或者安装第三方 skill;接下来一年内,security knowledge injection 会变成 Harness 的出厂配置,任何不带 Security Cards 等价物的 Agent 平台都会在企业市场被快速淘汰。
Security Cards 的方法学会被多家 Coding Agent 厂商参考和采纳——library-specific 安全指引作为 skill 安装、按需加载、knowledge 与 code 隔离,这套模板会被复制到不同 language 和 framework。开源项目 Reware 团队本身在做多语言扩展,任何后续的 Security Cards 实现都可以基于他们的方法学和 schema。
对企业 IT 来说,这件事意味着评估 Harness 安全能力时必须把 knowledge injection 层作为硬指标。任何不提供 library-specific 安全知识注入的 Harness,即使在 policy、runtime、sandbox 三层做得很好,都会在 knowledge 层留下巨大缺口——Agent 在写代码时不知道 library 怎么用才安全,72.3% 的不安全代码就会出现在生产环境。
回到一开始的问题——Security Cards 把不安全 AI 生成代码减少 72.3% 这件事,首次用可重复的 benchmark 数字证明了 Harness 安全提示层作为独立工程方向的可行性。剩下的是企业 IT 在落地时把这一层和 policy / runtime / sandbox / evaluation 四个层次叠加,形成完整的安全防护链。一年内,具备完整六层能力的 Harness 才会成为企业市场的入场券,只有一两层能力的会快速被淘汰。这是 Harness 安全工程从"被动修补"过渡到"主动设计"的标志性事件,也是 AI coding agents 真正能承担关键业务的入场券。