💻 computer science

Specification-Driven Development Benchmark: Security Knowledge Transition

本文通过提出一种将安全需求操作化的多层规范安全模型和安全知识迁移方法，旨在解决规范驱动型人工智能开发中的安全漏洞，并通过实证研究证明，与基准方法及基于 ASVS 条件的生成方法相比，这些方法显著降低了 API 失败率。

原作者： Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

发布于 2026-06-02

📖 1 分钟阅读☕ 轻松阅读

原作者： Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在雇佣一个超级快速、才华横溢的机器人厨师来为你建造一个复杂的餐厅厨房。你给机器人一份详细的食谱（即规格说明书），上面写着：“制作一个网球场预订系统，用户可以预订球场、支付费用并取消预约。”

这个机器人非常擅长遵循食谱。它完美地建造了炉灶、烤箱和点餐系统。然而，出现了一个问题：你忘了告诉机器人安全规则。你没有说：“不要让客户预订属于别人的球场，”或者“确保被停用用户无法再次潜入，”或者“不要让用户在预订后更改球场价格。”

因为没有明确告知机器人这些安全规则，它建造的厨房虽然在烹饪方面（功能性）表现出色，但却很危险（不安全）。它可能会让任何人进入 VIP 室，或者让客户偷走他人的预约。

这篇论文正是为了解决这个问题。作者们来自 EPAM Systems 的一个团队，他们认为当我们使用 AI 来编写软件时，我们不能仅仅依赖 AI 去“猜测”安全规则。我们必须像写烹饪指令一样，将它们明确地写下来。

以下是他们解决方案的简单拆解：

1. 问题所在：“沉默的安全”缺口

目前，当我们要求 AI 构建软件时，我们给它的是一份关于软件“应该做什么”的清单（功能性需求）。但我们经常忽略了软件“应该防止什么”（安全性需求）。

类比： 这就像告诉一名保安，“让人们进入大楼”，却忘了说，“但不要让他们进入金库。”保安完全执行了你的指令，但建筑被洗劫了。
结果： AI 构建的系统对用户来说运行完美，但在保护数据、拦截恶意行为或阻止滥用方面却失败了。

2. 解决方案：一份“安全蓝图”（多层模型）

作者们提出了一种与 AI 交谈的新方式。他们建议不要只给一份食谱，而是给 AI 一份安全蓝图。

把这份蓝图想象成一张连接各个要素的地图：

角色：（谁是用户？谁是管理员？）
反派：（会出现什么问题？如果有人试图窃取预订会怎样？）
规则：（如果用户试图窃取，系统必须说“不”并将其锁定。）
测试：（我们如何检查锁是否起作用？）

这份蓝图不仅仅是一份“要安全”的清单。它是一个结构化的链条，明确指出：“因为用户 A 试图访问资源 B，且这构成风险，所以我们必须实施规则 C，并且我们将通过场景 D 来测试它。” 这使得 AI 无法忽视或误解这些安全规则。

3. 流程：转化蓝图

论文描述了一种在 AI 开始编码之前，将普通的业务计划转化为这种富含安全信息的蓝图的方法。

第一步： 查看业务计划。
第二步： 要求 AI（或专家）根据该计划识别出所有潜在的“反派”和风险。
第三步： 将这些风险转化为代码中具体的、不可破坏的规则。
第四步： 将这个增强后的计划喂给 AI 以构建软件。

4. 实验：效果如何？

为了测试这一点，作者设置了一个“隐藏考试”。

他们给一个 AI 代理布置了一个任务：构建一个网球场预订系统。
他们用三种不同的指令运行了三次测试：
1. “不做任何事”组： AI 只得到了基础食谱（没有安全规则）。
2. “通用规则”组： AI 得到了食谱以及一份通用的安全规则列表（例如“始终检查密码”）。
3. “蓝图”组： AI 得到了食谱以及针对网球场定制的特定安全蓝图（例如“经理只能编辑由其管理的球场”）。

