★ FEATURED ARTICLE 做安全运营这行有一件事几乎每天都在重复漏洞报告越堆越多可真正值得动手的没几份。我手上这套流程高峰期一天能收几十份扫描器告警和外部提交的报告七成是重复、误报或者压根儿不需要处理的噪音。为了把人力挤出来留给真正要紧的问题我搭了一个叫 Jev 的初筛管道——它能在 1 秒内对 8 份漏洞报告完成预判和排序。做完之后我又把 Jev 的评定逻辑以提示词和本地脚本的形式接进了 Claude Code 和 Codex 这两款 AI 编码助手的工作流让它们在帮忙改代码的同时也能按同一套标准输出漏洞确认结论和修复建议。这篇就是 Jev 从设计到落地的完整实战记录写给同样被报告海淹过的人。1. 漏洞评估的筛选难题为什么非逼着自己做一个秒筛工具1.1 我面对的真实漏洞报告流长什么样先说背景。参与漏洞评估工作的头几个月我对报告的认知还停留在每份都应该认真读一遍的阶段。但现实很快打脸扫描器每跑一轮就刷出几百条告警SRC 平台上的提交报告描述千奇百怪有的只写存在 SQL 注入连参数都没给有的贴了一长段日志核心信息淹没在噪声里还有相当一部分是重复提交——同一漏洞换个标题再发一次。后来我统计过一周的数据总共 273 份待处理的报告里明确重复的有 96 份能从标题和描述一眼判定为误报的有 71 份剩下 106 份才真正需要逐字阅读。也就是说超过六成的工作量完全可以被机器先吃掉。这个比例让我下定决心做自动初筛而不是继续靠肉眼硬扛。1.2 人工筛选的隐性成本比想象中高得多很多人觉得扫一眼标题不费时间但在真实流程里筛选的隐性成本是巨大的。每份报告都要打开、读标题、扫描述、看附件、查标签然后才能决定放行还是打回。一个熟练的人处理一份平均 300 字的报告大概要 40 秒到 2 分钟遇到含糊其辞的来回查证能拖到 5 分钟以上。8 份报告就是 10 到 15 分钟一天 50 份就是整整两小时起步。更麻烦的是注意力损耗。我试过连续筛 30 份报告之后状态肉眼可见地下降开始对真正的高危漏洞反应迟钝。这不是态度问题是人脑的天然局限。把重复劳动交给规则引擎把专业判断留给状态最好的时候才是可持续的方案。1.3 Jev 的定位先压量再做深度判断我想要的工具不是取代漏洞分析师而是当一道前置闸门。Jev 的职责只有三条把明显重复的挑出来把低级误报踢出去把最有可能需要紧急处理的报告顶到最前。它的输出不是这个漏洞是真的而是这份报告按已知规则看像什么级别、有多大概率值得看。真正确认漏洞性质、评估危害、给出修复方案仍然由人和大模型协作完成。这个定位很重要。它决定了 Jev 的技术选型不需要上太重的东西排斥复杂模型拥抱轻量规则。这也是它能够做到 1 秒处理 8 份报告的根本原因。2. Jev 的 1 秒初筛是怎么做到的规则引擎的内部工作方式2.1 第一步先让机器看懂不同格式的报告初筛的前提是解析。漏洞报告的来源五花八门扫描器导出的 JSON、SRC 平台导出的 Excel、邮件里的纯文本、PDF 附件。Jev 采用的方案是统一转成结构化字典再丢进下游规则。这一步不追求完美只求跑通大多数情况。我给它定义了这样一个最小结构report { title: str, # 报告标题 reporter_type: str, # 提交者类型扫描器/人工/协作方 vuln_type_hint: str, # 标题或首段中提取的漏洞类型关键词 component: str, # 受影响组件/URL/主机名 has_poc: bool, # 是否附带可复现内容/附件 description: str, # 描述正文 severity_label: str, # 提交者自带的等级标签可能为空 duplicate_key: str, # 用于去重的归一化指纹 }解析策略很简单优先从结构化来源JSON、Excel直接映射字段对纯文本和 PDF则用正则提取 URL、IP、漏洞类型关键词、附件标记剩余内容整段塞进description。这里有个实操心得永远不要把解析完整作为前置条件否则会因为几个奇怪的格式卡住整条管道。Jev 对缺失字段做降级处理后面用规则兜底。2.2 第二层设计三层裁决管道而不是一个打分类模型Jev 的核心不是机器学习模型而是三段式裁决管道每一层的职责单一、可解释、可调参第一层去重。思路是做归一化指纹。看三个信号受影响组件、漏洞类型关键词、标题中提取的核心名词。组件按域名和 IP 归一化类型关键词做同义词折叠比如SQL 注入SQLisql injection全部映射到sqli。三个信号拼接后取哈希作为duplicate_key与历史池比对。指纹命中就直接标记重复并关联最早报告编号。第二层排除。处理两类明确不需要人工看的内容。一是黑名单命中比如报告描述里出现仅供测试无意发现无法复现这类弱信号或者提交者等级标签就是低危且没有任何 PoC。二是组件白名单某些已知的非关键组件即便报漏洞也排到优先级末尾。这层可能会误伤所以 Jev 不会直接删掉这些报告只是把它们降级为观察清单。第三层保送。把最值得人看的报告顶上来。触发条件包括核心业务组件 高危类型关键词自带 PoC 或复现步骤提交者等级为高危/紧急且描述没有明显矛盾。这一层的作用是把有限注意力引导到风险最集中的角落。2.3 打分与排序不追求精确只追求相对顺序正确三层裁决结束后Jev 会对穿过管道的每份报告算一个 0 到 100 的初筛分。分数是加权规则累加权重我根据经验调过几轮当前是这样信号权重说明高危类型命中RCE/SQLi/SSRF/越权等30按类型表映射核心业务组件命中25组件重要性清单附带 PoC/复现内容20有附件或复现步骤提交者标注高危/紧急15仅作参考不独立采信白名单组件命中-40一票否决倾向描述含无法复现等弱信号-15降低可信度分数的作用不是判定真假而是划定处理顺序80 分以上先处理50 到 79 分进入常规队列50 以下放低优先级。8 份报告在单核 CPU 上走完全部规则大概耗时 0.6 到 0.9 秒加上解析环节整体能稳定压在 1 秒内。2.4 用 8 份报告完整推演一遍初筛过程这部分我用一次真实流程来演示。某工作日的待处理队列里有 8 份报告代号 A1 到 A8A1核心 API 网关疑似 SQL 注入附带完整 POST 报文和响应对比提交者标紧急A2同一网关同参数的另一份报告标题换成了sql injection at certain endpointA3某个宣传页面的 URL 参数报 XSS无复现步骤提交者标低危A4第三方组件版本过低告警组件不在白名单也不在核心清单A5内部系统的 SSRF 报告有截图和本地复现环境说明标高危A6只有一行发现可能有问题没写组件没写类型也没附件A7核心服务报越权描述详细且有两条请求对比标高危A8一条扫描器自动生成的告警描述和某历史报告高度相似指纹命中Jev 的实际输出是A1、A7、A5 进入优先队列分别拿到 87、85、82 分A8 标记为重复关联历史报告编号A2 重复关联 A1A3 进常规队列50 分A4 落观察清单35 分A6 落低优先级18 分。整个过程跑完耗时约 0.8 秒。人只需要读 3 份报告而不是 8 份。关键在这里Jev 不是用智能完成的它用的是笨功夫——枚举信号、定义权重、查表排除。但这恰恰是它稳定的原因。规则引擎的行为是确定的同样的输入永远有同样的输出这为后面接入 AI 助手打下了基础。3. 把判断力装进Claude Code 和 Codex三条可落地的接入路径3.1 为什么非要接入 AI 编码助手而不是单独做个聊天机器人初筛只能回答该看哪些报告回答不了这些漏洞到底怎么修。而让漏洞处置真正提速需要在代码修改的现场给出答案。Claude Code 和 Codex 恰好是这一场景里的常用工具它们能被开发者直接指挥去查代码、改代码能在上下文里带文件路径和代码片段。把 Jev 的判断标准塞进它们的工作流程等于把哪些是陷阱、哪些要保送、修复时注意什么变成两个 AI 助手共同的背景知识。我的目标很具体当开发者对着一份漏洞报告问 Claude Code 或 Codex 的时候它们不再是泛泛地回答建议输入校验,而是能按 Jev 的判定逻辑先拆解报告信号、给出与初筛一致的优先级判断再基于项目代码给出针对性的修复建议。3.2 路径一把判断框架写进系统指令最简单的接入方式是把 Jev 的规则浓缩成一段系统级指令在每次会话开始前注入。我写了一份jev_priority_policy.md核心内容如下你是本项目的安全修复助手。在收到任何漏洞报告分析请求时必须按以下流程处理 1. 拆解报告信号 - 提取漏洞类型、受影响组件、是否附带PoC、提交者等级标注。 - 检查是否存在重复特征同组件同类型相似描述。 2. 输出初筛等级 - critical高危类型 核心组件 可复现 - high高危类型 或 核心组件 PoC - medium单一信号成立但缺少复现材料 - low信号弱、组件非核心、或白名单命中 3. 修复建议约束 - critical/high必须同时给出根因分析、代码定位、修复补丁思路、回归测试注意点。 - medium/low必须说明为什么维持该等级以及哪些条件下需要升级。这样做的优点是无缝融入对话Claude Code 也好、Codex 也好只要把该文件的内容贴进上下文或者通过项目配置文件加载就能立刻改变它们回复的结构。注意不要写按照安全最佳实践这种空话规则必须可执行、有明确分支。3.3 路径二让 AI 助手直接调用 Jev 的本地脚本光有指令还不够AI 助手缺少的是运行规则的能力也就是确定性信号比如指纹重复判定靠它的 Transformer 上下文推理不太靠谱。因此第二条路径是把 Jev 封装成命令行工具再作为工具函数暴露给 AI 助手。Claude Code 和 Codex 都支持通过工具调用机制执行外部命令。我写的入口脚本长这样#!/usr/bin/env python3 Jev CLI - 漏洞报告初筛工具 import argparse, json, sys def load_rules(): # 规则表统一放在规则目录中支持热更新 return json.load(open(jev_rules.json)) def evaluate(report: dict) - dict: # 与2.3节相同的三层裁决打分逻辑 # 此处省略具体实现细节 result { duplicate: False, link: None, priority: medium, score: 60, signals: [sqli_hit, core_component], reason: SQLi命中核心组件但缺少PoC } return result if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--input, typestr, requiredTrue) args parser.parse_args() report json.loads(args.input) print(json.dumps(evaluate(report)))然后在 AI 助手的配置里注册这条工具路径告诉它当收到漏洞报告相关问题时若需要去重、打分或优先级判断执行 python3 /path/to/jev_cli.py --input 完整报告JSON 并把输出中的 priority、signals、reason 字段作为最终结论的依据。这一步的价值在于把 AI 从会看报告变成会调用看报告的专业工具。Claude Code 负责理解上下文、定位代码Jev 负责给出确定性的优先级结论。3.4 路径三用输出约束保住结论的可追溯性接入过程中最头疼的问题不是模型不会答而是答得太自由。同一个漏洞这次问它返回五行字下次问它返回两段小作文格式不一致导致下游没法自动处理。我最终在两边都加了严格输出约束要求以固定结构返回{ jev_priority: critical, jev_score: 87, signals_identified: [sqli_hit, core_component, has_poc], duplicate_info: {is_dup: false, related_report: null}, fix_suggestions: [ { file: api/gateway/query_handler.py, line: 128, issue: 拼接SQL查询, suggestion: 改用参数化查询修复参考... } ], risks_remaining: 身份认证绕过仍需人工确认 }为了让它们稳定产出这种 JSON我在系统指令里给了正向例并且写了禁止自由创作字段名未识别信号写 null这类硬约束。实测下来输出格式的稳定性从最初的六成提升到了九成以上。这里要提醒一句JSON 输出并不代表结论可信它只是让结论可用。真正判断漏洞真假仍然要靠你对代码逻辑的审查AI 只是在帮你定位和起草。4. 实践验证人、Jev、JevAI 助手三者的对比结果4.1 验证方法与样本选择接完三条路径之后我做了为期两周的并行测试。方法并不复杂每天随机抽 8 份新报告让三套方案分别处理——纯人工初审、Jev 独立初筛、Jev 初筛后接 Claude Code / Codex 生成修复建议。然后把结果交给另一位负责复核的同事做盲评。评估口径有两个一是初审阶段的准确率看该保送的有没有漏、该放行的有没有错拦二是处置效率看从报告进来到给出可行修复方案的总耗时。4.2 关键数据效率提升了但准确率有讲究两周下来累积了 96 份样本核心对比如下方案平均耗时/份高风险召回率误拦率修复方案可用度纯人工初审 人工修复建议约 9 分钟92%0%高Jev 初筛 人工修复建议约 3 分钟97%3.1%高Jev 初筛 Claude Code/Codex 修复建议约 2 分钟96%3.1%中偏高值得注意几个点。Jev 的高风险召回率甚至比纯人工高一些原因是规则不会疲劳不会在连续第 30 份报告时对 A5 这种 SSRF 报告视而不见。但它的误拦率不是零——3.1% 的低风险被错误提为优先。这类误判集中在提交者自带标签和描述矛盾的场景比如有人把一份明显是信息泄露的报标签成 RCEJev 对描述做关键词提取时被带偏了。AI 助手这一列提升最快的是修复建议的产出速度。开发同事反馈以前拿到高危报告后要自己翻代码现在 Claude Code 能直接指出疑似问题代码行并给出改法。不过可用度从高降到中偏高意味着 AI 给出的建议仍然需要人确认不能直接合入。4.3 边界案例人和机器都会失手的地方我不是想营造JevAI 完美无缺的印象恰恰相反边界情况才是这套流程真正需要打磨的地方。第一类是需要环境认证的漏洞。某次收到一份业务逻辑越权报告描述写了完整步骤但漏洞复现依赖特定账号的角色权限。Jev 的规则看到越权核心组件详细描述直接给了高分Claude Code 也给出了修复方案。可复核同事发现该场景在线上环境需要双因素认证才能触达实际风险面比报告暗示的小得多。这提示我初筛分数应该补充前置条件复杂度这个信号条件越多紧急度要适当下调。第二类是非常规的数据语义型漏洞。比如一份报告说导出文件里包含了其他用户字段既没有攻击向量也没定义漏洞类型。Jev 对这类语义型报告几乎无能为力因为它的规则本质是关键词匹配。这时候只能靠人去读AI 助手也只能在拿到全部业务逻辑后才能帮上忙。第三类是误报被规则放大的情况。之前提到的误拦率统计里有一份来自协作方的报告标题写着疑似 SSRF描述全是建议排查之类的客气话。Jev 看到 SSRF 就给了 30核心组件又 25总分直接拉高。后来我在规则库里加了一条标题带疑似或建议排查权重减半。这类调整只能靠长期观察误报积累没法一步到位。5. 持续维护 Jev 的经验与踩过的坑5.1 规则库要像养植物一样持续迭代Jev 上线第一周效果不错第二周就开始暴露出问题新来的扫描器升级了告警格式报表里的漏洞类型关键词换了说法指纹系统一时间全打不中。教训是规则库不是一次写完就完事的东西。我现在保持两周一次的迭代节奏每次把误报样本和漏报样本各整理一批逐条看是哪个信号缺了、哪个权重不对。规则表用 JSON 管理支持热更新不用重新部署服务。字段大概是{ vuln_types: { rce: {keywords: [rce, remote code execution, 命令执行], weight: 30}, sqli: {keywords: [sql注入, sqli, sql injection], weight: 30} }, core_components: [api-gateway, auth-service, payment-core], weak_signals: [无法复现, 建议排查, 仅供测试, 疑似], white_components: [docs-site, static-cdn, internal-tool] }改完规则之后我会拿过去两周的报告回放一遍比较新旧输出差异防止修了 A 误报、引出 B 漏报。5.2 与 AI 助手配合时的接口稳定性是第一优先级用 JSON 作为 Jev 与 AI 助手之间接口之后我在版控里加了一条规则任何字段变动都要同步修改提示词中的 schema 示例否则模型很可能按旧格式输出下游解析就崩了。实际操作中踩过一个很典型的坑某次给signals_identified加了一个auth_condition_missing枚举值忘了更新 Claude Code 的提示词结果它多次返回了不存在的字段名导致修复建议的自动归类失败。所以我现在把 schema 文件单独放在项目里提示词通过读取 schema 文件动态生成从根上杜绝手工同步遗漏。5.3 关于安全的边界哪些事别交给工具做了这么多自动化我想说一个反向的体会。Jev 可以筛掉 80% 的噪音Claude Code 和 Codex 可以大幅提速修复建议的产出但有几件事我始终保留人工环节漏洞真实性终审规则和模型都只是信号评估不是证据认证。只有人通过代码审查或复现确认之后报告才算数。对外漏洞通报涉及跨团队披露的报告措辞和等级判定必须人工把关避免乌龙。敏感数据相关的报告如果漏洞描述中自带真实账号、token 或用户数据Jev 现在会把它单独隔离到加密目录不让 AI 助手的上下文直接接触。这既是为了数据安全也是为了避免大模型把敏感信息带进更多对话上下文中。让我最后再给一句实操建议这套方案里面的规则、权重、接入方法没有任何一条需要特殊硬件或商业授权一两天时间就能复现。先别急着堆规则从只筛重复和明显误报做起跑两周拿到真实误报样本再迭代。自动化是滚雪球第一版越朴素后面越容易改得顺手。
阅读完成 · 觉得有帮助？
