文章总结： 本文提出Prefill-AI-Native-SAST方法，利用LLM的prefill阶段并行计算优势（约10000t/s）与约束输出（≤100token），实现1小时审计1万接口的高效安全审计。核心方案包括单接口独立预填、输出schema强约束和批量流水线编排，在车端和IoT场景中成功发现RCE和权限缺陷漏洞。建议采用流水线替代agent思考链，通过JSONSchema和校验层工程化审计流程。 综合评分： 85 文章分类： AI安全,WEB安全,红队,内网渗透,安全工具

1小时审计1w接口，ai白盒之完全利用大模型prefill

原创

Lior1969 Lior1969

Moonlight安全

2026年8月11日 11:40 北京

在小说阅读器读本章

去阅读

Prefill-AI-Native-SAST

利用 LLM Prefill 速率优势的 AI-Native 接口安全审计：1 小时 1 万接口、8 小时数百级仓库复核

⏱️ 1h 审 10k 接口🎯 AI-Native（非 AI-Powered）🚗 x端 RCE / IoT 权限

1. 行业术语澄清：从 AI SAST 到 AI-Native SAST

当前业内对”AI 安全审计”叫法混乱，先把概念拉齐：

| 术语 | 含义 | 代表厂商 / 来源 | | — | — | — | | AI SAST | 最通用的叫法，指用 AI（LLM/ML）增强或替代传统静态分析 | Cycode、Snyk、Semgrep、Arnica 等 | | AI-Powered SAST | AI 仅用于辅助（如结果解释、修复建议），底层仍是规则引擎 | SonarQube、Veracode、Checkmarx 等 | | AI-Native SAST | AI 本身就是核心检测机制 ，不依赖传统规则引擎 | Datadog 开源项目、ZeroPath 等 | | Agentic Code Security | 更前沿的概念：智能体直接从代码推理威胁模型，而非扫描器输出 | Cycode、GitLab 等 |

本文主张：把”AI-Native”效率和质量同时做到极致，关键不是 prompt 调得多漂亮，而是让 LLM 跑在它最擅长的速度档位上——这就是 Prefill 优势。

1.1 什么是企业长期处置相同问题的方案

• 工具链思考（Tool-Chain Reasoning）是开销黑洞

  ：每个 action 都要重新预填上下文、调用工具、走决策循环，decode 输出占比极高。

• 不可复现

  ：同一份代码，两次跑出的漏洞清单可能不一致，无法作为合规证据。

• 不可并行

  ：单进程顺序调度，难以堆机器扩吞吐。

• 无法做”工程化沉淀”

  ：提示词、规则、白名单都得写在代码里，每次升级都改工程。

• 成本曲线无法平摊

  ：长期使用，token 费用远超一次性投入。

核心观点：LLM 推理分为 prefill（处理输入 prompt，并行、极快）与 decode（自回归生成输出，串行、慢得多）两个阶段。 一个万级接口的代码库需要审计的 prompt 输入可以轻松堆到 10000 t/s prefill 的吞吐，而 decode 也许只有 60 t/s。 约束输出 → 充分利用 prefill → 整体吞吐碾压传统 agent。

2. Prefill vs Decode：被忽略的 100× 速率差

LLM 推理的两阶段速率差异（典型 7B-70B 模型 + 高端 GPU）

KV Cache

📥 Prefill处理 prompt 输入并行计算~10,000 t/s

📤 Decode自回归生成严格串行~60 t/s

输出 token

2.1 速率基准

| 阶段 | 性质 | 典型速率 | 瓶颈 | | — | — | — | — | | Prefill | 并行（一次性吃下整个 prompt） | ~10,000 t/s | 显存带宽、KV Cache 容量 | | Decode | 串行（每生成一个 token 必须等上一个） | ~60 t/s | 带宽 + 显存读写 + 注意力 |

2.2 含义：如果输出控制在 100 token 以内

让一次”接口审计”的输出上限是 ~100 token（实际再看）（漏洞等级 + 一句话说明 + 仓库位置 + 极少上下文），意味着：

• decode 阶段耗时 ≈ 1.6 秒

  （100 ÷ 60）。

• prefill 阶段可以并行跑批

  ，每批 10-50 个接口共享一次 prefill。

• 总成本 = prefill 成本 + decode 成本

  ，而 decode 只占小头。

• 可编排

  ：用静态流水线替代 agent 的思考链，输出 token 数完全可控。

经验法则：如果你要做”万级接口、小时内完成”的批处理，约束输出比任何 prompt 工程都管用。

3. 核心方案：Prefill-AI-Native-SAST

整套方案的精髓：把 LLM 当成”快速预填 + 受控输出”的批量处理器，而不是带工具链的 agent。

①

单接口独立预填

每个接口的代码切片 + 上下文作为独立 prefill 输入，互不干扰。

②

输出 schema 强约束

用 JSON Schema / 函数调用锁定结构，强制 ≤100 （实际再看）token。LLM 无法发散。

③

批量流水线编排

