我做了一个 AI 原生安全测试 Skill：让 Claude Code/Cursor 直接进入安全工程模式

安全风信子

1036人浏览 · 2026-08-11 17:50:46

安全风信子 · 2026-08-11 17:50:46 发布

作者： HOS(安全风信子)
日期： 2026-02-26
主要来源平台： GitHub（HOS_SKILL_WORKFLOW）
读完你能学到： 你会理解 HOS-Sec-Engine 如何用"流程模板 + 决策树 + CVE 实时集成 + MCP 管理层"四件套，把一个只会聊天的 AI 助手变成真正能进入安全工程流程的执行层，并学会在 Claude Code / Cursor 中把它落地成一等公民的 Security Skill。

先看问题场景

“帮我看下这段代码有没有安全问题。”

这是我过去半年里问 AI 助手最多的一句话。说实话，90% 的回复都让我脊背发凉：模型确实认识 SQL 注入、XSS 这些词，它能把 OWASP Top 10 背得像教科书一样工整，但只要你让它对一个真实项目做安全测试，它就开始表演迷惑行为——

要么一本正经地跟你讲"我认为这个接口可能存在风险"，然后给不出任何一条证据；
要么用 curl 对着域名扫两下就宣布"未发现高危漏洞"，实际它连登录态都没有；
更常见的是，它把某份扫描报告念一遍，然后跟你打太极：“建议使用专业工具进一步验证”。

这不是模型的智商问题，是工程架构问题。大模型有安全知识，但它没有一个能把这些知识变成"可执行动作序列"的运行时。知识是点，流程是线，没有线，点再多也织不成网。

2025 年我在一个客户的交付项目里踩过最疼的一个坑：开发同学用 Cursor 三小时写完一个带文件上传的模块，npm run build 全绿、联调全通过、评审没人提异议。我随手一测——文件上传接口直接可以传 .jsp / .aspx 双扩展名文件，上传后文件还落在 Web 根目录下可被直接访问。一个能 getshell 的洞，在"全员 AI 写代码"的团队里躺了一周没人发现。 因为团队里根本没有人"像黑客一样"去测它，也没有任何环节会主动触发这种测试。

那一刻我意识到：AI Coding 时代真正缺的不是又一把扫描器，而是一个能让 AI Agent 主动、有方法论、可重复地执行安全测试的执行层。扫描器只能回答"这行代码像不像有问题"，而我们要的是"这个系统现在能不能被打穿、漏洞链怎么走、怎么修、修完怎么验证"。

所以我做了 HOS-Sec-Engine——一个 AI 原生安全测试 Skill。这篇文章就是它的完整拆解：为什么传统工具在 AI Coding 时代失灵、这个 Skill 怎么让 Claude Code / Cursor 进入"安全工程模式"、以及整颗引擎最关键的设计——让 AI 学会"什么时候调用什么工具"。

本节核心收获：AI 助手安全测试翻车，根因是"有知识没有流程执行层"；传统扫描器在 AI Coding 时代已明显跟不上，真正需要的是 Security Skill 而非又一个 Scanner。

一、AI Coding 时代，安全测试为什么越来越跟不上

1.1 代码生产速度，第一次超过了安全消费速度

先算一笔账，可能你也有同感。过去一个 5 人开发团队一周写 2000 行代码已经是高强度；今天一个普通工程师带着 Claude Code / Cursor，一天就能产出同样量级——而且每一行都可能带着漏洞。不是 AI 写得比人差，而是 AI 写得比人快得多，漏洞的绝对数量就跟着涨。

安全侧呢？还是老节奏：人工代码审计，一个资深安全工程师一天能细审多少行？撑死 1000~2000 行，还要精神高度集中。生产端在加速，消费端没有加速，缺口只会越拉越大。 如果用公式表达，就是 $\Delta v = v_{\text{prod}} - v_{\text{sec}}$ ，其中 $v_{\text{prod}}$ 是代码生产速度、 $v_{\text{sec}}$ 是安全消费速度，在 AI Coding 时代这个差值只会单调递增。这不是谁不努力，是量级不匹配——你把全公司安全工程师都派上去，也追不上一个 AI 化研发团队的产出速度。

而 AI 本身是天然能跟上这个速度的：它读代码不比写代码慢，它调工具不比你点鼠标慢，它还能不睡觉地循环。问题只在于——没有人把"安全测试工程师的工作方式"翻译成 AI 能稳定执行的工程协议。这正是 HOS-Sec-Engine 要干的事。

1.2 传统安全工具的三个"看不到"

我也不是没试过把传统工具堆上去。Semgrep、CodeQL、Trivy、SonarQube 都试过，结论是：工具没错，错在把它们当成"安全测试本身"。它们有三大结构性盲区：

第一，只能扫描，不能"攻击"。 SAST/DAST 的本质是"按规则找特征"，它不会做攻击路径规划——这个参数能注入、能不能横向打到内网、能不能拿到 RCE，扫描器不关心，也没有能力关心。而渗透测试的核心恰恰是"路径"。

第二，只能发现规则，缺上下文。 一个正则/规则引擎看到 eval(user_input) 就报警，但它不知道这个输入到底是不是用户可控的、前面有没有过滤、后面有没有 sink 可达性。于是报告里满是"疑似"，真实风险淹没在噪音里。安全行业有个老梗：扫描器报告 = 高噪声信息流。真正干活的人要花 80% 时间做误报筛选。

第三，缺攻击路径理解，也缺"二次判断"。 即使工具发现了某条线索，由谁来判断"这条线索值不值得深入、走哪条分支、用什么 payload"？传统工具做不到动态决策——流程是死的，而真实攻击是活的。

一句话总结：工具发现了"症状"，但没人做"诊断"和"手术方案"。而这个"诊断者"，恰好是大模型最擅长当的角色——前提是给它配上能执行动作的工具链和能约束方向的流程框架。

1.3 真正缺的是 Security Skill，而不是又一个 Scanner

所以问题的答案不是"再做一个扫描器"。扫描器已经过剩了，市场上不缺规则引擎，缺的是把"方法论"从人脑里抽出来、变成机器可执行、可复用、可验证的东西——这就是 Skill。

注意我的用词。Skill 不是一个 Prompt，Prompt 是一次性的话术；Skill 是一套标准化的能力封装：它定义了这个 Agent 会什么、按什么流程做、遇到分支怎么决策、调哪些工具、输出什么格式的报告。它像给 AI 装了一个"职业技能包"。

