文章总结： 30天实测显示AI辅助SRC挖洞使有效漏洞从11个增至23个，通过率从35%提升至49%。AI在信息收集和报告撰写环节效率提升显著，但在业务逻辑漏洞判定和创造性攻击链构造上无法提供有效帮助，需人工判断业务上下文与攻击直觉。建议新手用AI做信息收集和报告生成，资深人员将节省时间用于业务理解和攻击链构造。 综合评分： 85 文章分类： 实战经验,src活动,ai安全,漏洞分析

AI辅助SRC挖洞30天：有效漏洞翻倍，但这两个环节AI帮不上忙

原创

klsec.com klsec.com

昆仑AI安全实验室

2026年9月23日 09:30 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

连续30天，我把AI嵌入了自己的SRC工作流。每一条测试记录、每一个漏洞、每一次误报，全部存档。

最终数据：有效漏洞从之前30天的11个提升到了23个，翻了一倍多。总提交量从31份涨到47份，但通过率从35%提升到了49%。

但同一套工具，有两个环节AI完全没有帮上忙。今天这篇文章把30天的原始数据、有效和无效的边界、以及那两个AI无能为力的环节，全部摊开。

30天实测数据：不吹不黑，原始账本

对比基准： 前30天（纯手工）vs 后30天（AI辅助）。两个周期我投入的时间基本一致，每天3-4小时，周末稍多。目标类型相似，都是授权范围内的企业级Web应用和SaaS平台。

| 指标 | 纯手工30天 | AI辅助30天 | 变化 | | — | — | — | — | | 有效漏洞数 | 11 | 23 | +109% | | 总提交数 | 31 | 47 | +52% | | 提交通过率 | 35% | 49% | +14pp | | 高危及以上占比 | 27% | 39% | +12pp | | 单目标平均耗时 | 4.2小时 | 2.8小时 | -33% | | 报告撰写耗时/份 | 55分钟 | 22分钟 | -60% | | 信息收集耗时/目标 | 65分钟 | 18分钟 | -72% |

通过率从35%提升到49%，核心原因不是AI找到了更多漏洞，而是AI帮我更快地排除了没漏洞的目标。以前一个目标要花两三个小时才能确认“这里确实没有可利用的点”，现在AI在信息收集和初筛阶段就能给出判断，我把时间集中到了真正有产出可能的目标上。

单目标平均耗时从4.2小时降到2.8小时，省下来的1.4小时，主要来自信息收集（省47分钟）和报告撰写（省33分钟）。这两个环节，恰好也是AI在30天里表现最稳定、误报率最低的环节。

AI真正省时间的两个环节：数据说话

环节一：信息收集——从65分钟到18分钟

这个环节的省时效果是最确定的。

以前测一个目标，信息收集流程是这样的：打开FOFA拉子域名，复制到txt，跑subfinder补充，等结果，整理存活列表，用httpx批量探测，导出结果，逐个看Title和指纹，把可疑的挑出来。60-90分钟是常态。

现在我把流程改成了AI辅助的信息收集。给它目标域名，AI自动执行：调FOFA API拉资产、调subfinder枚举子域、调httpx存活探测、从JS文件里提取API端点。我只需要等结果，然后做一轮人工筛选。18分钟是实测中位数。

| 操作 | 纯手工耗时 | AI辅助耗时 | 效率提升 | | — | — | — | — | | 子域名枚举 | 15分钟 | 3分钟 | 5x | | 端口扫描 | 10分钟 | 2分钟 | 5x | | 指纹识别 | 12分钟 | 2分钟 | 6x | | JS文件下载与提取 | 25分钟 | 8分钟 | 3.1x | | 结果整理与去重 | 13分钟 | 3分钟 | 4.3x | | 合计 | 75分钟 | 18分钟 | 4.2x |

有一个实际案例：某电商平台的JS bundle约18MB，200多个JS文件。以前手工翻找API端点，至少需要半天。这次我把所有JS文件喂给AI，Prompt是“提取所有API端点，包括HTTP方法、路径、参数名、是否携带认证头，以JSON格式返回”。AI在8分钟内输出了840个端点。我手工验证了前120个，准确率约96%，漏报3个。光这一个环节，就省了至少三个小时。

