企业官网建设流程全解析

给 AI 系统做安全测试和传统安全测试不是一回事：除了"这个服务有没有 CVE"，还得回答"Agent 会不会被提示词注入劫持、MCP Server 会不会偷凭证、Skill 里有没有藏恶意代码"。这类问题纯规则扫不出来，纯靠 LLM 又贵又不稳定。腾讯朱雀实验室开源的 AI-Infra-Guard（A.I.G，Apache-2.0，5487 stars，今天还在 GitHub Trending 上）给的方案是双引擎架构：Go 写的规则引擎做确定性的指纹识别 + CVE 匹配，Python 写的 LLM agent 做需要推理的代码审计和越狱评估，两条腿走路。上周刚发 v4.5.2（2026-08-17）。本文拆它的架构演进、规则格式、三段式审计流水线，以及接入 CI 时实际会踩的坑。

架构演进：单二进制扫描器 → 多模块红队平台

v3.6+ 的运行拓扑：

WebUI / CLI / REST API / WebSocket └─▶ 任务调度器 ├─▶ AI Infra 扫描（Go 规则引擎：指纹识别 → CVE 匹配） ├─▶ MCP/Skill 扫描（Python agent：静态规则 + LLM 验证） ├─▶ Agent 扫描（多 agent 流水线：注入/SSRF/泄露测试） └─▶ 越狱评估（Python：攻击生成 → 目标 LLM → 判定器 → 安全分）

四个关键设计决策值得抄：

1. Rule-first, LLM-augmented：核心检测保持确定性（YAML 指纹 + 漏洞规则），快且结果可复现；LLM 只叠加在需要推理的场景（MCP 代码审计、Agent 行为模拟）。扫描器最怕"这次报、下次不报"，规则引擎兜底保证了基线稳定。
2. 按关注点拆语言：Go 处理高并发网络探测和 Web 平台，Python 处理 LLM agent 循环和评估框架。不用一个语言硬扛所有场景。
3. Data 即真相：所有检测规则放data/目录做版本管理，不编译进二进制——目前 143 个指纹文件、116 个组件级漏洞规则、覆盖 2000+ CVE 条目，规则库可以脱离主程序单独更新。贡献新指纹 = 往data/fingerprints/加个 YAML 提 PR，不碰主程序。
4. 引擎可插拔：每个扫描模块独立部署、独立版本，通过任务 API 连接。

规则引擎：指纹识别 + CVE 匹配

AI 基础设施扫描的输入是"运行中的服务地址"，不是 GitHub URL。vLLM 填http://127.0.0.1:8000，Ollama 填http://192.168.1.100:11434，ComfyUI 填http://10.0.0.5:8188，支持 CIDR 和 IP 区间批量扫。流程：HTTP 探测 → 指纹匹配 → 版本提取 → 漏洞库匹配。

指纹规则是 nuclei 风格的 YAML，这是data/fingerprints/ollama.yaml原文：

info: name: ollama author: 腾讯朱雀实验室 severity: info metadata: product: ollama vendor: ollama http: - method: GET path: '/' matchers: - body="Ollama is running" version: - method: GET path: '/api/version' extractor: part: body group: 1 regex: '{"version":"(\d+\.\d+\.?\d+?)"}'

两个设计点：http.matchers只负责确认"是这个组件"，版本提取单独走version.extractor的正则——指纹和版本解耦，CVE 匹配依赖精确版本号而不是 banner 关键词，减少误报。识别出组件版本后，漏洞匹配在data/vuln/的规则里做，支持 Ollama、ComfyUI、vLLM、n8n、Triton 这些 AI 组件，不是通用 Web 漏洞库。

LLM 审计引擎：MCP/Skill 扫描的三段式流水线

MCP Server 和 Agent Skill 的扫描走另一条路：把源码（本地目录或 GitHub URL）交给 LLM agent，跑 Info Collection → Code Audit → Vulnerability Review 三段流水线。agent 通过 XML schema 注册工具（file/ls/grep/dir/base64_decode/thinking/finish）自主浏览代码、定位漏洞、输出结构化结果。CLI 用法：

# Skill 扫描（PyPI 安装，可直接进 CI） pip install aig-skill-scan export LLM_API_KEY="your-api-key" aig-skill-scan --repo /path/to/skill -m deepseek-v4-flash --language en -o result.sarif.json # MCP 扫描：静态源码 + 动态打运行中的服务 python main.py --repo ./mcp-server -m "anthropic/claude-sonnet-4.5" -o report.sarif.json python main.py --server_url "http://localhost:8000/sse" --prompt "Test tool poisoning"