在 GitHub 仓库 lxcxjxhx/HOS_SKILL_WORKFLOW 里，这样的 Skill 已经有一整个矩阵（W-00 到 W-03、S-00 到 S-12、X-00），覆盖安全测试、成本优化、质量控制、论文红队等场景。前缀约定很清楚：W- 是老版 Workflow（YAML/JSON 模板），S- 是标准多文件 Skill（SKILL.md + src/ + templates/ 子目录结构）。而 S-00 就是本文主角 HOS-Sec-Engine——安全测试这个场景的标准多文件 Skill 实现。

本节核心收获：AI Coding 让代码生产提速、安全消费原地踏步，缺口不可逆；传统工具的三大盲区是"只能扫描、缺上下文、无攻击路径理解"；解决方案不是第 N 个扫描器，而是可执行的 Security Skill。

二、什么是 HOS-Sec-Engine

2.1 一句话定位

HOS-Sec-Engine 在仓库 README 里的官方定位是：

方法论驱动的 AI 原生安全测试引擎 —— 流程模板 · 决策树驱动 · CVE 实时集成 · MCP 管理层。引导"怎么做"，而非告诉你"做什么"。

这句话值得拆三遍。

“引导怎么做，而非告诉你做什么"是灵魂。市面上的安全 AI 产品（包括很多"AI 加固版"的扫描器）思路是：AI 帮你把扫描结果翻译成人话。这是"告诉你做什么”——它把 AI 当翻译官。HOS-Sec-Engine 反过来：它把安全工程师的方法论（先信息收集、再找注入点、有 WAF 就绕、拿到权限就后渗透……）编码成一套引擎可驱动的流程，然后让 AI 在这个框架里自己决定每一步具体怎么做。AI 不是翻译官，是拿着作战手册的士兵。

模块元信息同样值得一看。SKILL.md 的 YAML 头（front matter）是这么声明的：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/SKILL.md】
name: HOS-Sec-Engine
version: 3.0.0
description: 方法论驱动的 AI 原生安全测试引擎
author: HOS Team
tags:
  - security
  - pentest
  - audit
  - mcp
  - cve
  - automation
compatibility:
  - claude-code
  - cursor
  - windsurf
  - github-copilot
  - trae-cn
license: MIT
metadata:
  category: security
  subCategory: penetration-testing
  risk-level: high
  confidence: 0.95

注意两个细节：version: 3.0.0——这不是 0.1 的玩具，已经迭代到 3.0.0；risk-level: high——仓库坦诚这个 Skill 是高风险能力（能打真实目标），使用者必须遵守授权边界。这一点我在文章最后还会再强调一遍。

2.2 与传统 SAST/DAST 的本质区别

用一张表把差异钉死：

维度	传统 SAST/DAST	HOS-Sec-Engine
能力内核	规则引擎/特征匹配	流程模板 + 决策树 + 工具编排
是否理解攻击路径	❌ 只看单点特征	✅ 按阶段推进并动态分支
面对 WAF/防护	无感知	✅ 有独立 WAF 绕过阶段与决策
漏洞情报时效	静态规则库/本地库	✅ 实时调 NVD + GitHub Advisory API
误报处理	人工筛	✅ AI 二次判断 + 三证据裁判
可扩展性	加规则/加签名	✅ 改 YAML 模板即改流程
失败容忍	整体失败常见	✅ 单阶段/单步骤失败默认继续
输出	漏洞列表	✅ 结构化报告（Markdown/HTML/JSON）

看到最后两行的差异没？传统工具是一个"探测器"，HOS-Sec-Engine 是一个"执行层"。它不自带多少条硬编码规则——README 里写得很直白：“无硬编码技能：所有测试逻辑由流程模板 + 决策树驱动”。规则和知识是 AI 模型的，流程和决策是引擎的，工具是 MCP 的，三者解耦。

2.3 为什么采用 Skill + 工具链架构

这个架构决策是被现实教育出来的。最初我（以及很多同行）的路线是"做一个大而全的安全扫描 CLI"，后来发现三个致命问题：

做不完：漏洞类型半年翻一番，规则永远追不上；
养不活：规则库要人维护，社区要运营，一个人/小团队根本扛不住；
插不进：单机 CLI 跟 Claude Code / Cursor 的 Agent 生态是两套世界，用户希望的是"让我的 AI 顺手就把安全做了"，而不是再开一个终端窗口。

于是架构改成三层解耦：

AI Agent（Claude Code / Cursor / Codex…）
   │  感知 + 决策 + 语言
   ▼
HOS-Sec-Engine（Skill 执行层：流程/决策/工具路由）
   │  编排 + 规则化 + 记忆
   ▼
MCP 工具链（playwright / http-fetch / code-executor…）
   │  动手干活
   ▼
目标系统（被测 Web / API / 云配置 / 源码）

引擎只做"编排和判断"，具体脏活累活交给 MCP 工具。这样引擎本体轻、能随模型演进、也能随时接入新的 MCP 工具——这个"工具生态红利"是单机 CLI 永远吃不到的。这也是为什么它叫 “Engine” 而不是 “Tool”：引擎是给 Agent 装上的执行内核，不是给用户点开的按钮。

本节核心收获：HOS-Sec-Engine 的定位是"方法论驱动的 AI 原生安全测试执行层"；与传统工具比，它理解攻击路径、支持动态决策、实时情报、可扩展、失败容忍；架构上采用 Skill + 工具链三层解耦，让引擎轻、生态活、能随 AI Agent 一起演进。

三、HOS-Sec-Engine 整体架构

3.1 架构总览

先看一张图，把整条链路立起来。这张图就是仓库 src/core/ + src/mcp/ + src/playbooks/ 的真实模块关系的映射：

如果你把这张图跟仓库 README 里的"能力全景"表格对照，会发现一一对应：流程引擎、决策树引擎、阶段执行器、CVE 实时集成、工具注册中心、报告生成器、循环保护——七个核心能力，图上七条线，没有任何一个是摆设。

3.2 核心模块拆解