环节二：报告撰写——从55分钟到22分钟

这个环节的省时效果同样确定，而且通过率有明显提升。

以前写一份SRC报告，我需要把Burp的请求/响应截图整理好，手动写漏洞描述、复现步骤、影响分析、修复建议。55分钟是保守估计，遇到复杂的攻击链报告，超过一个半小时很常见。

现在我把报告撰写交给了AI。我把Burp的请求/响应文本、PoC命令、验证截图丢给它，Prompt大概是这样：“基于以下漏洞信息生成SRC报告。格式要求：结论先行，第一段写风险等级和业务影响；复现步骤逐条编号，含完整HTTP请求和响应；修复建议具体到代码层面。”

AI生成的初稿，我只需要改三处：把AI常用的“可能导致”改成确定性的“可导致”、把AI编造的CVSS评分改成真实值、把通用修复建议改成针对这个系统的具体方案。

报告质量也有提升。之前我提交的一份越权报告，审核回复是“复现步骤不够清晰”。现在AI生成的报告结构更规范，审核的反馈也少了。30天内提交的47份报告里，因“复现步骤不清”被退回的比例从之前的约15%降到了不到5%。

这两个环节，AI真的帮不上忙

环节一：业务逻辑漏洞的判定

这是30天里最明确的边界。AI无法判断“这个操作算不算越权”。

具体案例：我测一个SaaS平台，发现一个接口GET /api/v1/workspace/{id}/members，返回了成员列表。用Burp改了一下{id}，返回了另一个工作空间的成员信息。

我把请求和响应丢给AI，问它“这算不算越权”。AI回复：“该接口未验证用户对工作空间的所有权，可能存在水平越权。建议进一步测试。”

这个回答毫无价值。 因为问题的核心不是“接口有没有校验所有权”，而是“这个接口的设计是否允许这种访问”。有些系统的workspace/{id}本身就是设计为公开可读的，比如共享工作空间的成员列表。有些系统的{id}本身就是一个不可枚举的UUID，能拿到UUID本身就是一种权限。

这些判断需要理解业务模型。AI不知道这个平台的工作空间是“私有”还是“可共享”的，不知道{id}是顺序递增还是随机UUID，不知道返回的成员信息里有没有超出普通用户可见范围的内容。

30天里，我通过AI标记的“疑似越权”发现的有效漏洞是3个。但AI标记出来让我去手工验证的“疑似越权”是37个。命中率8%。剩下的34个，要么是设计如此，要么是数据范围完全在权限边界之内。

对比：AI在JS文件里提取API端点的准确率是96%，在报告生成上的可用率超过90%。但在“这个业务逻辑算不算漏洞”的判断上，AI的命中率不到10%。

这不是AI能力不够，是AI没有业务上下文。它不知道这个SaaS平台的定价体系，不知道这个电商平台的优惠券规则，不知道这个金融系统的风控逻辑。它只能看到“接口返回了数据”，但看不到“这个数据在设计上该不该被看到”。

一个佐证数据：CVE Bench的实测显示，AI在已知漏洞描述下的成功率约为25%，而自主发现漏洞的成功率仅为13%左右。AI更擅长“利用已知问题”，而不是“发现新问题”。

环节二：创造性攻击链构造

第二个AI帮不上忙的环节，是把多个“低危”发现串联成一条完整的攻击链。

30天里，我最有价值的一个漏洞链，是这样一个组合：

第一步，从JS文件里发现了一个硬编码的API Key，权限是只读。第二步，用这个Key调了一个文档导出接口，发现导出的文档URL里包含了另一个服务的内部域名。第三步，访问那个内部域名，发现它有一个未授权的调试端点，返回了数据库连接信息。

三个发现单独看都不算高危——只读Key是信息泄露（中危），内部域名是信息泄露（低危），调试端点未授权是低危。组合起来，是一条从边缘服务到核心数据库的完整攻击链，定级严重。

AI在第一步和第二步都有贡献——它帮我提取了API Key、帮我发现了文档导出接口。但第三步的串联判断，完全是人做的。AI看到调试端点返回了数据库连接信息，它的回复是“该端点可能泄露敏感信息，建议验证是否可连接数据库”。它不会主动去想“这个数据库连接信息，和前面那个API Key发现的是同一个系统的吗？这两个发现之间有没有逻辑关联？”

