把收集变成流水线

单站点测试不需要自动化，手工就够。需要自动化的是两种情况：资产多到手工看不过来，或者同一批资产要定期重测。

一条可用的流水线

读入域名列表
  → 抓首页 HTML
  → 提取 <script src> 与页面里的接口路径
  → 并发下载 JS（只取前 100KB）
  → 特征检测：框架指纹、版本号、sourceMappingURL
  → 输出 CSV：域名 / JS 地址 / 框架 / 版本 / 是否有 map

关键在最后一步的「是否有 map」。有 .map 的站，基本等于把源码给了你——这条在 Webpack 与源码泄露里展开。

并发数别开太大。五个线程跑几百个域名，已经足够；开到五十，一半请求会被丢，还得重跑。

自动化解决什么，不解决什么

它解决的是「重复劳动」：抓页面、提链接、拼 URL、判断有没有某个特征。这些动作规则明确，机器比人快，也比人稳。

它不解决的是「该看哪里」。扫描器告诉你 a.example.com 用了 Spring Boot 2.3，剩下的判断——这个版本有没有已知漏洞、这个漏洞在当前配置下能不能打、打了会不会影响业务——全是人的事。

所以自动化跑完之后，人的工作量不会减少，只是从「找东西」变成「判断东西」。这个转变是好事，但很多人卡在这里：拿到一张几百行的表，不知道从哪看起。

排序比数量重要

一张 500 行的资产表，价值不如一张 20 行的。

我的排序习惯：

1. 有登录口的排在前面。登录口意味着有账号体系，有账号体系就有越权、爆破、逻辑漏洞。
2. 版本号明确的排在前面。知道版本就能查 CVE，不知道就只能盲测。
3. 有 .map、.git、接口文档的排在前面。源码泄露是最快的突破口。
4. 测试环境、开发环境排在前面。它们的防护通常比生产弱一个档次。
5. 剩下的一律往后放，包括所有「只有 200 状态码的空页面」。

定期重测

资产表不是一次性的。新上线的子域、新部署的接口、改过的版本，都会让上一次的结论失效。

重测不需要全量。跑一遍存活探测和指纹识别，和上次的结果 diff——变化的部分才是这次要看的。这和网络监控里「变化比快照更有信息量」是同一个道理。

一个提醒

自动化脚本里的目标列表，是从客户给的资产清单来的，不是自己扫出来的。

这条听起来废话，但真有人拿全网测绘的结果直接跑。跑的是别人的站，出事的时候没有任何东西能证明你在范围内。

参考

• 《自动化进行目标资产探测和安全漏洞扫描》，公众号存档
• 《Webpack 漏洞利用：从 .map 文件到敏感接口》，公众号 渗透安全HackTwo