CiscoDevNet/foundry-security-spec

# Foundry 安全规范 **来自 Cisco 的关于智能体 AI 安全评估的开放规范。** [](CHANGELOG.md) Cisco 的高级安全倡议小组内部构建并运行了一个智能体安全评估系统，经历了多次迭代和多种部署模型，在此过程中积累了大量被证明至关重要的设计决策，以及更长的被证明无关紧要的决策清单。 **Foundry 将这些经验提炼成了一个单一的、与组织无关的规范。** 这是经过多次迭代后，被一致证明最有效的设计。它不是我们的代码。它是一个行之有效的系统的架构，我们将学到的每一个教训都作为一项要求记录下来，而在每一个正确答案取决于*你的*基础设施的地方，我们都留作明确的悬而未决的问题。 你只需提供一个前沿的 LLM 和一个评估目标。Foundry 为你提供架构、不变式和防护机制。你可以利用这份规范作为蓝图，在自己的技术栈上构建自己的实现。 ## 此存储库包含的内容 | 文件 | 目的 | |---|---| | [`spec.md`](spec.md) | 初始规范。包含八个核心 agent 角色、五个扩展角色、finding 生命周期、协作基础架构、治理和安全要求，以及约 130 项功能要求，并附有内联说明解释其*存在的原因*。在每个特定于组织的决策点上都有意进行了模糊处理；这些点被标记为 `[NEEDS CLARIFICATION: ...]` 供你解决。 | | [`constitution.md`](constitution.md) | 十一条不可违背的原则，任何实现都必须遵循，无论使用何种技术栈。每一条都编码了我们曾经历过、诊断并修复过的生产故障。这些原则约束了从规范衍生出的每一个计划和任务。 | | [`GLOSSARY.md`](GLOSSARY.md) | Foundry 术语的独立词汇表，镜像自 [`spec.md` §2](spec.md#2-glossary)。适合只想了解词汇的读者。 | | 此 README | 如何将初始规范转化为你自己的系统。 | 此存储库中**没有代码**，这是有意为之的。规范本身就是交付成果。 ### 伴侣项目：CodeGuard 该贡献是 Foundry 设计核心的**从检测到预防的飞轮效应**： 1. **规则扫描**目标中的每一个功能。系统化、可重复，找出你已经知道要寻找的内容。 2. **探索性 agent 同时进行狩猎**。富有创造力，针对特定目标，找出尚未有规则描述的内容。 3. 当探索确认了规则遗漏的内容时，Foundry 会**记录规则盲区**。 4. 该盲区被**泛化为一条规则**（一条新规则，或是对本应触发的规则的修订）。该规则随后进入语料库。 5. 下一次扫描时，无论在此目标还是未来的任何目标上，都会**在第一轮就捕获这一整类问题**。探索则被释放出来，去更远的地方狩猎。 6. 循环往复。没有终态；每一次评估都会扩充语料库。 CodeGuard 独立存在，且早于这项工作；你可以使用不同的规则格式运行 Foundry。Foundry 增加的是一种机制，它将规则语料库从受维护的产物转变为可自我改进的产物。 ## 为什么我们发布的是规范而不是工具 我们的内部系统与 Cisco 的基础设施紧密耦合：我们的云提供商、issue 追踪系统、LLM gateway、部署平台和严重性分类体系。将那段代码开源只会给你一个恰好只能在一个环境中运行的东西：也就是我们的环境。 真正能转移的是*设计*：你需要哪些 agent 角色及其原因、每个角色必须保证什么、finding 如何从检测流向发布、评估的“完成”意味着什么、质量门位于何处，以及哪些捷径会在六个月后让你受挫。该设计是与基础设施无关的，这正是此存储库所包含的内容。 该规范专为通过 [spec-kit](https://github.com/github/spec-kit)（或任何规范驱动的开发工作流）使用而编写：你通过一个澄清步骤来解决针对你的环境的悬而未决的问题，然后另一边出来的就是基于*你的*技术栈、为*你的*实现量身定制的*你的*规范。 ## 适用对象 - **安全团队**：拥有前沿的 LLM、需要评估的软件，并面临“我们如何将这个模型转变为一个能产生我们可以信任的发现的系统？”这一问题。 - **平台和工具团队**：正在构建内部安全评估能力，宁愿从一个经过验证的架构开始，也不愿从一张白纸开始。 - **研究人员**：研究 AI 辅助的漏洞发现，希望获得一个基于生产运营而非基准测试的参考架构。 这**不是**一个现成的扫描器。如果你想要今天就可以 `pip install` 并直接指向某个 repo 的东西，那这不是你要找的。如果你想要构建你的组织在三年后仍在运行的系统，这就是你的蓝图。 ## 入门指南 ### 前置条件 - 支持 [spec-kit](https://github.com/github/spec-kit) 工作流的编程 agent（Claude Code 或兼容工具）。 - 一个将用于存放你的实现的 repo。 - 对于以下问题的初步答案：使用哪个 LLM 提供商、哪个 issue 追踪系统、哪个 datastore、在哪里运行。你不需要完全确定这些；澄清步骤会引导你完成。 ### 第 0 步：阅读 constitution 打开 [`constitution.md`](constitution.md) 并从头到尾阅读一遍。它很短。每项原则都有一段“为什么这是不可违背的”说明，描述了促成该原则的生产故障。如果任何原则看起来不适合你的情况，答案通常是“我们还没有遇到过那种失败”，而不是“这种失败不会在这里发生”。 ### 第 1 步：在你的项目中安装 spec-kit ### 第 2 步：安装 constitution ``` cp path/to/foundry/constitution.md your-project/.specify/memory/constitution.md ``` 然后运行 `/speckit.constitution` 并表明你正在采用现有的 constitution。agent 会将其注册为后续步骤要核对的标准。 ### 第 3 步：初始化规范 ``` mkdir -p your-project/specs/001-foundry cp path/to/foundry/spec.md your-project/specs/001-foundry/spec.md ``` ### 第 4 步：澄清 ``` /speckit.clarify ``` | 组别 | 示例 | 指导 | |---|---|---| | **身份与范围** | 系统名称；是否包含“具有源代码访问权限的授权评估”；合并/拆分/省略八个核心角色中的任何一个 | 先回答这些问题；它们决定了后续的一切。 | | **集成选择** | VCS、issue 追踪系统、LLM 提供商、datastore、部署目标、隔离 runtime、agent 运行框架、认证模型 | 初始规范描述了每个选项必须满足的*接口契约*。“我们使用 GitLab、一台 VM、Docker、SQLite”就足以完整回答其中一半的问题。 | | **策略选择** | 严重性方案、弱点分类体系、暴露 `needs-review`、标签命名、合规性映射 | 尽可能使用你组织现有的惯例。 | | **扩展范围** | 针对可选角色的五个是/否问题 | **建议：在你的首次构建中对所有五个问题都选“否”。** 先让八个核心角色产生可靠的 finding，然后再重新考虑。 | **提示：** - 对于集成和策略选择，“我还不知道”是可以接受的；计划步骤会再次提出它们。但对于身份和范围，这是不可接受的。 - 当初始规范提到“作者做了 X”时，那是一个操作示例，而不是建议。 - 当被问及“合并、拆分或省略”时，在回答之前请阅读该角色 §5 部分末尾的成本说明。 在澄清结束时，你的 `spec.md` 将被原地重写：标记被你的答案替换，丢弃的部分被移除，并附加了澄清记录。 ### 第 5 步：明确化 ``` /speckit.specify ``` 将澄清后的初始规范强化为完整的规范：扩展你的答案所必需的部分，连续重新编号功能要求，根据 constitution 进行验证，并将状态从 `SEED` 设置为 `DRAFT`。 ### 第 6 步：迭代澄清和明确化直到它们收敛 **明确化可能会引入新的模糊之处。** 特别是： - 如果你在 §6 中对任何扩展角色回答了*是*，明确化刚刚根据一段简短的描述为它编写了功能要求。这些要求几乎肯定会带有自己的 `[NEEDS CLARIFICATION: ...]` 标记（例如，对于 Attack-Mapper：使用哪种图存储、使用什么 node-id 方案、如何获取 by-design edges）。 - 你做出的集成选择可能会暴露出后续的决定（例如，选择自托管的 issue 追踪系统会暴露出“什么是 API endpoint 和认证模型”这个新问题）。 因此在明确化之后，再次运行 `/speckit.clarify`。如果它发现标记，请回答它们并重新运行明确化。重复此过程，直到澄清报告没有未解决的问题，**并且**通读 `spec.md` 时发现没有任何非你所做的决定。两到三轮是正常的；只有在你对每个扩展都回答“否”并且你的集成答案已经非常具体时，一轮才算是正常的。 在有标记遗留的情况下，不要进入计划阶段。如果 `[NEEDS CLARIFICATION]` 进入到 `/speckit.plan`，就会变成固化在你设计中的猜测。 ### 第 7 步：计划、任务、实现 ``` /speckit.plan # technical design satisfying the spec /speckit.tasks # ordered, dependency-aware build backlog /speckit.implement # work through it ``` 在完成重要的里程碑之后，运行 `/speckit.analyze` 来交叉检查规范、计划、任务和代码，以防出现偏差。 ## 初始规范给你的，以及不给你的 **给你的：** 架构（八个核心角色、五个扩展角色、基础架构）、finding 生命周期（状态、判定、证据门、指纹）、协作模型（原子声明、心跳存活检查、自动阻断）、治理模型（sandbox、预算、基于产出的自动停止、覆盖率门控），以及这背后每一个决策的理由。 **不给你的：** 检测规则、调查提示词、严重性评级标准、报告模板或任何其他*内容*。这些对于每个组织和每个目标都是不同的，而且它们是你系统最终质量的大部分来源。具体来说，你需要编写： - **检测规则语料库**（[§5.4](spec.md#54-detector)）。这是一个能够不断积累价值的产物：每一条规则都适用于未来的每一次评估，rule-gap 循环会告诉你接下来该写什么规则，而且相同的语料库可以重新部署到 LLM 编码助手中，作为开发期间的预防性防护机制。[CodeGuard](https://github.com/cosai-oasis/project-codeguard)（见上文*伴侣项目*）是一种满足规范规则语料库要求的具体格式；你可以采用它、fork 它，或者仅仅将其作为你自己实现的参考。 - **Cartographer 的文档模板**（[§5.3](spec.md#53-cartographer)）：针对你的目标类型，如何构建架构、攻击面、信任边界、数据流和威胁模型文档。 - **Triager 的调查程序**（[§5.5](spec.md#55-triager)）。 - **Reporter 的报告模板和严重性评级标准**（[§5.8](spec.md#58-reporter)）。 - 你的硬性规则区块（[§9.2](spec.md#92-scope-rules)），这超出了初始规范已经强制要求的 FR-111 最低限度。 初始规范的价值在于，当你编写出一条好的检测规则时，其周围的系统不会浪费它：该 finding 将被去重、受证据门控、尽可能被验证、报告一次，并计入完成进度；当探索发现你的规则遗漏了某些内容时，系统会告诉你接下来该编写哪条规则。 ## 架构一览 ``` OPERATOR │ ┌──────────────▼──────────────┐ │ ORCHESTRATOR │ │ lifecycle + conversational │ └──────────────┬──────────────┘ │ ════════ SUBSTRATE ════════ work queue · finding store sandbox · budget · dashboard ════════════╤═══════════════ │ knowledge layer │ finding pipeline oversight ┌───────┐┌─────────┐ │ ┌────────┐┌────────┐┌─────────┐┌────────┐┌─────────┐ │INDEXER││ CARTO- │──────────────┘ │DETECTOR││TRIAGER ││VALIDATOR││REPORTER││COVERAGE │ │ ││ GRAPHER │ │ ││ ││ ││ ││ GUIDE │ └───────┘└─────────┘ └────────┘└────────┘└─────────┘└────────┘└─────────┘ extension roles (build after core works): DEEP-TESTER · VARIANT-HUNTER · ATTACK-MAPPER · REMEDIATOR · SELF-IMPROVER ``` 八个核心角色，每一个都在捕捉前一个角色的失败模式。阅读[规范的 §4](spec.md#4-system-overview) 了解完整模型，阅读 [§5](spec.md#5-core-agent-roles) 了解各个角色的要求。 参见 [CHANGELOG.md](CHANGELOG.md)。 ## 安全 ## 来源 Foundry 由 Cisco Systems, Inc. 发布。它提炼了由 Cisco 的高级安全倡议小组构建和运营的内部安全评估系统的设计。该规范在设计上与组织无关；Cisco 的特定基础设施选择仅作为澄清问题中的操作示例出现，从不作为强制要求。 ## 致谢 规范和 constitution 的原作者： - Theo Morales (@kh0rvus) - John Allbritten (@jallbrit)

标签：C2, 防御加固