Penetrify的2026年AI渗透测试工具评测给出了类似的结论：2026年最具影响力的渗透测试发现，仍然来自人类创造力——支付流程绕过、多步授权链提权、云IAM策略链式利用。没有任何AI工具能可靠地找到这些。

pentest-tools.com在2026年6月对158名安全从业者的调查也印证了这一点：AI在漏洞扫描和发现阶段的使用率高达74.1%，但在漏洞利用和攻击链构建阶段的使用率骤降到36.7%。从业者们把AI放在“出错成本低”的环节，而在“出错成本高”的判断环节，仍然依赖人。

为什么这两个环节AI帮不上忙

这两个“帮不上忙”的环节，有一个共同的底层原因：AI没有“业务模型”，也没有“攻击者直觉”。

业务逻辑漏洞的判定，需要你理解“这个系统是怎么设计的”。一个电商平台的优惠券叠加规则、一个SaaS平台的多租户隔离模型、一个金融系统的风控引擎——这些业务模型不在代码里，在产品的设计文档里、在业务团队的脑子里、在真实的用户行为里。AI看得到代码，看不到业务。

创造性攻击链的构造，需要“攻击者直觉”——一种在看似无关的发现之间找到逻辑关联的能力。这种直觉来自大量的实战经验：你知道“只读Key”和“调试端点”之间可能存在什么联系，你知道“内部域名泄露”往往是通往核心资产的跳板。AI有知识，但没有这种“嗅觉”。

一个安全研究者的评价很准确：“AI在覆盖、假设生成和代码分析方面很快。它在影响评估、验证和判断可利用性方面很差。每一个模型都会夸大发现。研究者的判断力，是噪音和CVE之间唯一的区别。”

给不同阶段的你，几条实在建议

如果你是新手：

先用AI做信息收集和报告生成。这两个环节AI最稳，也最容易让你看到“AI确实有用”。但AI说“可能存在漏洞”的时候，你必须手工验证。它标出的每一个“高危”，你都要亲手确认。

如果你做了两三年：

用AI做批量初筛和报告生成，把你省下来的时间花在业务逻辑理解和攻击链构造上。这两个环节才是你的核心价值。AI能帮你更快地跑完流程，但跑完流程之后，真正能挖出高危漏洞的，是你对业务的理解和你串联发现的能力。

如果你在带团队：

把AI辅助的流程标准化，但明确标注边界。哪些环节用AI、用什么样的Prompt、输出格式是什么、谁来复核——写成SOP。同时明确告诉团队：AI标记的“疑似越权”不要直接写报告，必须手工验证业务逻辑；AI发现的“单个漏洞”不要直接提交，先看看能不能串联成攻击链。

写在最后

30天下来，我对AI在SRC挖洞里的定位有了清晰的认识。

AI是一个“覆盖工具”和“格式工具”。 它帮你覆盖更多的资产、更多的端点、更多的JS文件。它帮你把技术发现格式化成规范的报告。它不会累、不会烦、不会因为看了三小时JS就走神。

AI不是一个“判断工具”。 它不知道一个total字段从2变成34000意味着什么。它不知道一个只读API Key和一个调试端点之间可能存在什么关联。它不知道这个系统的业务逻辑允许什么、不允许什么。

有效漏洞翻倍，不是AI替你挖了洞。是AI帮你更快地跑完流程，让你有更多时间去做那些AI做不了的事——理解业务、构造攻击链、做判断。

那才是你真正该花时间的地方。

严正声明

本文所述AI辅助SRC挖洞的30天实测数据和案例，基于个人在SRC平台授权范围内的真实操作。所有案例均已脱敏处理。AI工具的使用应遵守各平台服务条款，不得将敏感数据上传至未经授权的第三方服务。漏洞挖掘必须在SRC平台明确授权的资产范围内进行。未授权测试属于违法行为。AI是工具，判断力是你的责任。

免责声明：

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

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

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

本文转载自：昆仑AI安全实验室 klsec.com klsec.com《AI辅助SRC挖洞30天：有效漏洞翻倍，但这两个环节AI帮不上忙》