传统漏洞扫描擅长回答“代码里可能有什么问题”，却不一定知道“攻击者此刻正在打哪里”。Cloudflare 将 Managed Defense 的 WAF 数据、生产流量和安全信号与 OpenAI Daybreak 模型结合，让漏洞发现从静态告警列表转向上下文驱动的处置流程：优先确认正在被利用或暴露程度较高的问题，在安全条件允许时准备边缘缓解规则，同时生成供工程师审查的代码补丁建议。
排序依据从 CVSS 扩展到真实暴露面
单看漏洞严重度，团队很容易被大量高危告警淹没。两个 CVSS 分数相同的问题，在生产环境中的风险可能完全不同：一个接口没有外部流量，另一个接口正持续收到符合利用特征的请求。
上下文感知的漏洞排序可以综合以下信号：
- 漏洞自身的严重度与可利用性；
- 受影响路由是否暴露在公网；
- 生产流量是否实际经过相关代码路径；
- WAF 是否观察到匹配的攻击模式；
- 攻击频率、来源分布以及近期增长趋势；
- 资产是否承载身份、支付或敏感数据；
- 是否已有可靠的边缘缓解措施。
这并不意味着流量少的漏洞可以忽略。生产信号用于调整处置顺序，而不是替代代码扫描、依赖分析和人工安全审查。例如，一个尚未被探测但能够绕过身份认证的漏洞，依然可能需要立即修复。
边缘缓解与代码修复是两条时间线
发现活跃攻击后，应用补丁通常还要经历开发、测试和部署。WAF 位于应用前方，可以先阻断特征明确的恶意请求，为代码修复争取时间。合理的闭环通常分为四步：
- 将扫描结果映射到路由、服务和生产流量。
- 使用 WAF 事件判断漏洞是否正在被探测或利用。
- 对高置信度场景准备范围尽可能小的边缘规则。
- 生成代码补丁和测试建议，经人工审查后进入正常发布流程。
“准备缓解规则”不应等同于“模型自动上线规则”。规则过宽可能阻断合法请求，规则过窄又可能被轻易绕过。上线前至少要检查匹配范围、误报样本、监控指标、到期时间和回滚方式。对于影响登录、上传、Webhook 或 API 客户端的规则，可以先运行在记录模式，再逐步启用阻断。
可以这样实践：构建一个可解释的优先级队列
下面是一个可直接运行的最小 Python 示例。它不是 Cloudflare 或 OpenAI 的正式 API，而是一个用于内部流程原型的假设模型：输入漏洞严重度、生产请求量、WAF 攻击命中数和资产敏感度，输出带理由的优先级列表。
将代码保存为 prioritize.py，使用 Python 3.10 及以上版本运行 python prioritize.py：
from dataclasses import dataclass
from math import log10
@dataclass
class Finding:
finding_id: str
route: str
severity: float # 0-10
requests_24h: int
waf_hits_24h: int
sensitive_asset: bool
def score(finding: Finding) -> tuple[float, list[str]]:
value = finding.severity * 5
reasons = [f"severity={finding.severity}"]
if finding.requests_24h > 0:
exposure = min(log10(finding.requests_24h + 1) * 6, 24)
value += exposure
reasons.append(f"production exposure +{exposure:.1f}")
if finding.waf_hits_24h > 0:
attack = min(log10(finding.waf_hits_24h + 1) * 12, 36)
value += attack
reasons.append(f"observed attack traffic +{attack:.1f}")
if finding.sensitive_asset:
value += 15
reasons.append("sensitive asset +15")
return round(min(value, 100), 1), reasons
findings = [
Finding("VULN-101", "/api/search", 8.1, 420_000, 1_280, False),
Finding("VULN-102", "/internal/report", 9.4, 0, 0, True),
Finding("VULN-103", "/login", 7.5, 95_000, 74, True),
]
ranked = sorted(
((score(item)[0], item, score(item)[1]) for item in findings),
key=lambda row: row[0],
reverse=True,
)
for priority, finding, reasons in ranked:
print(f"{priority:5.1f} {finding.finding_id:8} {finding.route}")
print(" " + "; ".join(reasons))
实际接入时，应把输入替换为漏洞管理平台、路由清单和经过聚合的 WAF 事件。不要把完整请求体、身份令牌、Cookie 或客户数据直接发送给模型；优先传递脱敏后的路径模板、规则编号、计数、时间窗口和最小必要代码片段。
模型输出也应采用结构化格式，例如：
finding_id: VULN-101
confidence: high
observed_exploitation: true
recommended_actions:
- type: edge_mitigation
mode: log_only
expires_after: 24h
rollback_owner: security-oncall
- type: code_patch
requires_human_review: true
required_tests:
- legitimate search requests remain accepted
- known exploit payloads are rejected
- encoded and duplicated parameters are covered
结构化结果便于执行策略校验。例如，缺少负责人、到期时间或回滚方案时，自动化系统可以拒绝部署边缘规则，而不是尝试理解一段自由文本。
补丁建议必须进入现有工程护栏
模型可以关联漏洞、攻击样本与相关代码，但补丁仍可能改变业务语义。安全团队需要验证修复是否处理了根因，而不只是拦截某个已见过的载荷。工程流水线至少应包含单元测试、针对漏洞的回归测试、静态分析、依赖检查和分阶段发布。
还要防范来自流量内容的提示注入。请求参数、Header 和上传内容都属于不可信数据，不能被当作模型指令。系统应把遥测数据放在明确的数据字段中，限制模型可调用的工具，并让部署动作经过独立策略引擎和人工批准。
落地时检查这五件事
- 是否能把漏洞稳定映射到具体服务、路由和代码所有者；
- 风险分数是否保留组成项和证据，便于审计与质疑；
- 边缘缓解是否默认小范围、可观测、可过期、可回滚；
- 发送给模型的数据是否完成脱敏和最小化；
- 代码补丁是否经过测试、代码审查和正常发布机制。
这类方案真正缩短的不是扫描时间，而是从“发现告警”到“确认生产风险并采取可逆行动”的时间。WAF 信号提供现场证据，Daybreak 模型帮助关联上下文与生成修复候选，而最终的部署权仍应由可审计的工程流程掌握。