再看一张模块地图，这是仓库真实的目录结构（README「项目架构」一节的原样）：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/README.md 项目架构】
S-00-HOS-Sec-Engine/
├── src/
│   ├── core/                       # 引擎核心
│   │   ├── engine.ts               # 主引擎入口（HosSecEngine）
│   │   ├── process-engine.ts       # Process Engine 流程引擎
│   │   ├── phase-executor.ts       # 阶段执行器
│   │   ├── decision-tree.ts        # 决策树引擎
│   │   ├── cve-integration.ts      # CVE 实时集成
│   │   ├── tool-registry.ts        # 工具注册中心
│   │   ├── orchestrator.ts         # 流程编排器
│   │   ├── report.ts               # 报告生成器
│   │   ├── formatter.ts            # 格式化工具
│   │   ├── judge.ts                # LLM-as-a-Judge 三证据裁判
│   │   ├── poc-validator.ts        # PoC 三状态 Oracle 验证
│   │   └── waf-bypass.ts           # WAF 绕过策略
│   ├── mcp/                        # MCP 管理层
│   │   ├── registry.ts             # MCP 注册中心
│   │   ├── discovery.ts            # MCP 自动发现
│   │   ├── router.ts               # MCP 工具路由
│   │   └── health.ts               # MCP 健康监控
│   ├── playbooks/                  # 流程模板
│   │   ├── process-templates/      #   YAML 模板（web-pentest / api-security-audit / cloud-config-audit）
│   │   ├── web/ api/ cloud/ intranet/ audit/
│   │   └── index.ts
│   ├── agents/                     # Agent 系统（coordinator / ensemble / sub-agent）
│   └── examples/process-guidance.ts
├── config/mcp-servers.json         # MCP 服务器配置
└── tests/                          # core / integration / loop 三套测试

每个模块的职责，用表格说清楚（这部分直接对应仓库 README 的组件表）：

组件	文件	职责
Process Engine	`src/core/process-engine.ts`	解析 YAML 模板、驱动阶段执行、调用决策树、CVE 富化
决策树引擎	`src/core/decision-tree.ts`	根据阶段结果动态决定下一阶段分支
阶段执行器	`src/core/phase-executor.ts`	按步骤执行、解析模板变量 `{{target}}`、提取 findings
CVE 集成	`src/core/cve-integration.ts`	实时查询 NVD/GitHub Advisory，富化 finding 并提级
工具注册中心	`src/core/tool-registry.ts`	统一注册/路由工具调用
MCPRegistry	`src/mcp/registry.ts`	MCP 服务器生命周期管理
MCPDiscovery	`src/mcp/discovery.ts`	自动扫描已安装的 MCP 包
MCPRouter	`src/mcp/router.ts`	多种策略工具路由（best_match / round_robin / parallel_first / specific）
MCPHealthMonitor	`src/mcp/health.ts`	定时健康检查 + 自动恢复
LLMJudge	`src/core/judge.ts`	三证据裁判，消除误报
报告生成器	`src/core/report.ts`	输出 Markdown / HTML / JSON 结构化报告

3.3 引擎执行的一条主线

引擎一次完整执行的主线，用 sequenceDiagram 画出来（对齐 process-engine.ts 的真实执行流程）：

这条主线上有几个被 README 特别标注的工程细节，都是实战中逼出来的：

失败容忍：continueOnPhaseFailure 和 continueOnStepFailure 默认都是 true。单步失败不影响整体——渗透测试里一个 payload 失败太正常了，不能让一个阶段挂掉整个流程。
循环保护：MAX_PHASE_ITERATIONS = 200，防止决策树在 A/B 阶段间死循环烧 token。还有 MAX_FINDINGS、MAX_RECOMMENDATIONS、MAX_SCAN_DEPTH、GLOBAL_MAX_RECOVERY_LIFETIME 一整套阈值，全部可配置、不用改代码。
懒加载：initMCP() 不是构造时初始化，而是首次需要时才启动 MCP 服务器——README 里写得很直白：“避免自动启动 MCP 服务器导致测试死循环”。

本节核心收获：架构 = 流程引擎（骨架）+ 决策树（大脑）+ 工具注册/路由（手脚）+ CVE 集成（情报）+ 报告器（出口），外加循环保护与失败容忍两套"安全气囊"；这些模块在仓库 src/ 下全部真实存在且可运行。

四、为什么不是简单 Prompt

这是我最常被问到的问题："这不就是把一段 prompt 写长点吗？"不是。Skill 与 Prompt 是两种不同量级的东西。

在展开对比之前，先把几个高频词的定义钉死，免得后面鸡同鸭讲：

Skill

标准化的能力封装—— SKILL.md 声明 + src/ 源码 + templates/ 模板 + tests/ 测试，定义了 Agent 会什么、按什么流程做、调哪些工具、输出什么格式。一句话：它是 AI 的"职业技能包"。

Workflow

一套可执行的阶段序列。在 HOS-Sec-Engine 里即 YAML 流程模板（如 web-pentest.yaml），每个阶段带目标、思路指导与成功标准。

Decision Tree

根据阶段执行结果动态决定下一阶段的规则集，让流程"活"起来，而不是死顺序。

Tool Calling

Agent 调用外部工具的机制；引擎里由 ToolRegistry 统一注册、MCPRouter 统一路由。

MCP

模型上下文协议（Model Context Protocol），把浏览器、HTTP、代码沙箱等外部能力封装成 AI 可调用的标准化工具。

安全上下文

流程执行的状态容器（ProcessContext），记录目标、已完成阶段、findings 等，保证执行可复现、可审计。

4.1 Skill vs Prompt：一张表看懂

维度	一段 Prompt	HOS-Sec-Engine Skill
形态	一次性文本	标准多文件工程（SKILL.md + src/ + templates/ + tests/）
确定性	随模型心情	流程模板 + 决策树约束，可预期
工具调用	看模型会不会	工具注册中心 + MCP 路由，强编排
可验证	无法自动化验证	三套测试（core / integration / loop）自动跑
可复用	复制粘贴即失效	模块化，开箱即用
可扩展	改 prompt 靠玄学	加 YAML 模板 / 加 MCP 工具即可
失败处理	聊崩了重来	失败容忍 + 循环保护 + 自动恢复

仓库里有个细节能证明"工程化"不是嘴上说说：tests/verification-report.json 记录了全套验证结果——构建通过、运行时测试 17/17 通过、MCP 管理层测试 81/81 通过、overall: true。这已经不是"一段提示词"的层次，这是一套带 CI 级别的测试保障的软件。

4.2 Workflow：YAML 流程模板 = 方法论的外置硬盘

引擎的方法论不是埋在代码里，而是外置成 YAML，放在 src/playbooks/process-templates/ 下。当前内置三套：

Web 渗透测试     ──  src/playbooks/process-templates/web-pentest.yaml
API 安全审计     ──  src/playbooks/process-templates/api-security-audit.yaml
云配置审计       ──  src/playbooks/process-templates/cloud-config-audit.yaml

以 Web 渗透测试模板为例（web-pentest.yaml，version 3.0.0），它把一次完整渗透测试拆成 8 个阶段：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/playbooks/process-templates/web-pentest.yaml】
id: web-pentest
name: Web 渗透测试方法论
description: |
  指导 AI 如何进行 Web 渗透测试的方法论框架。
  从信息收集到后渗透的完整渗透测试生命周期，采用自适应决策树驱动。
