镜像漏洞扫描已成为常态，前端资产的安全巡检呢？

摘要：后端镜像有 Trivy、镜像仓库有漏洞扫描、依赖有 SCA——但页面里跑的第三方脚本、埋点 SDK、CDN 资源，很多团队几乎没有盘点过。本文讨论前端资产为什么成了安全巡检的盲区，以及如何建立一套可落地的前端资产巡检流程。

一个常见的对比：后端团队每周用 Trivy 扫镜像漏洞、依赖锁文件纳入 SCA 扫描、镜像仓库设置阻断策略；而前端这边，生产页面里加载着几十个第三方脚本——统计、广告、客服、埋点、地图——没人说得清哪些在用、谁加的、域名是否还可靠。镜像漏洞扫描已是常态，前端资产的安全巡检却基本是空白。

结论：前端资产（第三方脚本、CDN 资源、埋点 SDK）已成为供应链攻击的高发入口，2024 年 Polyfill.io 事件就是例证。巡检不必自建复杂平台：盘点资产 → 建立清单 → 检查风险 → 持续监控，四步即可起步，核心是"先知道页面里跑了什么"。

一、后端有 Trivy，前端为什么没有"Trivy"

后端资产扫描体系成熟的逻辑很清晰：镜像有固定清单（Dockerfile 可溯源）、依赖有锁文件（package-lock）、漏洞库有 CVE 映射，扫描器能做"资产清单 × 漏洞库"的匹配。而前端第三方脚本没有类似的确定性清单：

• 脚本来自 CDN 域名，可能随时被换内容（同一条 URL，不同时间返回不同代码）；
• 埋点/广告脚本经常由非技术同事通过 GTM 等工具直接添加，代码仓库里看不到；
• 脚本之间会互相加载（一个 SDK 拉另一个 SDK），实际运行的"资产"比 HTML 里写的 <script> 标签多得多。

所以前端巡检的第一步不是"扫漏洞"，而是"扫资产"——先回答页面里到底跑了什么。

二、前端资产的风险面有多大

先看一组量级数据。HTTP Archive《2025 Web Almanac》统计，全球超过 90% 的网页至少加载一个第三方资源；头部 1000 个站点桌面端第三方请求的中位数达到 129 个、移动端 106 个，全量数据集桌面端 83 个、移动端 79 个。这不是"一两个统计脚本"的量级，而是一张庞大的、动态变化的第三方资产网络。

风险不是理论上的。2024 年 6 月，知名 JavaScript 库服务 Polyfill.io 被曝注入恶意代码：其域名易主后被用于向移动端用户投放恶意跳转，安全公司 Sansec 在 6 月 25 日披露后，Cloudflare 于次日发布公告确认威胁并自动替换引用，注册商在 6 月 27 日封禁该域名——据 Sansec 统计，受影响站点超过 10 万个。攻击面有多大？软件供应链管理公司 Sonatype 在其《2024 年软件供应链现状报告》中给出更宏观的图景：过去一年恶意开源软件包数量同比增长 156%，累计识别超 70 万个。

Polyfill.io 这类事件的核心教训：一个你自己都不记得的第三方脚本，域名易主后就成了你网站的投毒入口。

第三方脚本供应链风险链条：网站引入第三方脚本 → 域名被收购易主 → 脚本注入恶意代码 → 浏览器执行恶意内容 → 用户数据与流量受损。链路中每一个环节都发生在你的监控视野之外。
 

第三方脚本供应链风险链条

三、前端资产安全巡检四步法

Step 1：盘点资产

用爬虫/浏览器自动化批量抓取站点关键页面，提取所有 <script>、<link>、iframe、图片请求，去重后形成"脚本 URL 清单"。注意覆盖：首页、登录页、支付页、活动页等不同模板，因为不同页面加载的第三方差异很大。

Step 2：建立清单

对每个脚本登记：域名、用途（统计/广告/客服/地图等）、引入方式（代码直引 or 标签管理器）、负责人、添加时间。这一步产出的"第三方资产台账"是后续所有检查的基础。

Step 3：检查风险

逐项核验：域名归属是否变更（WHOIS/历史记录）、是否启用 SRI（Subresource Integrity，子资源完整性校验）、是否使用 HTTPS、版本是否陈旧、脚本是否从 CDN 动态加载可变内容。

Step 4：持续监控

定期重跑盘点（建议每月或每发布周期），对比清单差异，新增脚本自动进入待审核队列；对高危域名（变更过归属、无 SRI、动态内容）设置告警。

前端资产安全巡检四步

四、巡检清单（可直接用）

踩坑记录：现象——某站点巡检发现一个"无人认领"的客服脚本域名已易主，但内容仍正常，团队一度认为虚惊一场。根因——域名易主后攻击者选择了"先潜伏后利用"策略，短时间内不投放恶意内容。排查证据——WHOIS 变更时间与脚本首次出现时间相差一年，且脚本内容哈希在易主后发生变化。修复方式——将该脚本替换为自托管版本并加 SRI，同时把"域名归属变更"设为自动告警项。经验：第三方脚本的安全巡检是持续性工作，不是一次盘点就结束——资产会变，归属会变，内容会变，监控必须跟着变。

FAQ

Q1：前端脚本也能被"扫描漏洞"吗？

A：能，但思路不同。后端扫的是"已知漏洞库匹配"，前端更关键是"资产盘点 + 归属核验 + 内容完整性"——因为第三方脚本的域名和内容都可能变化，漏洞库覆盖不了这种动态风险。

Q2：SRI 是什么？为什么能防投毒？

A：SRI（子资源完整性）是浏览器特性：在 <script> 标签里带上资源的哈希，浏览器校验不一致就拒绝执行。Polyfill.io 事件中，启用了 SRI 的站点即使引用原域名，恶意内容也无法执行。

Q3：前端资产巡检多久做一次？

A：推荐每个发布周期做一次差异扫描（新增脚本自动入审），季度做一次全量核验（域名归属、SRI 覆盖、废弃清理），高危域名变更可做实时监控。

Q4：没有安全团队的小公司怎么办？

A：四步法里前三步（盘点、建清单、查归属）用爬虫脚本 + 表格就能完成，一天内可出第一版台账；先把"未知资产"和"易主域名"两个高风险项清掉，收益立竿见影。

Q5：标签管理器（GTM 等）里的脚本怎么盘点？

A：GTM 容器本身就是一个第三方资产，先把容器加载的脚本 URL 导出来并入台账；同时给 GTM 配置变更审批，防止非技术同事无记录地添加新脚本。

总结

镜像扫描解决"后端依赖有什么漏洞"，前端巡检解决"页面里到底跑了什么、谁在控制它"。Polyfill.io 事件用 10 万个受影响站点证明了前端供应链风险的现实性。从一张资产台账开始，四步建立起前端巡检闭环，让每一个第三方脚本都"有名、有主、有校验、有监控"——这是镜像漏洞扫描之后，下一个值得补齐的安全基础设施。

参考资料：HTTP Archive《2025 Web Almanac（Third Parties 章节）》；
                  Cloudflare 官方博客《Automatically replacing polyfill.io links…》（2024-06-26）； 
                   Sansec 威胁研究披露（2024-06-25）；
                   Sonatype《2024 State of the Software Supply Chain》；
                    InfoQ 对 Polyfill.io 事件的报道（2024）。