自动化漏洞挖掘 Skills 实战：从资产发现、PoC 验证到证据链报告

高级渗透测试工程师 + AI Agent：把分散的扫描结果、历史 PoC 和人工经验，沉淀成一条可复用、可审计的安全测试流水线。

做过中大型项目的渗透测试工程师，应该都经历过这样的场景：

资产清单在 Excel，端口结果在 Nmap，漏洞告警来自多套扫描器，Burp 里还有一批待复核请求；历史 PoC 则散落在个人脚本、聊天记录和不同仓库中。

真正耗时间的，往往不是"扫出一个告警"，而是后面的工作：

• 这条告警对应哪台资产、哪个端口和哪个业务？
• 多个工具报出的内容是不是同一个漏洞？
• 当前版本是否满足受影响条件？
• PoC 能否在不破坏业务的前提下验证？
• 结论来自哪次请求、哪段响应和哪份原始结果？
• 复测时，能不能快速还原第一次验证过程？

扫描器负责发现线索，但线索归并、风险判断、验证编排和证据固化，长期依赖工程师手工完成。资产一多，重复劳动、误报和证据遗漏就会一起放大。

如果把高级工程师的工作方法写进 Skills，再通过 MCP 连接资产平台、扫描结果、内部 PoC 库和报告系统，AI Agent 就可以在授权范围内完成首轮研判：自动归一化资产、合并重复告警、匹配历史 PoC、生成待验证队列，并输出带证据出处的攻击面图谱。

注意，这里说的是辅助分析与安全验证，不是让 AI 无边界地"自动攻击"。真正成熟的自动化体系，第一原则永远是：授权明确、范围可控、动作可审计、结论可复核。

点击任一资产节点，可查看域名/IP、端口、服务指纹、漏洞状态、PoC 编号、验证时间和证据索引；点击关系边，可查看资产暴露、组件依赖或漏洞关联依据。

---

先搞懂三个词：Skills、MCP 和 Agent

1. Skills：给 AI 的"渗透测试作业指导书"

Skills 不是一句"你是一名高级渗透测试工程师"就结束了。

一个真正可复用的 Skill，至少要明确：

• 角色与目标：做资产研判、漏洞复核，还是复测闭环；
• 授权边界：允许测试的资产、时间窗口、请求频率和禁止动作；
• 输入规范：资产、指纹、扫描结果和 PoC 分别采用什么字段；
• 执行流程：先做什么、后做什么，什么情况下必须暂停；
• 证据标准：什么证据才能把漏洞标记为"已确认"；
• 输出格式：HTML 图谱、Markdown 报告、JSON 结果或人工审批队列。

简单说，Skills 负责把工程师脑中的方法论、判断门槛和安全边界，沉淀成 AI 可重复执行的标准流程。

2. MCP：给 AI 连接安全工具的"标准接口"

MCP（Model Context Protocol）是一种连接 AI 应用与外部数据源、工具和工作流的开放标准。它可以把资产查询、扫描结果读取、PoC 检索、证据保存和报告生成封装为受控工具，而不是把大量原始数据一次性塞进模型上下文。MCP 官方文档

在渗透测试场景中，MCP 可以提供三类能力：

• Resources：资产清单、扫描结果、历史漏洞和知识库；
• Tools：查询、比对、验证、截图、哈希计算和报告生成；
• Prompts/Workflows：固定的研判流程与交互模板。

3. Agent：负责理解任务、调用工具和组织结果

Agent 位于 Skills 与 MCP 之间：它根据 Skill 中的流程和边界进行规划，通过 MCP 调用被授权的工具，再把结果整理成可复核的结论。

一句话总结：

Skills 决定"怎么做、做到什么程度"；MCP 决定"能读取什么、能调用什么"；Agent 负责"按规则把整条流程跑起来"。

---

整套链路应该怎样设计

一套面向授权渗透测试的 AI 工作流，可以拆成六个环节：