category: web
version: 3.0.0
phases:
  - id: reconnaissance          # 信息收集与攻击面分析
  - id: waf-bypass              # WAF 绕过策略分析
  - id: sqli-detection          # SQL 注入漏洞深度检测
  - id: xss-detection           # XSS 跨站脚本深度检测
  - id: ssrf-path-detection     # SSRF 与路径遍历检测
  - id: upload-rce-detection    # 文件上传与命令注入检测
  - id: exploitation            # 漏洞利用与深入利用
  - id: post-exploitation       # 后渗透与数据收集

每个阶段不止有名字，还有方法论指导（description）、业务目标（objectives）、AI 行动指南（approach）、成功标准（successCriteria）、超时与重试。这是整套设计里最"反直觉"的一笔：模板不写死步骤，模板写的是思路。 比如"SQL 注入漏洞深度检测"阶段，模板不是告诉你"第 1 步发 ' or 1=1 --，第 2 步看回显"，而是告诉你"识别注入点→判断注入类型→根据数据库类型调整→被 WAF 拦了就换编码绕过→根据回显动态调整方向"。具体 payload 是 AI 自己生成的，方向是模板给的。

为什么这样设计？因为固定的扫描步骤在真实世界里 80% 时间失效——目标千奇百怪，固定 payload 序列就是给 WAF 送人头。方法论 + 模型智能，才是活的测试。

模板里每个阶段的 condition 字段实现了"条件阶段"。比如 waf-bypass 阶段带条件"信息收集阶段检测到 WAF 防护"，exploitation 阶段带条件"前面阶段发现了可利用的漏洞"——条件不满足，ProcessEngine 的 evaluatePhaseCondition() 会直接跳过并标记 skipped。引擎里这个函数支持的内置条件在源码里写得很清楚：

// 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/core/process-engine.ts】
private evaluatePhaseCondition(condition: string, context: ProcessContext, phaseResults: PhaseResult[]): boolean {
    switch (condition) {
      case 'vulnerabilitiesFound':
        return context.findings.length > 0;
      case 'accessGained':
        return phaseResults.some(r =>
          r.findings.some(f => f.type === 'rce' || f.type === 'auth-bypass')
        );
      case 'highPrivilege':
        return phaseResults.some(r => r.status === 'success');
      case 'ssrfAccessible':
        return context.findings.some(f => f.type === 'ssrf');
      case 'wafDetected':
        return context.findings.some(f => f.type === 'waf-detected');
      default:
        return true;
    }
  }

4.3 Decision Tree：让流程"活"起来

固定流程的渗透测试毫无意义，所以引擎配了决策树。decision-tree.ts 里每个决策节点由 sourcePhase（源阶段）+ 一组 conditions（条件）+ defaultNext（默认下一步）构成，evaluate() 按序评估条件、命中即返回下一阶段。Web 模板的决策树长这样（节选）：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/playbooks/process-templates/web-pentest.yaml】
decisionTree:
  - id: decide-after-recon
    sourcePhase: reconnaissance
    conditions:
      - rule: "检测到 WAF 防护"
        nextPhase: waf-bypass
        description: "检测到 WAF，先进入 WAF 绕过策略分析"
      - rule: "未发现明显防护"
        nextPhase: sqli-detection
        description: "无明显防护，直接进入漏洞检测"
    defaultNext: sqli-detection

注意这里的分支是"有 WAF 先绕 WAF，没 WAF 直接打"。决策树引擎（decision-tree.ts）内部用一套可读的"伪规则"判断条件——源码里提供了 result.hasFindings()、result.hasCriticalVulnerability()、result.hasAccess()、result.hasS3Bucket()、result.hasWaf()、result.isCloudflare()、result.hasWafBypassTool() 等一整套语义化判定：

// 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/core/decision-tree.ts】
if (rule.includes('result.hasCriticalVulnerability()')) {
  const matched = result.findings.some(f => f.severity === 'critical' || f.severity === 'high');
  return { condition, matched,
    reason: matched ? '发现高危漏洞' : '未发现高危漏洞' };
}
if (rule.includes('result.hasAccess()')) {
  const matched = result.status === 'success' && result.findings.some(f =>
    f.type === 'rce' || f.type === 'command-injection' || f.type === 'auth-bypass'
  );
  return { condition, matched, reason: matched ? '已获取访问权限' : '未获取访问权限' };
}

这套伪规则是给 AI 看的"决策语言"——process-guidance.ts 的演示输出里直接给出了决策树的通俗解释：

如果发现高危漏洞 → 进入深入利用阶段；如果未发现漏洞 → 切换测试方向；如果获取访问权限 → 进入后渗透阶段。例如 Web 渗透测试决策树：信息收集 → SQL注入检测 → XSS检测 → SSRF/路径遍历 → 文件上传/命令注入 → 漏洞利用 → 后渗透。

4.4 Tool Calling + MCP：AI 的手和脚

Prompt 里你只能"建议 AI 用工具"；HOS-Sec-Engine 里工具是一等公民。所有可调用工具注册在 tool-registry.ts 的全局单例里，引擎内置了三个基础工具（web_fetch / search_google / cve_query），而真正的大杀器是 MCP 管理层。

config/mcp-servers.json（version 2.0.0）预置了 7 个 MCP 服务器，每个都有明确的攻防用途：

MCP 服务器	命令	在安全测试里干什么
`playwright`	`@anthropic/mcp-playwright`	浏览器自动化：攻击验证、XSS/注入验证、登录态测试
`http-fetch`	`@anthropic/mcp-fetch`	HTTP 请求：payload 注入、API fuzz、WAF 绕过测试
`sequential-thinking`	`@anthropic/mcp-sequential-thinking`	多步推理：攻击链规划、bypass 策略分析
`memory`	`@anthropic/mcp-memory`	持久记忆：WAF 指纹学习、payload 成功率记录
`filesystem`	`@anthropic/mcp-filesystem`	文件系统：payload 存储、日志分析、结果持久化
`github`	`@anthropic/mcp-github`	GitHub 集成：exploit 同步、CVE 跟踪
`code-executor`	`@anthropic/mcp-code-executor`	代码沙箱：JS/Python payload 验证、exploit 原型