结果：
他们用一组包含 221 项安全测试（如尝试黑入系统、窃取数据或破坏规则）的隐藏测试集对所有系统进行了测试。

第 1 组（无规则）： 失败了 50 次。
第 2 组（通用规则）： 失败了 42 次。（有所改进，但仍会出错）。
第 3 组（蓝图）： 仅失败了 36 次。（表现最好）。

最大的提升发生在“业务逻辑”类别中。这意味着蓝图帮助 AI 更好地理解了网球领域的特定规则（如所有权和预订状态），而不仅仅是给予它通用的安全建议。

5. 结论

论文得出结论：通用的安全建议虽有帮助，但具体的、详细的蓝图才是必要的。

如果你想让 AI 构建一个安全的系统，你不能仅仅希望它知道规则。你必须构建一份“安全蓝图”，将业务规则与安全规则明确地连接起来。这份蓝图充当了桥梁，确保安全知识在 AI 编写代码的过程中不会在翻译中丢失。

简而言之： 不要只告诉 AI 要构建什么；要使用一张结构化的地图，明确告诉它如何保护它所构建的东西，从而不留任何猜测的空间。

技术摘要：面向安全知识传递的规范驱动开发基准

1. 问题陈述

本文探讨了 AI 辅助规范驱动开发（SDD）中一个关键的缺口。虽然现代大语言模型（LLM）智能体越来越多地被用于根据结构化规范（用户故事、API 合约、技术规范）生成代码，但在这一过程中存在显著的“安全知识丢失”现象。

在传统的 SDD 中，功能性需求被明确定义（例如，“用户可以创建预订”），但安全性需求往往保持隐性、通用，或被推迟到生成后的评审阶段。因此，生成的系统往往能满足可见的功能需求，却无法保留关键的安全行为，例如：

授权规则与所有权边界。
输入验证与令牌拒绝。
敏感数据处理与滥用案例语义。

作者认为，依赖 LLM 训练数据的先验知识来处理安全性是不稳定的。核心问题在于缺乏一种形式化的方法，将应用特定的安全知识表征在规范中，将该知识转移到生成的代码中，并在不向生成器泄露测试数据的情况下验证这种转移。

2. 方法论

本文提出了一个两部分的方案：一个多层规范安全模型和一个安全知识传递方法，并通过使用隐藏预言机（hidden-oracle）和隐藏黑盒（hidden-black-box）基准设计的两个实证研究进行评估。

A. 多层规范安全模型

该模型将安全知识操作化为一个可追溯的结构，而非扁平的检查清单。它由五个通过追溯链（系统实体 → 威胁/风险 → 需求 → 实现规则 → 代码元素 → 验证场景 → 证据）连接的核心层组成：

系统模型： 定义参与者、角色、资产、端点、信任边界和所有权规则。
威胁/风险登记册： 记录与特定资产相关的威胁、滥用案例及其根本原因。
设计层： 映射安全格局（受保护的资产、数据流）。
实现层： 将威胁转化为可操作的规则（例如，端点授权、对象所有权检查）。
验证层： 定义正向/负向测试、误用案例及证据要求。

B. 安全知识传递方法

这是一个将业务/技术规范转化为“安全增强型生成合约”的八阶段流水线：

规范获取： 收集需求和 OpenAPI 合约。
规范验证： 确保参与者和所有权规则的完整性。
安全相关提取： 标准化系统上下文。
威胁与风险推导： 使用诸如 OWASP ASVS 和 STRIDE 等来源推导风险。
安全需求合成： 创建可测试且可追溯的需求。
实现转换： 将需求转换为代码约束。
集成： 将安全约束直接注入到用于 AI 智能体的技术规范中。
验证转换： 从需求中推导出隐藏的测试场景。

C. 实验设计

评估采用了**隐藏评估器（hidden-evaluator）**方法以防止测试泄露：

