Cloudflare：构建漏洞管理框架，将大语言模型噪声转化为全舰队防御引擎！

免费使用与联系销售

可免费开始使用，也可联系销售。

Cloudflare博客相关

可订阅以接收新文章通知，还有多个分类标签，如人工智能、开发者等。

构建你自己的漏洞管理框架

2026年6月18日发布，作者有Dan Jones、Alexandra Godoi、Grant Bourzikas，阅读时长17分钟。几周前发布了_Project Glasswing_的初步研究结果，探讨前沿安全模型应用于企业代码库的情况，还研究防御体系调整以保护基础设施和客户免受前沿AI威胁。AI生态系统快速变化，自主工作流程未来不依赖独立模型等。从局部安全“技能”转变为全舰队范围扫描管道，需将模型视为可互换组件，频繁更换和交叉测试模型，企业级管理框架要超越孤立代码仓库，追踪跨仓库依赖关系中的漏洞。本文将深入探讨构建与模型无关的层，包括管理状态控制、消除误报等工作。

预先解答两个疑问

第一篇文章阐述通用编码代理无法胜任工作，原因是代理一次只能持有一个假设，覆盖范围小且会丢失信息。接着回答两个问题：一是“为什么不使用子代理而要使用管理框架？”子代理有用但安全分析需持久性等，这是编排问题，仅靠提示词无法解决；二是“这篇博客文章只是在为前沿模型打广告吗？”不是，方法核心是管理框架，要构建与模型无关的系统，可自由选择模型。

一切始于一项技能

从约450行的`security - audit`技能开始，在单个代码仓库运行并调整提示词发现漏洞，后添加编排功能成为系统基础架构，提示词保留初始技能中的攻击场景等。该技能设计为7个阶段审计，包括侦察、Hunter代理攻击、验证等，且该技能映射到后来的管理框架。但该技能有局限性，单次运行发现漏洞约为多次运行的一半，发现的漏洞偏向简单类型。运行和微调技能遇到上下文耗尽、持久性、跨仓库推理三个问题。建议真正但最小化的管理框架包含侦察、狩猎和验证阶段及独立验证器，未拥有多个重要仓库前跳过跨仓库追踪，未被大量噪声淹没前无需专门去重代理，先在开发环境使用技能，缺少架构阶段拖慢进度时再构建。

将技能转化为管道

目前多数AI安全文章只涉及单个代码仓库或基准测试，而Cloudflare在整个代码库舰队中进行跨仓库追踪。代码库涵盖多种编程语言和配置管理系统等，花约六周时间将技能转化为管道，把技能各阶段拆分成独立代理，添加数据库和编排器，映射几乎一对一。整个代码库舰队在统一管理框架下运行，能追踪仓库依赖关系，管理框架专注安全编排高层逻辑，可在数百个代码库扩展，无需编写自定义语言解析器。

两阶段的漏洞研究工作流程

整个漏洞研究工作流程基于漏洞发现管理框架（VDH）和漏洞验证系统（VVS）两阶段操作框架。VDH主动扫描代码库发现潜在安全问题，漏洞进入VVS后经历去重、评估和修复等阶段。VDH和VVS使用不同模型，可相互检查，具有安全优势，管理框架能吸收下游波动性。

阶段1：漏洞发现管理框架（VDH）

重点讨论阶段之间衔接和决定流程有效的细节。各代理/阶段有不同主要角色和子代理/工具，如侦察绘制目标架构图，狩猎针对攻击类型攻击等。第4到8阶段作为连续生产者 - 消费者循环运行，确保后期发现的漏洞能得到处理。拆分管道保证严格上下文控制，每个代理工作高度聚焦，上下文使用量控制在总窗口25%以下。引入并行处理前要考虑持久性问题，每个阶段将数据写入SQLite数据库，发现的漏洞实时流式保存。建议明确对响应文本进行分类，避免将空运行记录为成功。

动态威胁建模

侦察阶段代理自行编写威胁模型，除内置攻击类型外，还可为特定仓库发明新攻击类型并制定方法，编写自定义分类法指导Hunter代理。Hunter代理超越代码阅读，进入主动执行阶段，编译代码片段等，通过提供沙箱提升检测质量。建议管理框架在Docker中运行时，沙箱需设置`seccomp = unconfined`和`apparmor = unconfined`。

微分叉和愿望清单

添加兄弟分叉和愿望清单两个机制。兄弟分叉确保Hunter代理遇到有趣代码路径不偏离轨道，派生兄弟代理，全舰队任务占比约9%，比例依赖模型。愿望清单让代理将需求写入中央愿望清单，系统可在人类提供依赖项后自动重新运行任务，部分需求可自我修复。自添加愿望清单以来，在128个代码仓库中已被写入25472次。