MCP 管理层自己也是"自我管理"的：MCPRegistry 管生命周期（注册/启动/停止/注销）、MCPDiscovery 自动扫描已装的 MCP 包（checkNpmGlobal / checkNodeModules）、MCPHealthMonitor 定时全量/增量检查 + 自动恢复（maxRecoveryAttempts: 3）。整套机制对应 README 的初始化链路：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/README.md MCP 管理层】
initMCP()  [首次使用时懒加载]
  ├─ loadMCPServersFromConfig()    ← config/mcp-servers.json
  ├─ mcpDiscovery.discoverAll()    ← 自动扫描已安装的 MCP 包
  ├─ mcpRegistry.registerServer()  ← 注册中心管理生命周期
  ├─ mcpHealthMonitor.start()      ← 健康监控 + 自动恢复
  └─ buildToolMappings()           ← 工具映射到流程步骤

4.5 安全上下文 + 可重复执行

Prompt 的另一个致命伤是没有状态。聊完一次就归零。而引擎维护完整的 ProcessContext（目标、当前阶段、已完成阶段、findings、自定义 state），每次执行都从模板 + 上下文确定性重建流程——同一套 Skill，今天跑、下个月跑、换台机器跑，结果是可复现的。README 里那一排测试命令不是装饰：

npm run build                  # 完整构建流程
npm run test                   # 核心引擎测试
npm run test:integration       # 全量集成验证
npm run test:loop              # 循环保护测试
npm run dev                    # 监听模式编译

本节核心收获：Skill ≠ Prompt——它有标准文件结构、有可验证的测试、有外置 YAML 方法论、有决策树动态分支、有 MCP 工具编排、有上下文与可重复执行；"模板给方向、AI 给手段、工具给手脚"这套三元设计是它的本质。

五、实际案例：给 AI 一个存在漏洞的项目

空谈架构没意思，来走一遍真实流程。仓库自带的演示入口是 src/examples/process-guidance.ts（对应 npm start / npm run start，package.json 里 start: node dist/src/examples/process-guidance.js）。我们完整跑一遍，看看这个 Skill 到底怎么"干活的"。

5.1 案例背景与启动

假设我们拿到一个测试授权目标 https://example.com（演示用，安全测试请务必在授权范围内），决定走 web-pentest 流程。按 README「一分钟开始」：

git clone https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW.git
cd S-00-HOS-Sec-Engine
npm install
npm run build
node dist/src/examples/process-guidance.js

引擎启动后，第一步是加载流程模板。真实日志（来自 tests/verification-report.json）是这样的：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/tests/verification-report.json（运行时日志节选）】
[ProcessEngine] 内置工具已注册
[ProcessEngine] 加载模板: api-security-audit (...)
[ProcessEngine] 加载模板: cloud-config-audit (...)
[ProcessEngine] 加载模板: web-pentest (...)
[ProcessEngine] 已加载 3 个流程模板

5.2 执行过程：引擎眼中的完整生命周期

process-guidance.ts 的主流程分 6 步：初始化引擎 → 展示可用模板 → 展示决策树逻辑 → 执行流程 → 输出结果 → 生成报告。其中执行阶段的日志是理解"方法论驱动"的最佳切片：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/examples/process-guidance.ts 执行输出结构】
======================================================================
[ProcessEngine] 🔴 阶段 [1/8]: 信息收集与攻击面分析
[ProcessEngine] 📋 业务目标: 方法论指导：
1. 首先理解目标的业务逻辑和技术架构
2. 识别所有可能的入口点（URL 参数、HTTP 头、Cookie、API 端点）
3. 分析目标的防护机制（WAF、认证、速率限制、CSP）
...
[ProcessEngine] ✅ 成功标准:
   • 已识别主要技术栈组件
   • 已发现至少 3 个可攻击的输入点
   • 已了解防护机制和可能的绕过方向
   • 已记录安全相关的响应头信息

每个阶段，引擎都会把业务目标和成功标准打在台面上——这不是日志冗余，而是"安全工程模式"的关键：AI 的每一步动作都要对着目标推进，而不是自由发挥。阶段结束后，决策树接过指挥棒：

信息收集发现 WAF → 决策树分支到 waf-bypass（“检测到 WAF，先进入 WAF 绕过策略分析”）；
没检测到 → 直接进 sqli-detection；
每个检测阶段结束，按决策规则串联到下一阶段，直到 exploitation（漏洞利用）与 post-exploitation（后渗透）。

这个"信息收集 → SQL 注入 → XSS → SSRF/路径遍历 → 文件上传/命令注入 → 利用 → 后渗透"的执行路径，在 process-guidance.ts 里被刻意打印成决策树路径，每一步都有据可查。

5.3 结果与报告：三件套输出

流程跑完，引擎汇总统计（ProcessResult.summary 字段来自 types/process.ts）：

// 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/types/process.ts】
export interface ProcessResult {
  templateId: string;
  context: ProcessContext;
  phaseResults: PhaseResult[];
  status: 'running' | 'completed' | 'failed' | 'stopped';
  summary: {
    totalFindings: number;
    criticalCount: number;
    highCount: number;
    mediumCount: number;
    lowCount: number;
    cveReferences: number;
    duration: number;
  };
}

报告生成器（src/core/report.ts）基于 ProcessResult 输出三件套：Markdown 报告（可直接贴进 PR 或工单）、HTML 报告（给非技术 stakeholders 看）、JSON（给 CI/CD 消费）。每条 finding 带严重级别、漏洞类型、描述、证据、以及 CVE 匹配。process-guidance.ts 里这样打印发现的等级与关联 CVE：

• [high] sqli - SQL 注入参数 id（...）
  关联 CVE: CVE-2024-xxxx (HIGH)

5.4 踩坑实录：第一次跑就翻车的三个教训

这部分是我自己调这套 Skill 的真实经历，写出来帮大家少踩坑。

坑一：让它扫"没授权的目标"。 早期演示时我随手把某个线上站点填进 HOS_SEC_TARGET，结果 WAF 直接把我们的测试流量封了。教训：风险分级是真实的——SKILL.md 自己都标了 risk-level: high。所有测试目标必须写成配置项，且必须授权。.env.example 里已经给了范式：

# 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/config/.env.example】
# Target for Skill execution
HOS_SEC_TARGET=https://example.com

坑二：MCP 服务器全家桶一起启动，机器直接卡死。 7 个 MCP 服务器全量 autoStart 是很重的，尤其 playwright 会拉起浏览器内核。后来引擎改成了 initMCP() 懒加载 + mcpHealthMonitor 健康检查（quickCheckIntervalMs: 15000，15 秒快速检查），需要时才拉起，配合 maxRestarts 做崩溃自愈——这个改动直接解决了测试环境的稳定性问题。

坑三：payload 被 WAF 拦了还继续硬刚。 早期的流程没有 WAF 感知，一个注入 payload 被拦 10 次，白白烧 token。后来在模板里加了 waf-bypass 阶段 + 决策树规则，并且让 web_fetch 工具默认带上完整浏览器指纹头（tool-registry.ts 里的 User-Agent / Sec-Fetch-* 头序列），从源头降低被 WAF 拦的概率。这一段是踩出来的，不是设计出来的。