不依赖 agent 思考链，预填 → 解码 → 落库三段式流水线，CPU/GPU 调度可控。

④

质量并不让步

发现的 4 个接口组合形成的车端 RCE、IoT 多设备权限问题，证明了 token 预算内仍能定位高危漏洞。

⑤

可堆机器扩吞吐

纯流水线无状态，多卡多进程天然支持，吞吐近线性增长。

3.1 输出 schema 设计（强制 ≤100 token）（实际再看）

{
  "severity": "P0",          // P0/P1/P2/P3
  "desc":    "X端 CAN 总线指令注入",
  "repo":    "huawei/vehicle-ecu",
  "path":    "src/can/inject.c:142",
  "chain":   ["api_a", "api_b", "can_send"]
}

每个字段都是关键词，没有废话。LLM 必须在 100 token 内填完。

3.2 Prompt 模板

xxxxx安全审计。
输入：单个接口的代码 + 调用链上下文。
输出严格遵循 JSON Schema：
  {severity, desc, repo, path, chain}
不要任何解释、不要 markdown、不要额外文字。

[代码]
{api_code}

[调用链]
{call_chain}

4. 算力账本与时间线

4.1 单次扫描成本估算

10,000

接口 / 扫描

≤100（实际再看）

token / 接口（输出）

1,000,000

token 总输出（1w 接口）

~4.6 h

decode 60 t/s 理论耗时

4.2 本地部署可行性

很多企业担心云端 API 限额、费用审计、合规问题。Prefill-AI-Native-SAST 对本地极友好：

| 本地部署速率 | 1 万接口总输出 | 1 万接口耗时 | 可审接口 / 天（24h） | | — | — | — | — | | 12 t/s（保守） | 1,000,000 token | ≈ 23 小时 | ~10,000+ | | 30 t/s（中端） | 1,000,000 token | ≈ 9.3 小时 | ~25,000 | | 60 t/s（高端） | 1,000,000 token | ≈ 4.6 小时 | ~50,000 |

关键：减去 agent 路径的”工具调用 → 思考 → 再调用”循环，Prefill-AI-Native-SAST 在同等硬件下可获得 10× 以上的有效吞吐。

4.3 实战复核：1小时 × 万级接口

在某次大型X企XXX审计中，真实成绩：

• 审计范围：

  数百仓库，接口总数 X 万+。

• 复核时长：

  8 小时。

• 关键发现：

  4 个接口组合形成的X端任意代码执行（RCE）链；多个 IoT 设备的权限控制缺陷。

• 输出形态：

  JSON 结构化清单，可直接入漏洞管理平台。

5. 真实产出样例

5.1 单接口输出（<100 token）（实际再看）

{
  "severity": "P0",
  "desc":    "CAN 总线指令未鉴权注入，可远程执行 ECU 任意命令",
  "repo":    "vendor-a/vehicle-gateway",
  "path":    "src/can_handler.c:142",
  "chain":   ["/api/can/send", "/api/auth/login", "can_inject"]
}

5.2 组合漏洞（多接口联动）[真实结果，使用大致案例举例]

{
  "name":    "x端远程代码执行链",
  "severity": "P0",
  "feasibility": 0.92,
  "chain": [
    {"step":1,"api":"/api/auth/login","role":"auth_bypass"},
    {"step":2,"api":"/api/diag/open",  "role":"diag_session"},
    {"step":3,"api":"/api/can/send",   "role":"can_inject"},
    {"step":4,"api":"/api/ota/flash",  "role":"rce"}
  ]
}

5.3 IoT 权限缺陷样例

{
  "severity": "P1",
  "desc":    "智能家居网关的设备配对接口缺少设备级 ACL，可越权控制他人设备",
  "repo":    "vendor-b/iot-hub",
  "path":    "controllers/device_pair.go:88",
  "chain":   ["/api/device/pair", "/api/cmd/send"]
}

注意：这些都是真实审计场景下 LLM 直接输出的结构化结论，没有人类后处理。LLM 在 token 预算内足以推理出”接口 A → 接口 B → 接口 C”的攻击路径，前提是 prompt 里给了调用链上下文。

6. 关键工程细节

6.1 上下文构建：每个接口

接口上下文过大是 prefill 阶段最大的成本来源。控制策略：

• 代码切片

  ：只保留入口函数 + 直接调用的下游。

• 调用链压缩

  ：用文件名 + 行号代替完整代码（”Service#search:42 → DAO#query:88″）。

• 公共依赖剔除

  ：框架代码、配置类、常量不喂 LLM。

6.2 JSON Schema 约束（避免 decode 失控）

{
  "type": "object",
  "required": ["severity", "desc", "repo", "path"],
  "properties": {
    "severity": {"enum": ["P0","P1","P2","P3"]},
    "desc":     {"type": "string", "maxLength": 80},
    "repo":     {"type": "string", "maxLength": 60},
    "path":     {"type": "string", "maxLength": 120},
    "chain":    {"type": "array", "maxItems": 6}
  }
}

6.3 温度与采样（理论上）