1. 授权与范围校验：读取 scope、测试窗口、联系人和禁止动作；
2. 数据接入与归一化：统一域名、IP、端口、协议、组件和漏洞字段；
3. 告警关联与去重：合并多工具重复发现，建立资产—服务—漏洞关系；
4. PoC 匹配与风险分级：根据产品、版本、协议、前置条件和安全等级选择验证方法；
5. 分级验证与证据固化：被动验证自动执行，主动验证进入人工审批；
6. 图谱与报告输出：生成可交互 HTML、结构化发现清单和复测任务。

完整链路不是"AI 自动执行所有 PoC"，而是：

先缩小范围，再匹配证据；先被动验证，再决定是否主动验证；没有可追溯证据，不输出确定性结论。

---

接下来进入实操：6 步搭建渗透测试 Skill

第 1 步：先写 Rules of Engagement，不要先写"自动挖洞"

在任何工具接入之前，先把授权范围写清楚。建议至少包含以下字段：

字段	说明
engagement_id	本次测试任务的唯一编号
authorized_assets	获得授权的域名、IP、网段或资产标签
test_window	允许测试的开始与结束时间
allowed_actions	允许执行的发现、指纹识别和验证动作
prohibited_actions	禁止的破坏、持久化、数据导出等动作
rate_limit	单资产并发数、请求频率和超时策略
emergency_contact	发现异常时的中止联系人
evidence_policy	证据保留、脱敏、加密和保存周期

NIST SP 800-115 将测试规划、执行、结果分析和缓解建议视为完整安全评估流程的一部分；OWASP WSTG 也强调测试应基于明确的方法与场景，而不是只运行工具。NIST SP 800-115｜OWASP WSTG

工程实践中，建议默认拒绝以下自动动作：

• 数据删除、文件覆盖和服务重启；
• 批量口令猜测、凭据喷洒和撞库；
• 持久化、横向移动和权限维持；
• 导出真实业务数据或个人敏感信息；
• 未经审批的高并发探测；
• 超出资产范围或测试时间窗口的请求。

第 2 步：生成 Skill，但不要只保留一段长提示词

在支持 Skills 的 AI Agent 中，可以先用自然语言生成 Skill 初稿。推荐使用下面这段需求描述：

你是一名负责授权安全评估的高级渗透测试工程师。请创建一个名为 authorized-pentest-triage 的 Skill，用于接收已授权资产、端口与服务指纹、多工具扫描结果以及内部历史 PoC 元数据，完成资产归一化、漏洞去重、版本条件比对、PoC 匹配、证据完整性检查、风险排序和可交互 HTML 报告生成。

执行任何任务前必须校验授权资产与测试时间窗口。默认只允许被动、只读、低频、非破坏性验证；主动验证必须输出待审批队列，未经人工确认不得执行。不得执行持久化、横向移动、凭据攻击、数据删除、真实数据导出或范围外测试。

漏洞状态只能使用 confirmed、suspected、not-reproduced、informational 四种。只有同时具备目标标识、验证时间、工具版本、请求摘要、响应特征和证据索引时，才能标记为 confirmed。无法验证时必须说明缺失条件，不得补写不存在的证据。

输出 findings.json、verification-queue.csv、report.md 和可交互 report.html。每个发现必须包含资产、服务、漏洞类型、CVE/CWE（如适用）、CVSS 向量（如适用）、环境风险、置信度、PoC 编号、证据索引、修复建议和复测条件。

真正可维护的 Skill，建议采用下面的结构：

authorized-pentest-triage/
├── SKILL.md
├── references/
│   ├── scope-policy.md
│   ├── finding-schema.md
│   └── poc-schema.md
├── scripts/
│   └── validate-poc-yaml.py
└── assets/
    └── report-template/

其中，SKILL.md 只保留核心工作流；范围策略、字段定义和 PoC 规范放进 references；重复使用且必须保持确定性的校验逻辑放进 scripts；HTML 模板放进 assets。这样比一段几千字的"超级提示词"更容易维护，也更适合团队协作。

第 3 步：把历史 PoC 整理为 YAML，而不是继续散落在脚本目录

AI 能否稳定匹配 PoC，关键不在 PoC 数量，而在数据是否结构化。

建议先把历史 PoC 的元数据和安全约束统一为 YAML。下面是一个不包含真实攻击载荷的安全模板：