本节核心收获：一个真实流程 = 启动加载模板 → 按阶段推进并打印业务目标/成功标准 → 决策树动态分支 → CVE 富化 → 三件套报告输出；三个常见坑（授权、MCP 重载、WAF 硬刚）分别对应配置化目标、懒加载+健康监控、WAF 感知三个工程改进。

六、最关键的设计：让 AI 学会"什么时候调用什么工具"

如果说前面是"骨架和器官"，这一节是整套 Skill 的神经系统。工具人人会接，难的是让 AI 在正确的时间、用正确的工具、做正确的事。这一节我们直击 src/mcp/router.ts 和 src/core/ 里的真实实现。开门见山：工具的选用，本身就是方法论的一部分——把"什么时候用什么"沉淀成规则，正是这套 Skill 区别于普通 Prompt 的分水岭。

6.1 工具选择的三个层次

我把它拆成三层，越往下越接近"肌肉记忆"：

第一层：内置工具兜底。 tool-registry.ts 注册的 web_fetch 是"任何场景都能用"的万能手，它还内置了一整套浏览器指纹头，专门用来降低被基础 WAF 拦截的概率。cve_query 则把 CVE 查询的实活委托给 CVEIntegrator。

第二层：Skill-MCP 映射，这是真正的"什么时候用什么"。 router.ts 里维护了一张 DEFAULT_SKILL_MCP_MAPPINGS 表，把每个攻击场景（skillId）映射到必备 MCP 服务器和推荐 MCP 服务器，并且连"动作 → 服务器 → 工具 → 入参模板"都写死了。看两个例子：

// 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/mcp/router.ts】
{
  skillId: 'web-sqli-001',
  requiredMCPServers: ['http-fetch'],
  recommendedMCPServers: ['playwright', 'memory'],
  toolMappings: [
    { action: '发送 SQL 注入 payload', server: 'http-fetch', tool: 'http_post',
      inputTemplate: { url: '{target}', body: '{payload}' } },
    { action: '测试 SQL 盲注', server: 'http-fetch', tool: 'http_get',
      inputTemplate: { url: '{target}', params: '{params}' } },
    { action: 'WAF 绕过验证', server: 'playwright', tool: 'browser_navigate',
      inputTemplate: { url: '{target}' } },
  ],
},
{
  skillId: 'web-waf-bypass-0day',
  requiredMCPServers: ['http-fetch', 'sequential-thinking'],
  recommendedMCPServers: ['playwright', 'memory'],
  toolMappings: [
    { action: '分析 WAF 特征', server: 'sequential-thinking', tool: 'think',
      inputTemplate: { thought: '{analysis}' } },
    { action: '发送绕过 payload', server: 'http-fetch', tool: 'http_post',
      inputTemplate: { url: '{target}', body: '{payload}' } },
    { action: '记录绕过模式', server: 'memory', tool: 'remember',
      inputTemplate: { key: '{pattern_key}', value: '{pattern_value}' } },
  ],
},

这张表本身就是"攻防经验的结构化"：SQL 注入用 http-fetch、XSS 验证上 playwright 截图、WAF 绕过先 sequential-thinking 想策略再用 http-fetch 打、打下来的模式用 memory 记住。AI 不用"猜"该用什么工具——查表即可，而且这张表可以随经验持续追加。

6.2 决策规则引擎：AI 的"判断层"

工具选对了，还得知道"下一步干嘛"，这是决策树的活。除了前面讲的 result.hasWaf() 这类规则，decision-tree.ts 还支持条件阶段短路——模板里某个阶段的 condition 不满足（比如 accessGained 要求已获得权限，而前面没打下来），process-engine.ts 会跳过该阶段并记录 skipped 状态。这条链路保证：AI 永远不把时间花在"现在不该做的事"上。

6.3 CVE 实时集成：把"情报"接到工具链上

工具负责打，情报负责"打完怎么定性"。cve-integration.ts 通过两个公开 API 实时拉 CVE，不依赖本地漏洞库：

// 【来源：HOS_SKILL_WORKFLOW/S-00-HOS-Sec-Engine/src/core/cve-integration.ts】
// NVD API 2.0 端点
const url = `https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=${encodeURIComponent(query)}&resultsPerPage=${limit}`;
// GitHub Advisory API 端点
const url = `https://api.github.com/advisories?keyword=${encodeURIComponent(query)}&per_page=${limit}`;

更有意思的是它的关键词提取策略——extractKeywords() 里维护了一张漏洞类型 → 查询关键词的映射表，加上一份技术栈关键词表（apache / nginx / tomcat / spring / struts / log4j / mysql / thinkphp / cloudflare / modsecurity...）。一条发现（finding）命中类型或技术栈关键词，就自动去拉关联 CVE，再按 CVE 严重程度上调 finding 的等级（CRITICAL 的 CVE 会把 finding 提到 critical）。这就是"实时情报富化"：扫描器给的是冷数据，引擎给的是热情报。

6.4 路由策略：最后一百米的可靠性

工具调用是高频动作，路由要可靠。router.ts 提供四种策略：

策略	行为	适用
`best_match`	选延迟最低的服务器	默认，快
`round_robin`	轮询分发	多节点负载均衡
`parallel_first`	并行执行取首个成功（上限 5 台）	冗余高可用
`specific`	指定服务器执行	明确目标

配合 MCPHealthMonitor（全量检查 60s / 快速检查 15s / 自动恢复），工具链本身就是"自我治愈"的。

本节核心收获：AI 学会"什么时候调用什么工具"靠的不是玄学，是三层机制——内置工具兜底、Skill-MCP 映射表给方向、路由策略保可靠性；决策树管"下一步做什么"，CVE 集成管"发现怎么定性"，一张映射表把攻防经验变成了可扩展的结构化资产。

七、适合哪些人

老实说，这套 Skill 不是给所有人的，但它非常适合下面六类人：