• temperature = 0.0

  —— 审计要确定性。

• top_p = 0.9

  —— 极端保守，避免乱选 token。

• max_output_tokens = 120

  —— 硬上限。

• stop

  = ["\n\n", "```"] —— 抑制发散。

6.4 校验层（结构 + 语义）

def validate(out: dict) -> bool:
    if out["severity"] not in {"P0","P1","P2","P3"}: return False
    if len(out["desc"]) > 80:                          return False
    if not re.match(r"^[\w\-/]+:\d+$", out["path"]):    return False
    if len(out.get("chain", [])) > 6:                  return False
    return True

7. 与 Codex Security 的对比

| 维度 | Codex Security | Prefill-AI-Native-SAST | | — | — | — | | 范式 | AI-Powered（agent + 工具调用） | AI-Native （流水线 + schema 强约束） | | 万级接口耗时 | 数天（受 agent 思考链拖累） | 1 小时 | | 输出 token / 接口 | 数千 | ≤100 （实际再看） | | 复现性 | 弱 | 强 （temperature=0） | | 企业长期使用 | 成本曲线陡、不可沉淀 | 流水线可工程化、长期摊薄 | | 组合漏洞发现 | 需要多轮 agent | 调用链上下文一次给齐 | | x端 / IoT 场景 | 工具链难以覆盖固件/X线协议 | prompt 注入调用链即可推理 | | 本地部署 | 需要重写 agent 框架 | 标准 OpenAI 兼容 / vLLM |

⚠️ 注意：“AI-Powered SAST”和”AI-Native SAST”的边界不是 prompt 写得有多花，而是底层是否依赖规则引擎。如果你的产品仍然跑着 Semgrep 规则，把 LLM 接上去叫”AI 解释器”，那是 AI-Powered；让 LLM 直接对代码做威胁推理、不依赖任何 sink 规则库，才是 AI-Native。

8. 本地落地推荐

1. 审计单接口的输出形态

   ：确定你们公司的漏洞条目最少需要哪些字段（一般 4-6 个）。

2. 写 JSON Schema

   ：用 OpenAI Structured Outputs / vLLM guided decoding 锁定结构。

3. 实现上下文构建器

   ：每个接口 ≤4 KB，调用链用代号而非全文。

4. 部署 vLLM / SGLang

   ：本地推理引擎，10 分钟启动 7B 模型。

9. 结论

Prefill 优势是 LLM 时代被严重低估的”性能加速器”。

把输出控制在 ≤100 token（实际再看）、让 prefill 阶段承担 99% 的吞吐， 你可以在 1 小时内审完 1 万接口、8 小时内复核数百仓库—— 这不是 agent 的未来，是流水线的未来。

AI-Native 的本质：不是让 LLM 像人一样思考，而是让 LLM 跑在它最擅长的速度档位。

这套方法已经在XXXXXX链审计中验证：发现 4 个接口组合形成的X端 RCE、多个 IoT 设备权限控制缺陷——而这些在网上几乎没有人公开讨论过如何用 LLM 高效捕获。

Codex Security / Claude Code 适合人写代码、人审代码的交互场景； 企业级、大批量、合规可沉淀的安全审计，必须走 AI-Native + Prefill 流水线。

附录 A：术语表

| 术语 | 含义 | | — | — | | Prefill | LLM 推理的第一阶段，并行处理输入 prompt，生成 KV Cache | | Decode | LLM 推理的第二阶段，串行自回归生成输出 token | | AI-Native SAST | AI 本身就是核心检测机制，不依赖传统规则引擎 | | AI-Powered SAST | AI 仅用于辅助（如结果解释），底层仍是规则引擎 | | Agentic Code Security | 智能体直接从代码推理威胁模型 | | JSON Schema 强约束 | 用结构化输出限制 LLM 的输出格式与长度 | | Guided Decoding | 推理引擎在 decode 阶段屏蔽不符合 schema 的 token | | vLLM | 开源 LLM 推理引擎，支持 continuous batching + guided decoding | | t/s | token per second，每秒处理的 token 数 | | X端 RCE | 通过X载网络（CAN / OTA / 诊断接口）实现的远程代码执行 |

附录 B：关键数字一览

| 指标 | 数值 | | — | — | | Prefill 典型速率 | ~10,000 t/s | | Decode 典型速率 | ~60 t/s | | 速率倍率（prefill / decode） | ~167× | | 单接口输出上限 | ≤100 token（实际再看） | | 1 万接口总输出 | 1,000,000 token | | decode 60 t/s 跑完 1w 接口 | ~4.6 小时 | | decode 12 t/s（本地）跑完 1w 接口 | ~23 小时（仍可在 1 天内完成） | | 单次扫描接口上限（小时级） | 1 万+ | | 实战复核记录 | 8 小时 × 数百仓库，发现 4 接口组合x端 RCE + 多 IoT 权限缺陷 |

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Moonlight安全 Lior1969 Lior1969《1小时审计1w接口，ai白盒之完全利用大模型prefill》