全舰队范围的跨仓库追踪

追踪代理检查软件组件连接方式，发现潜在攻击者路径后在消费者仓库派生新狩猎任务，需统一跨仓库符号索引和准确依赖关系图，可发现单仓库扫描遗漏的漏洞。大规模操作有两个经验教训：一是去重需专门代理，简单匹配无济于事，需认知推理；二是不要过早引入静态分析，Hunter代理更愿读取和运行代码，愿望清单是系统使用最频繁的工具。

生成可信的发现结果

要防止代理制造虚假漏洞，Hunter代理提交发现前需说明威胁模型，明确攻击者等，输出模式顺序强制执行。每个确认发现附带PoC测试，针对原始代码库运行，无有效PoC视为虚假发现，还需附带建议补丁。确定性代码机械验证文件和路径，验证器反驳Hunter代理理论，不自行记录发现。无法确定系统假阴性率，可通过重新运行发现新漏洞和覆盖范围增加衡量系统有效性。

阶段2：漏洞验证系统（VVS）

从管理框架输出的发现进入VVS，目前VVS包含来自145个代码仓库的13841个发现。VVS的分类引擎使用不同模型，分解为去重、评估、修复三个任务。

去重

使用大语言模型比较发现复杂度高，确定性代码构建倒排索引生成候选列表，代理查看列表确定是否可用一个修复方案解决多个漏洞，稳定跨运行键确保重新发现的漏洞打开现有记录。

上下文评估

评估是对幸存发现的第二次独立检查，代理获取信息确定代码路径在生产环境的可利用性和代码仓库所有者，将发现转化为基于风险的编排工作流程。

自动修复

修复代理获取建议补丁和单元测试，重写后应用补丁并运行有针对性测试，从失败到通过是理想情况，修复后测试失败提交会被阻止，修复代理不自行合并代码，需人类审查，这是人工干预保障措施。三个分类任务中，代理被限制在狭窄任务，由确定性簿记代码包装，无人类签字确认不写入生产环境，修复代理是系统中最年轻、最慢的部分。

成本分析

在整个代码库舰队运行数百个代理成本高，但成本分布可预测，计算预算主要用于狩猎阶段，填补空白是控制成本与覆盖范围的杠杆。按代码仓库分配预算，设置任务上限，启动工作池，大规模扫描是定期积压清理工作，复杂代码仓库全面扫描耗时久，更便宜、更小的管理框架适合检查。

如何衡量系统有效性

通过跟踪自动化管道过滤工程噪声为高质量发现的效果衡量系统有效性，成功指标是精准提炼原始数据。跟踪每个验证阶段后幸存的原始发现数量，初始验证拒绝率从40%下降到11%，高完整性发现比例从35%上升到58%。介绍从原始候选发现到可操作发现的终身分解情况，管理框架核心指标是控制未确认发现数量接近零，架构是严格过滤漏斗。VDH生成的20799个原始候选发现中约12057个通过验证，推送到VVS合并后中央漏洞池达13841个，去重代理合并5442个发现，1154个发现被标记处理，最终为工程团队留下7245个可操作发现。上下文评估层将合规检查转化为风险管理，架构能追踪漏洞来源，VDH系统性能可通过划分单元格和运行填补空白代理衡量，管理框架连接自动健康信号，独立分类过程增强系统健壮性。

我们的“北极星”指标：衡量现实世界中的效率

基于标准代码仓库运行情况制定基准测试，随着时间推移，全舰队范围持续循环去重等操作，终身候选发现数量将减少约65%。

通过自动修补节省的工程时间

通过技术吞吐量等衡量管道健康状况，初始验证筛选产生100个初始发现，运行3 - 4小时，保持高度聚焦上下文窗口；压缩层将发现从约100个压缩为80个高保真漏洞；修复代理以平均每个漏洞5分钟的速度处理80个漏洞，系统约14小时可完成发现、验证等工作并创建有效拉取请求。

缩短关键漏洞的平均修复时间

系统采用分层推出策略确保部署安全，隔离关键、高危和可利用漏洞，优先提交人工审核，5天内修复；其余潜在风险等漏洞15 - 20天逐步部署。

如何处理所有这些补丁

这些发现是研究实验结果，不代表实时生产环境漏洞。管理框架在测试环境持续运行，具体数字可能过时。每个漏洞附带测试用例和草稿补丁，安全团队正在处理报告并应用修复，Cloudflare产品已针对漏洞主动加固。同时发布了用于开发管理框架的初始技能，希望管理框架也能很快发布，可作为构建自己项目的起点。