研究 1（模型生成）： 一个 LLM 流水线尝试从系统上下文中推导出结构化的安全模型，而原始的威胁/风险模型（即“预言机”）保持隐藏。
研究 2（代码生成）： 一个 GPT-5.3-Codex 智能体在三种条件下生成一个网球场预订系统的 FastAPI 后端：
- 基准组 ( $C_0$ ): 仅包含功能规范。
- ASVS 条件组 ( $C_1$ ): 功能规范 + OWASP ASVS 需求。
- 多层模型条件组 ( $C_2$ ): 功能规范 + 应用特定的多层安全模型。
评估： 所有生成的后端都针对一个隐藏的 221 项测试黑盒 API 套件进行评估，该套件涵盖 15 个类别（如管理员安全、业务逻辑、授权）。

3. 核心贡献

多层规范安全模型： 一个通过系统实体、威胁、需求和验证证据之间的可追溯关系来表征安全知识的、可供 AI 消耗的结构化人工制品。
安全知识传递方法： 一个将规范转化为经过验证的安全增强型生成合约的流水线。
模型生成的实证验证： 证明了在隐藏预言机条件下，LLM 流水线可以从系统上下文中推断出特定领域的安全关注点。
代码生成案例研究： 提供实证证据表明，安全调节（security-conditioning）能改善生成的后端行为，特别展示了应用特定建模优于通用标准。

4. 结果

研究 1：安全模型生成

覆盖率： 生成的模型实现了对隐藏预言机的 100% 松散覆盖（所有 11 个威胁和 6 个风险至少在部分程度上得到了体现）。
精确度： 严格覆盖度中等（5/11 个威胁、4/6 个风险被完全覆盖），其余部分为部分覆盖。
结论： 该流水线可以恢复安全关注点空间，但生成的分类法需要专家进行对齐和精炼。

研究 2：后端生成性能

针对 221 项隐藏测试套件进行评估，其众数失败计数（三次运行中最频繁的结果）为：

基准组 ( $C_0$ ): 50 次失败（通过率 77.38%）。
ASVS 条件组 ( $C_1$ ): 42 次失败（通过率 81.00%）。
- 相对失败减少量： 较基准组减少 16.00%。
多层模型条件组 ( $C_2$ ): 36 次失败（通过率 83.71%）。
- 相对失败减少量： 较基准组减少 28.00%；较仅使用 ASVS 的组减少 14.29%。

类别级分析：

最显著的改进发生在应用特定类别中：
- 业务逻辑： 失败次数从 17 次降至 9 次（减少 47.06%）。
- 管理员安全： 失败次数从 2 次降至 0 次（减少 100%）。
- JWT Token： 失败次数从 1 次降至 0 次。
通用类别： 在输入验证等类别的改进较不明显，表明通用标准（ASVS）已涵盖了大部分此类内容。
回归： 观察到“合约一致性”失败次数略有增加（从 13 次增至 14 次），这归因于安全逻辑覆盖了模式保真度（例如，返回通用错误而非预期模式），表明需要集成合约感知的生成。

5. 意义与主张

本文主张，通用安全标准（如 OWASP ASVS）虽然能改善生成的安全行为，但不足以处理应用特定的安全语义。

核心论点： 安全知识必须是一个显式的生命周期人工制品。它不应留给模型先验或生成后的评审。
价值主张： 多层规范安全模型作为一个中间人工制品，将通用的安全概念与特定领域的具体参与者、资产、所有权规则和状态转换绑定在一起。
局限性： 作者明确指出，该模型是一个“安全需求操作化层”，而非对安全代码的保证。表现最好的条件组仍有 36/221 项测试失败，这使得隐藏黑盒测试变得必要。结果是基于单一领域（网球预订）和特定 LLM 智能体的初步证据，并不声称实现了完全的安全保证或跨领域的泛化。

文章总结道，规范驱动的 AI 开发需要一个专门的安全制品层，以减少可观测的安全知识丢失，从而弥合业务规则与安全实现之间的鸿沟。