AI Coding 重度用户（Claude Code / Cursor / Codex / Gemini CLI 玩家）：你每天让 AI 写大量代码，最该让它顺手做安全回归的人就是你。仓库总 README 明确列出兼容平台：Claude Code ✅、OpenAI Codex ✅、Cursor ✅、Gemini CLI ✅、VSCode AI IDE ✅、Trae ✅。
安全研究员 / 渗透测试从业者：把重复的侦察、枚举、CVE 关联交给引擎，把精力留给人脑才擅长的"创造性利用"。
DevSecOps / 平台工程：npm run test:integration、JSON 报告、失败容忍、循环保护——这些都是能直接接进 CI 流水线的工程特性。
CTF 选手：决策树 + 工具编排的思维方式，本身就是最好的渗透思路训练；api-security-audit.yaml 覆盖 JWT / OAuth / IDOR / GraphQL，全是 CTF 和实战高频考点。
安全开发 / 工具链作者：想给 Agent 生态做安全工具的人，仓库的"模板外置 + 决策树驱动 + MCP 路由"架构是现成的参考蓝本。
企业安全团队：需要统一、可审计、可复用的安全测试流程资产，而不是散落在个人 prompt 里的"祖传手艺"。

一个提醒：能力越大，边界越要清楚

SKILL.md 自己标注 risk-level: high、subCategory: penetration-testing。这套 Skill 能打真实目标，所以只允许在授权范围内使用。 仓库的 License 也要注意：模块 README 声明 MIT，仓库总 README 声明 AGPLv3（强互惠，SaaS 化需开源服务端源码），商用前务必跟维护者确认合规口径¹。

本节核心收获：六类人最受益（AI Coding 玩家 / 安全研究员 / DevSecOps / CTF / 安全开发 / 企业安全团队）；高风险能力必须遵守授权边界，许可合规要提前确认。

八、总结

回到开头那个让我脊背发凉的场景："帮我看下这段代码有没有安全问题。"现在我的回答变了：

不要问 AI"有没有问题"，给它一个能按方法论执行的 Skill，让它在流程里自己找答案。

顺带说一个我自己的观察：安全圈常讲"最普通的输入点往往最致命"——就像 H₂O 这种最不起眼的分子恰恰是生命的基石，一个看起来人畜无害的文件上传接口，可能就是一个 getshell 的起点。引擎要做的，就是让 AI 不放过任何一个"普通"的输入点。

HOS-Sec-Engine 用四件套回答了"AI 原生安全测试"这个命题：

流程模板（YAML） 把渗透方法论外置成可编辑资产，模板给方向、AI 给手段；
决策树 让流程动态化——发现 WAF 先绕、拿到权限就后渗透，流程跟着结果走；
CVE 实时集成 把静态库换成 NVD / GitHub Advisory 实时情报，发现即富化、可提级；
MCP 管理层 让 AI 真正"动手"——注册、发现、路由、健康监控四件套，工具链自我治愈。

加上三证据裁判（judge.ts，对应 SEC-bench Pro 的三证据模型，防止"crash 匹配虚增 43.6%“式的误报）、循环保护、失败容忍，这套 Skill 已经从"能用"走到了"工程可用”——别忘了，它的测试报告是 17/17 + 81/81 全绿。

学完本文，你能做什么？

按这份行动清单动手（建议逐项勾选）：

1. 有 Claude Code / Cursor 的话：git clone https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW.git → cd S-00-HOS-Sec-Engine → npm install && npm run build → node dist/src/examples/process-guidance.js，亲眼看看"安全工程模式"长什么样；
2. 打开 src/playbooks/process-templates/web-pentest.yaml，对照本文架构图，把 8 个阶段和决策树读一遍，理解"方法论外置"；
3. 在授权目标上跑一次 api-security-audit 流程，观察决策树如何动态分支；
4. 编辑 config/mcp-servers.json，给 web-waf-bypass-0day 这类 skillId 配上你自己的工具链；
5. 跑 npm run test 和 npm run test:integration，看引擎如何自证正确性；
6. 把跑出来的真实案例整理成 issue/PR——你的实战经验就是下一版决策树里的一条新规则。

最后留两句可以单独传播的话：

扫描器回答"这行代码像不像有问题"，Security Skill 回答"这个系统现在能不能被打穿、怎么修、修完怎么验"。

这不是一个"AI 帮你写安全报告"的 Prompt，而是一套让 AI Agent 真正进入安全工程流程的 Skill。

项目在 GitHub 持续迭代（仓库 lxcxjxhx/HOS_SKILL_WORKFLOW，主分支 main，S-00-HOS-Sec-Engine 是它的标准安全模块）。如果你也觉得"AI Coding 时代该有人把安全测试做成 AI 的职业技能包"，去仓库点个 star、提个 issue 或 PR，你的实战经验就是下一版决策树里的一条新规则。安全是社区问题，一个人守护不了所有代码。

本文核心观点回顾

问题：AI Coding 让代码生产提速、安全消费原地踏步，传统工具只有"扫描能力"没有"攻击路径理解"，缺口不可逆。
答案：需要的是可执行的 Security Skill，而不是又一个 Scanner；HOS-Sec-Engine 就是这个 Skill（v3.0.0，TypeScript）。
架构：流程引擎 + 决策树 + 工具注册/路由 + CVE 集成 + 报告器 + 循环保护/失败容忍（全部对应 src/ 真实模块）。
方法论：YAML 模板给方向、AI 给手段、MCP 给手脚，模板不写死步骤、只写"怎么做"的思路。
决策：web-pentest.yaml 8 阶段 + 决策树动态分支；condition 条件阶段短路；result.hasWaf() 等语义化规则。
情报：NVD API 2.0 + GitHub Advisory 实时查询，类型/技术栈关键词提取，CVE 严重程度驱动 finding 提级。
工具编排：DEFAULT_SKILL_MCP_MAPPINGS（web-sqli-001 → http-fetch 等）决定"什么时候用什么"，四种路由策略保证可靠性。
可信度：tests/verification-report.json 记录 build ✅、runtime 17/17 ✅、MCP 81/81 ✅。

关键技术点与来源对照：

技术点	来源文件
引擎入口 / MCP 自我管理	`src/core/engine.ts`
流程引擎（阶段驱动 + 决策 + 富化）	`src/core/process-engine.ts`
决策树规则引擎	`src/core/decision-tree.ts`
工具注册中心 / 内置工具	`src/core/tool-registry.ts`
CVE 实时集成（NVD/GitHub）	`src/core/cve-integration.ts`
三证据 AI 裁判	`src/core/judge.ts`
Skill-MCP 映射 / 路由策略	`src/mcp/router.ts`
流程模板（8 阶段 + 决策树）	`src/playbooks/process-templates/web-pentest.yaml`
模块定位 / 能力全景	`README.md`、`SKILL.md`
验证报告（17/17、81/81）	`tests/verification-report.json`

参考链接：