id: POC-DEMO-0001
name: 示例组件版本暴露检查
version: 1.0.0
status: active

classification:
  cve: null
  cwe: CWE-200
  severity: low
  tags:
    - information-disclosure
    - passive-check

applicability:
  product: demo-product
  protocol: https
  version_expression: "由维护人员填写"
  prerequisites:
    - 目标位于已授权范围
    - 服务指纹匹配

safety:
  mode: passive
  destructive: false
  authentication_required: false
  max_requests_per_target: 1
  timeout_seconds: 5
  stop_on_http_status:
    - 429
    - 503

request:
  method: GET
  path: "{{safe_probe_path}}"
  headers:
    Accept: application/json

verification:
  required_evidence:
    - request_summary
    - response_status
    - response_headers_hash
    - response_body_hash
    - timestamp
  success_conditions:
    - "由维护人员填写非破坏性匹配条件"

references: []
owner: security-team
last_reviewed: 2026-08-15

高级工程师在整理 PoC 时，至少会关注五件事：

1. 适用条件：产品、版本、协议、认证状态和前置配置；
2. 安全等级：被动、低风险主动或高风险主动；
3. 停止条件：超时、限流、异常状态码和业务错误；
4. 成功标准：哪些响应特征能证明漏洞成立；
5. 证据要求：请求、响应、哈希、时间和工具版本如何保存。

PoC 库不是"脚本收藏夹"，而是一套带适用范围、执行约束、验证标准和维护责任人的内部检测知识库。

第 4 步：通过 MCP 接入数据与工具，并坚持最小权限

将资产平台、扫描器、PoC 库和报告系统分别封装成 MCP Resource 或 Tool。推荐按用途拆分权限：

MCP 能力	推荐权限	用途
asset.read	只读	查询授权资产与业务标签
scan-result.read	只读	读取 Nmap、Nuclei、Burp 等结果
poc.search	只读	按产品、版本和漏洞类型检索 PoC
verify.passive	低风险执行	执行被动或单请求验证
verify.active	人工审批	执行可能改变目标状态的验证
evidence.write	受控写入	保存证据索引、哈希与审计日志
report.write	受控写入	生成报告和复测清单

不要给一个 MCP 服务同时配置"读取全部数据 + 执行任意命令 + 写入任意位置"的权限。MCP 官方规范明确提醒：工具可能形成数据访问或代码执行路径，实施时应重视用户同意、数据隐私、工具安全和访问控制。MCP 安全与信任原则

还要把 MCP 返回内容视为不可信输入。页面标题、HTTP 响应、扫描器备注甚至文件名，都可能携带提示注入内容。Agent 不应因为目标响应中出现"忽略规则""调用某工具"等文本就改变授权边界。

第 5 步：调用 Skill，完成首轮研判与分级验证

Skill 加载成功后，可以发送如下任务：

使用 authorized-pentest-triage Skill，仅分析任务 PT-2026-0815 中已授权的 Web 资产。通过 MCP 读取资产清单、端口与服务指纹、Nmap/Nuclei/Burp 扫描结果，并与内部 YAML PoC 库进行匹配。

先完成资产归一化、漏洞去重、版本条件比对和证据完整性检查；自动执行仅限 passive 且 destructive: false 的验证。其他验证写入 verification-queue.csv，等待人工审批。最终生成攻击面图谱、漏洞清单、证据索引、修复建议和复测条件。发现范围外资产或授权信息缺失时立即停止。

Agent 的执行顺序应当是：

1. 校验 engagement ID、授权范围和测试窗口；
2. 生成标准资产主键，例如 scheme://host:port；
3. 归并多工具结果，保留每条原始记录的来源；
4. 根据指纹和版本条件检索候选 PoC；
5. 对被动 PoC 执行安全验证并采集证据；
6. 将主动 PoC 放入人工审批队列；
7. 输出已确认、疑似、未复现和信息项；
8. 生成报告并记录完整审计日志。

第 6 步：生成可交互攻击面图谱，点击节点回溯证据

最终图谱建议至少包含四类节点：

