漏洞管理的时间窗口正在急剧缩短。来源材料引用的 M-Trends 2026 数据显示，平均漏洞利用时间已经降到 -7 天，也就是攻击者可能在补丁发布前一周就开始利用漏洞。安全团队因此开始把大语言模型代理接入代码仓库、IDE 和 CI/CD，希望自动发现漏洞、生成 PoC，甚至直接提交修复。
真正棘手的问题不是模型能否找到 Bug，而是：当一个能够读取代码、运行命令、访问工具并创建 Pull Request 的概率系统判断错误，企业如何限制它的权限、成本和影响范围？可行的答案不是让 AI 取代现有控制，而是把 AI 放进由确定性策略、隔离执行和人工审批组成的流水线。
AI 代理必须被当成不可信工作负载
漏洞扫描代理通常会同时接触三类高风险对象：专有源代码、潜在攻击载荷和具有写权限的开发凭据。任何一项失控，都可能把安全工具变成新的攻击入口。
部署前需要建立几条不可绕过的边界：
- 模型之前先做数据控制：由确定性策略引擎过滤 PII、PHI、密钥和其他敏感数据，再通过专用防护模型识别提示注入。不能只依赖提示词要求模型“不要泄露数据”。
- 把源代码视为不可信输入：攻击者可以在注释、测试数据或第三方依赖中植入间接提示注入，例如要求代理忽略漏洞、读取环境变量或向外部地址上传文件。
- 隔离执行环境：代理只能在无特权、短生命周期的容器中编译代码和执行 PoC。容器应采用只读根文件系统，限制 CPU、内存、执行时间和网络出口。
- 使用短期机器身份：代理访问仓库时使用绑定到特定仓库、分支和操作的 JIT Token，不共享开发人员令牌，也不能访问相邻仓库。
- 默认禁止任意外连：只允许访问模型端点、内部制品仓库和集中日志服务。运行期数据流监控需要记录数据去了哪里，而不只是记录代理调用了哪个工具。
- 固定模型和工具版本：模型、MCP 服务、第三方技能和编排框架都属于供应链组件，需要版本锁定、哈希校验、漏洞扫描和变更审批。
还要与模型服务商明确自动化安全测试的授权范围和可接受使用政策，并通过零数据保留协议保护专有代码与未公开漏洞。即使供应商声明不训练客户数据，也应在合同、技术配置和审计记录中同时落实。
两条路线不能混成一条流水线
AI 辅助漏洞管理至少包含两个性质不同的问题。
企业漏洞管理：先解决排序问题
EASM、CSPM、CTEM、传统扫描器和 AI 代理会产生大量重复发现。把更多扫描结果直接推给工程团队，只会放大告警疲劳。正确顺序是先归一化资产和漏洞标识，合并重复项，修正陈旧 CMDB 数据，再计算风险分数。
一种可落地的评分方式是：
最终分数 = 0.20 × 漏洞严重度 + 0.40 × 资产上下文 + 0.40 × 威胁上下文
其中，漏洞严重度可以由 CVSS 基础分乘以 10 得到；资产上下文反映互联网暴露、业务重要性和数据敏感度；威胁上下文则结合活跃利用、PoC、攻击者相关性与 EPSS 概率。权重不是行业常量，应按组织风险偏好校准。合规要求或监管指令也可能覆盖内部排序。
LLM 在这一层更适合整理非结构化威胁情报、提取受影响产品和攻击条件，而不应独立决定是否接受风险或执行隔离动作。高置信度的封禁、终端隔离和凭据吊销仍应交给经过测试的 SOAR 剧本。
产品安全：让概率发现接受确定性验证
SAST 和 DAST 按规则、控制流或运行结果工作；LLM 根据统计和语义关系判断代码。长上下文中的注意力衰减、仓库分块和跨服务调用都会让模型丢失完整数据流。因此，LLM 比较擅长发现局部异常，却可能误判跨文件授权、业务逻辑缺陷和间接 SSRF。
最适合代理审计的是拥有“二元判定器”的目标：输入是否触发崩溃、断言是否失败、越界访问是否被 AddressSanitizer 捕获。C、C++、汇编、Python C 扩展和 JNI 组件尤其适合在沙箱内结合编译器、模糊测试器和内存检测器验证。
授权绕过或复杂业务逻辑依赖“架构判定器”。模型即使生成了能运行的 PoC，也未必知道该路径是否可达、是否需要管理员权限、是否涉及真实敏感数据。此类发现必须由理解信任边界和业务意图的工程师复核。RAG 可以补充设计文档，却不能解决文档过期、冲突或缺失的问题，人工威胁建模仍然不可省略。
可以这样实践：风险门禁与 PoC 验证
下面是一个可以直接运行的最小风险评分器。它不是来源材料中的产品 API，而是根据文中评分方法构造的实践示例。把三个输入替换成漏洞平台计算出的 0 到 100 分值即可。
#!/usr/bin/env python3
import argparse
import json
WEIGHTS = {
'vulnerability': 0.20,
'asset': 0.40,
'threat': 0.40,
}
def bounded(value: float) -> float:
if not 0 <= value <= 100:
raise argparse.ArgumentTypeError('score must be between 0 and 100')
return value
def main() -> None:
parser = argparse.ArgumentParser()
parser.add_argument('--cvss', type=float, required=True)
parser.add_argument('--asset', type=bounded, required=True)
parser.add_argument('--threat', type=bounded, required=True)
parser.add_argument('--gate', type=float, default=70)
args = parser.parse_args()
vulnerability = bounded(args.cvss * 10)
score = round(
WEIGHTS['vulnerability'] * vulnerability
+ WEIGHTS['asset'] * args.asset
+ WEIGHTS['threat'] * args.threat,
2,
)
result = {
'score': score,
'requires_priority_review': score >= args.gate,
'inputs': {
'vulnerability': vulnerability,
'asset': args.asset,
'threat': args.threat,
},
}
print(json.dumps(result, indent=2))
if __name__ == '__main__':
main()
保存为 risk_score.py 后可以运行：
python3 risk_score.py \
--cvss 8.8 \
--asset 100 \
--threat 75 \
--gate 70
这个分数可以决定处理 SLA 和是否进入代理审计，但不能直接授权代理修改生产环境。对于代码漏洞，可以在 CI 中增加一个独立验证任务。下面假设代理已经生成 security/poc_test.py，而仓库测试使用 pytest：
name: Validate AI security finding
on:
pull_request:
paths:
- 'security/poc_test.py'
- 'src/**'
- 'tests/**'
permissions:
contents: read
jobs:
validate:
runs-on: ubuntu-latest
timeout-minutes: 10
container:
image: python:3.12-slim
options: --cap-drop=ALL --security-opt=no-new-privileges
steps:
- uses: actions/checkout@v4
with:
persist-credentials: false
- name: Install pinned test dependencies
run: pip install --no-cache-dir -r requirements-test.txt
- name: Run regression suite
run: pytest -q tests
- name: Verify remediation against PoC
run: pytest -q security/poc_test.py
实际部署时还需要由平台层关闭默认网络出口、限制并发数和迭代次数，并将执行日志送入不可变的集中存储。工作流令牌只有读权限；若代理需要创建 PR，应由另一个受控服务使用短期令牌完成，不能把写令牌暴露给执行 PoC 的容器。
一个有效的分流规则可以是：PoC 无法编译、运行超时或未得到预期判定时，不创建人工工单，只保留审计记录；PoC 成功且回归测试通过后，再交给工程师判断可达性、业务影响和修复优先级。设置这一门槛也能阻止代理在“生成、失败、重写”的循环中无限消耗 API 与计算预算。
修复阶段：代理只能提 PR，不能直接改主分支
IDE 中的代理适合局部、语法级修复，例如替换字符串拼接 SQL、移除硬编码密钥或更新明显过期的调用。开发者可以立即查看上下文并拒绝不合理改动。
中央 CI/CD 代理面对的范围更大，应遵循更严格的契约：
- 代理只在临时分支生成最小补丁并创建 PR。
- 原始 PoC 必须转化为回归测试，修复后重新执行。
- 标准单元测试、集成测试和安全策略检查全部通过。
- 人工审查者验证信任边界、业务语义和补丁可维护性。
- 审计日志记录模型版本、提示输入摘要、工具调用、测试结果和批准人。
- 部署使用渐进发布、运行期监控和自动回滚。
模型版本必须固定，但固定版本也会终止服务，所以团队需要把模型升级当作依赖升级：在隔离环境重放历史案例，测量误报率、漏报风险、成本和补丁质量，再切换生产流水线。
上线前检查清单
采用 AI 漏洞代理时，可以用以下问题作为准入门槛：
- 代理读取的代码、文档和依赖是否都按不可信输入处理？
- 是否在模型调用之前拦截密钥、PII、PHI 和提示注入？
- 执行环境是否无特权、短生命周期、受资源和网络策略限制？
- 机器身份是否短期、可追踪，并绑定到单个仓库和分支？
- 每个高风险发现是否附带可重复执行的确定性验证？
- 是否限制代理的执行时间、重试次数、并发和费用？
- AI 生成的修复是否只能通过 PR、测试和人工审批进入主分支？
- 是否保留模型版本、工具调用、测试证据和审批人的不可变日志？
- 是否仍在维护 SAST、DAST、资产发现、威胁建模和基础身份控制？
AI 可以加快漏洞发现和修复，但它不会修复糟糕的权限架构，也不能提供穷尽性保证。更稳健的长期路线，是让代理处理可验证、局部且重复的工作，把架构判断交给人，同时通过内存安全语言、最小权限、微分段、短期身份和供应链控制，从设计上消除整类漏洞。