CLI 默认单阶段模式（只跑 Code Audit），比三段快约 3 倍；输出 SARIF 2.1.0——GitHub Code Scanning、GitLab Security Dashboard、VS Code Problems 面板原生可消费，这是它进 CI 的关键设计。

MCP 风险分类是 MCP01–MCP10 + 3 个补充规则（Name Confusion 仿冒、Rug Pull 先信任后变脸、Tool Shadowing 同名工具覆盖），Skill 风险分类按 SkillTrustBench 的 T01–T09 五层：

SkillTrustBench 基准上不同 LLM 做审计的 F1——审计质量是模型选型的函数，不是工具的：

Gemini 3.5 Flash 的 FPR 只有 0.012，适合当"先过滤再人工复核"的第一道闸；要低漏报（Recall 0.9974）就上 Opus 4.6。产出分三档判定：malicious（有明确攻击意图）/suspicious（有漏洞但无攻击意图）/normal。

Agent 动态黑盒扫描

Agent Scan 不打源码，打运行中的 Agent 平台（Dify、Coze、OpenAI 兼容接口、WebSocket 等），通过 provider YAML 描述被测目标：

targets: - id: "http" config: url: "http://127.0.0.1:18081" endpoint: "/chat" method: "POST" headers: Content-Type: "application/json" body: message: "{{prompt}}" transform_response: "reply" # 从响应里取 Agent 回复的 JSON key

内置 10 个检测技能（默认跑 5 个核心：数据泄露、工具滥用、间接提示词注入、授权绕过、Web 外传），结果映射 OWASP ASI 分类。最大的坑是transform_response：自定义 HTTP provider 不填它，所有响应被解析成 None，扫描结果为零——这是文档明确标注的必填项，Web UI 里对应"响应解析器"输入框。

实践记录与踩坑

• 无鉴权，别暴露公网。README 原话：平台定位企业/个人内网自检，当前没有认证机制。Docker compose 部署要求 4GB+ 内存、10GB+ 磁盘，Web 端口 8088。
• 恶意代码会藏。v4.5.2 新增 .pyc bytecode 绕过检测和 charset smuggling 防御——攻击者把恶意代码编译进 .pyc 躲过文本审计，或用编码混淆绕过规则匹配（pre_scan 阶段做编码异常检测）。扫第三方 Skill 时这两类要重点看。
• 扫描器自己也会被反打。v4.5.2 在 MCP 动态模式加了工具白名单防 RCE——LLM 驱动的扫描器去连恶意 MCP server 时，对方可能反过来诱导审计 agent 执行命令。给审计 agent 的执行能力设边界，这个设计值得抄进自己的 Agent 测试基建。
• 成本控制：三段式（含 Review 阶段）比单阶段贵且慢。CI 里用单阶段 + SARIF 输出卡门禁，平台交互式排查再跑三段。LLM 配置走环境变量（LLM_API_KEY/LLM_MODEL/LLM_BASE_URL），配置优先级 CLI > 环境变量 > 默认值。
• 模型分工：mcp-scan 支持给不同任务配不同模型（THINKING_MODEL=gemini-2.5-pro、CODING_MODEL=claude-sonnet-4.5），推理用强模型、生成用快模型，能压不少成本。
• 评分口径：安全分 =max(0, 100 - Σ扣分)，Critical -100 / High -40 / Medium -25 / Low-Info -10。接门禁建议按"存在 Critical 即 fail"卡，别用总分——总分会被一堆 Low 刷低，失去拦截意义。

定位与进阶方向

平台化体检和动态红队框架不冲突，可以组合：CI 里aig-skill-scan出 SARIF 进 Code Scanning 卡合并，夜间任务跑 Agent Scan 全量，发布前用 RAMPART 这类 pytest 插件做 Agent 行为回归（断言"特定攻击下 Agent 是否表现出预期行为"）。A.I.G 的 API 也支持完整自动化（上传源码 → 创建任务 → 轮询状态 → 拉结果），适合接到自己的测试平台上。

进阶方向：SkillTrustBench 基准对齐（自建 Skill 审计器可以拿它当评测集）；指纹/CVE 规则库的自动化更新（项目已按 CVE/GHSA 源做半自动对齐）；越狱评估的多轮攻击方法（v4.5.1 已支持 Many-Shot、PAIR、GOAT、ActorAttack 四种）。AI 安全测试现在还是"规则 + LLM"双引擎的形态，等 Agent 工具调用边界标准化之后，大概率会往"行为契约测试"收敛——提前把资产体检和运行时断言两条链路都搭好，不亏。