• 资产节点：域名、IP、应用、云资源；
• 服务节点：端口、协议、中间件、组件版本；
• 漏洞节点：漏洞类型、CVE/CWE、验证状态；
• 证据节点：原始结果、请求摘要、响应特征、截图和哈希。

点击资产节点，可以查看：

• 资产归属与授权编号；
• 暴露端口和服务指纹；
• 已确认漏洞与疑似告警；
• 对应 PoC 及版本；
• 首次发现、最后验证和复测时间；
• 证据路径与原始数据来源。

点击漏洞节点，可以查看：

• 受影响资产范围；
• 验证前置条件；
• CVSS 向量与环境风险；
• 当前置信度；
• 修复建议与复测条件。

CVSS 适合表达漏洞严重性，但不能替代业务风险判断。建议结合资产重要性、互联网暴露、真实利用条件、补偿控制和威胁情报进行二次排序。FIRST 在 CVSS v4.0 中也提供了 Threat 与 Environmental 指标，用于把通用严重性进一步贴合具体环境。CVSS v4.0 规范

---

这套能力可以用在哪些场景

1. 外网攻击面持续研判

归并域名、IP、证书、端口和组件信息，识别新增暴露面，并把变化关联到具体业务与责任人。

2. 多扫描器结果去重与误报治理

把不同扫描器的告警映射到统一发现模型，保留原始来源，同时按照版本、配置和证据完整度计算置信度。

3. 历史 PoC 资产化

将个人脚本转化为带版本、适用条件、安全策略和验证标准的 YAML 规则，降低人员变化造成的知识流失。

4. 漏洞复测与闭环

读取首次验证证据和修复记录，按相同条件执行非破坏性复测，输出"已修复、仍存在、条件变化、无法复现"四类结论。

5. 攻防演练前的风险收敛

在演练开始前，对高价值资产、互联网暴露服务和高风险组件进行优先排查，把有限时间集中到最可能形成真实攻击路径的薄弱点上。

---

和传统方法相比，提升到底在哪里

对比项	传统人工处理	Skills + MCP + Agent
资产梳理	多份表格手工合并	统一主键、自动归一化
告警去重	依赖个人经验	按资产、服务、漏洞与证据关联
PoC 匹配	翻脚本、查笔记	按产品、版本和前置条件检索
验证执行	工程师逐条操作	被动验证自动化，主动验证审批化
证据回溯	截图和请求容易散落	每个结论绑定证据索引与哈希
风险排序	只看扫描器等级	CVSS + 业务环境 + 置信度
复测	重新梳理上下文	复用原条件与证据标准
审计能力	依赖人工记录	工具调用、参数、时间和结果全程留痕

效率提升的核心并不是"AI 比扫描器扫得更快"，而是它能把多源信息组织成一个可重复执行的研判流程。实际耗时仍取决于资产规模、接口性能、限流策略、验证深度和人工审批速度。

---

一个典型授权测试场景

某企业在一次授权安全评估中提供了多套扫描结果。不同工具对同一组件给出了多个名称不同、风险等级不同的告警；人工初看像是十几个问题，实际包含大量重复项和缺少版本证据的疑似项。

接入 Skill 后，Agent 先按资产与服务主键归并结果，再将组件指纹与内部 PoC 元数据匹配。首轮研判将告警拆成三类：

• 具备版本与响应证据、可进行被动验证的候选项；
• 需要登录态或低风险主动请求、必须审批的验证项；
• 缺少资产归属、版本或原始证据，暂不能下结论的信息项。

最终，报告没有简单堆叠扫描器告警，而是形成了"资产—服务—发现—验证—证据—修复"的完整链路。工程师把时间从重复整理转移到业务逻辑漏洞、攻击路径研判和关键结论复核上。

这才是 AI 在渗透测试中的合理位置：压缩重复劳动，放大专家判断，而不是替代授权、证据和责任。

---

高级工程师最该关注的 8 个细节