主要来源（GitHub 仓库）：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW
模块 README：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/blob/main/S-00-HOS-Sec-Engine/README.md
模块 SKILL.md：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/blob/main/S-00-HOS-Sec-Engine/SKILL.md
Web 渗透测试流程模板：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/blob/main/S-00-HOS-Sec-Engine/src/playbooks/process-templates/web-pentest.yaml
MCP 服务器配置：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/blob/main/S-00-HOS-Sec-Engine/config/mcp-servers.json
验证报告：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/blob/main/S-00-HOS-Sec-Engine/tests/verification-report.json
辅助：NVD API 2.0：https://services.nvd.nist.gov/rest/json/cves/2.0；GitHub Advisory API：https://api.github.com/advisories；Model Context Protocol：https://modelcontextprotocol.io

附录（Appendix）：

A. 环境要求（来自 package.json）：Node.js >= 18.0.0；TypeScript ^5.3.0；核心依赖 js-yaml ^5.2.1、chalk ^4.1.2、@inquirer/prompts ^5.0.0；bin 入口 hos-sec-engine 与 hos-process。

B. 运行时环境变量（config/.env.example 节选）：

OPENAI_MODEL=gpt-4
OPENAI_MAX_TOKENS=4096
ANTHROPIC_MODEL=claude-3-opus-20240229
LOCAL_MODEL_BASE_URL=http://localhost:11434
LOCAL_MODEL_NAME=llama3
HOS_SEC_ACTIVE_PROVIDER=openai
HOS_SEC_MAX_CONCURRENT_AGENTS=3
HOS_SEC_SANDBOX_ENABLED=true
HOS_SEC_SANDBOX_NETWORK=restricted
HOS_SEC_TARGET=https://example.com

C. 失败容忍与循环保护阈值（README「循环安全保护」）：MAX_PHASE_ITERATIONS（防无限循环）、MAX_FINDINGS（防发现溢出）、MAX_RECOMMENDATIONS（防建议溢出）、MAX_SCAN_DEPTH（防目录递归溢出）、GLOBAL_MAX_RECOVERY_LIFETIME（MCP 全局恢复上限）；continueOnPhaseFailure 与 continueOnStepFailure 默认均为 true。

D. CVE 富化置信度说明（作者推导，供理解）：一条 finding 的严重级别提级遵循"取两者更严重"规则，即 $\text{finalSeverity} = \max(\text{findingSeverity}, \text{cveSeverity})$ ；当 CVE 级别为 CRITICAL 且 finding 非 critical 时，enrichFindingWithCVE 将 finding 提升为 critical。【需核实：仓库未给出数学公式，此式为代码行为的等价表述】

E. 学术引用（README「学术引用」）：SEC-bench Pro（Lee 等, arXiv:2605.26548）§3.5 三证据裁判、§4.2 RQ1 多 Agent 集成、§3.3 Oracle 验证、§4.3 Token 效率、§4.3.2 失败模式追踪分别对应 src/core/process-engine.ts、src/agents/ensemble.ts、src/core/phase-executor.ts、src/core/decision-tree.ts、src/core/report.ts。

F. 本文 Mermaid 说明：文中共 3 个 Mermaid 图（架构 flowchart、执行 sequenceDiagram、工具选择 flowchart），语法均按 Mermaid 标准编写，可直接在支持 Mermaid 的编辑器中渲染验证。

关键词： AI 原生安全测试, HOS-Sec-Engine, Claude Code, MCP 工具编排, 决策树引擎, CVE 实时集成, Security Skill, DevSecOps

仓库总 README 声明项目采用 AGPLv3（强互惠许可证，SaaS 化必须开源服务端源码）；模块级 README 与 SKILL.md 声明 MIT。两者以哪个为准、以及商业使用授权，请以仓库维护者最新说明为准。【需核实】
↩︎

亚马逊云科技技术品牌专区

更多推荐

2026年AI编程工具排行榜：10款主流产品深度横评，谁才是真正的提效之王

三个月实测10款AI编程工具，从代码生成质量、Agent能力、过程可控性、性价比、IDE兼容性五个维度打分排名。文心快码以SPEC规范驱动+Multi-Agent矩阵在可控性上拉满，附完整对比表和选型建议。

亚马逊云科技技术品牌专区

深入理解 AI Agent · MCP 子系列 #02：MCP Server 开发实战—从工具注册到无状态新规范

亚马逊云科技技术品牌专区

ChatGPT Plus / Pro + Codex 技术深度解析与开发实战（2026年8月）

核心 API 集成：OpenAI 客户端的初始化与 Codex 模型调用智能 Agent 构建：具备自修复能力的代码生成循环多文件项目生成：从需求到完整项目结构的自动化代码审查与优化：基于 Codex 的自动化代码审查流式响应：实时代码生成的实现：工具集成增强代码生成能力企业级部署：负载均衡、缓存与监控随着 Codex 模型能力的持续进化，未来的开发模式将更加智能化。开发者可以将更多精力放在架构设

亚马逊云科技技术品牌专区

所有评论(0)

查看更多评论

安全风信子

@lxcxjxhx

已为社区贡献13条内容

我做了一个 AI 原生安全测试 Skill：让 Claude Code/Cursor 直接进入安全工程模式

安全风信子

目录

先看问题场景

一、AI Coding 时代，安全测试为什么越来越跟不上

1.1 代码生产速度，第一次超过了安全消费速度

1.2 传统安全工具的三个"看不到"

1.3 真正缺的是 Security Skill，而不是又一个 Scanner

二、什么是 HOS-Sec-Engine

2.1 一句话定位

2.2 与传统 SAST/DAST 的本质区别

2.3 为什么采用 Skill + 工具链架构

三、HOS-Sec-Engine 整体架构

3.1 架构总览

3.2 核心模块拆解

3.3 引擎执行的一条主线

四、为什么不是简单 Prompt

4.1 Skill vs Prompt：一张表看懂

4.2 Workflow：YAML 流程模板 = 方法论的外置硬盘

4.3 Decision Tree：让流程"活"起来

4.4 Tool Calling + MCP：AI 的手和脚

4.5 安全上下文 + 可重复执行

五、实际案例：给 AI 一个存在漏洞的项目

5.1 案例背景与启动

5.2 执行过程：引擎眼中的完整生命周期

5.3 结果与报告：三件套输出

5.4 踩坑实录：第一次跑就翻车的三个教训

六、最关键的设计：让 AI 学会"什么时候调用什么工具"

6.1 工具选择的三个层次

6.2 决策规则引擎：AI 的"判断层"

6.3 CVE 实时集成：把"情报"接到工具链上

6.4 路由策略：最后一百米的可靠性

七、适合哪些人

一个提醒：能力越大，边界越要清楚

八、总结

学完本文，你能做什么？

本文核心观点回顾

所有评论(0)

温馨提示：您尚未绑定手机号

安全风信子