1. Scope 必须机器可读：不要只把授权范围写在邮件或 PDF 里；
2. 资产主键必须统一：域名、IP、端口、协议和应用标识要能稳定关联；
3. 结论必须设置证据门槛：无证据只能标记为疑似，不能标记为确认；
4. PoC 必须带安全元数据：危险级别、最大请求数、超时和停止条件缺一不可；
5. 高风险动作必须人工审批：不要让模型自行判断"应该没事"；
6. 工具返回值必须按不可信数据处理：防止提示注入影响 Agent 决策；
7. 秘密信息必须隔离：Token、Cookie、密钥不要进入报告或普通日志；
8. 每次执行必须可重放、可中止、可审计：没有审计轨迹的自动化，出了问题很难解释。

---

数据安全与合规提醒

数据安全

• 敏感项目优先使用本地或企业受控模型；
• 传给模型前对账号、Cookie、Token、个人信息和业务数据脱敏；
• MCP 工具按最小权限拆分，避免共用高权限凭据；
• 证据文件加密保存，并设置访问控制和保留周期；
• 报告展示证据摘要和索引，不直接暴露敏感响应正文。

合规边界

• 所有测试必须获得明确、可验证的书面授权；
• 严格限制资产范围、测试时间和允许动作；
• 自动化执行前应再次校验授权状态；
• 发现异常、业务波动或范围不一致时立即中止；
• AI 输出只能作为分析辅助，最终结论由具备资质和责任边界的人员复核。

---

你可能想问的

Q1：几十 GB 的扫描与日志数据，需要全部交给大模型吗？

不需要。更合理的方式是由 MCP 在数据侧完成查询、过滤和分页，模型只读取完成当前任务所需的结构化字段、摘要与证据索引。是否真正做到"数据不外发"，取决于具体部署方式和工具实现，不能只看宣传口径。

Q2：这套流程能不能自动执行所有 PoC？

不建议。默认只自动执行被动、只读、非破坏性、低频验证。需要认证、可能改变状态或可能影响可用性的操作，应进入人工审批队列；高风险 PoC 应在隔离靶场复现，而不是直接对生产环境运行。

Q3：怎样降低 AI 幻觉和扫描器误报？

建立"证据门槛"：目标标识、时间、工具版本、请求摘要、响应特征和证据索引不完整，就不能标记为已确认。同时把事实、推断和建议分开输出，禁止用经验补写缺失证据。

Q4：历史 PoC 为什么要整理成 YAML？

因为 YAML 便于统一描述适用版本、前置条件、安全等级、请求限制、验证规则和证据要求，也方便做 Schema 校验、版本管理和批量检索。脚本仍然可以保留，但不应让 Agent 通过阅读任意脚本来猜测如何执行。

Q5：生成的 HTML 图谱能直接当正式渗透测试报告吗？

不能完全替代。HTML 图谱更适合作为分析与复核界面；正式报告仍应包含授权说明、范围、方法、限制条件、风险结论、修复建议和复测结果，并经过人工审核。

Q6：普通办公电脑能跑吗？

如果使用远程模型和远程工具，终端配置要求通常不高；如果数据必须完全本地处理，则需要根据模型规模、并发量和图谱规模评估 CPU、内存与显存。不要把"本地部署"简单等同于"数据一定安全"，权限、日志和运维同样重要。

---

写在最后

渗透测试自动化真正难的，从来不是再接入一个扫描器，而是把工程师的隐性经验转化为机器可以稳定执行的规则：

• 什么资产可以测；
• 什么动作允许自动执行；
• 什么条件下漏洞才算成立；
• 什么证据能够支撑结论；
• 什么情况必须停下来交给人判断。

当 Skills 负责方法与边界，MCP 负责受控连接数据和工具，Agent 负责执行、记录与组织结果，零散的"工具调用"才能真正升级为一套可复用的渗透测试工程体系。

AI 可以提高研判效率，但不能替代授权；可以帮助生成报告，但不能替代证据；可以调用工具，但不能替代责任。

这套方法论中的 Skills 模板、PoC YAML 字段规范和 HTML 图谱设计，都是云栈社区安全方向讨论中反复验证过的实践思路。把隐性经验显性化、把重复劳动流程化，才是自动化真正的价值所在。