恶意代码检测只看成功页面会产生什么选择偏差
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eedfcafa284b.html
📄
恶意代码检测只看成功页面会产生什么选择偏差
只看成功页面，等于只用“已放行、已返回正常内容”的样本去评估检测效果，会系统性低估漏报和绕过。更实际的做法是：在没有完整日志或权限时，先固定一组“被拒绝或被拦截”的样本做对照，再看两类样本的判定依据是否一致。若两者依据不同，成功页面上的低告警率不能推出检测规则有效。
矛盾现象：成功页面很干净，告警却集中在别处
常见情形是：抽查若干正常返回的页面，脚本、外链、表单都符合预期，于是判断“检测没有问题”。但同一时间，拦截日志或用户反馈里出现的可疑样本，往往落在被拒绝、超时、跳转或需要登录的路径上。这两组观察并不矛盾，它们来自不同的抽样入口。
如果只统计成功页面，分母天然排除了检测已经拦下的对象。剩下的样本之所以“干净”，可能只是因为它们本来就不含可疑特征，而不是因为规则识别得准。要判断偏差有多大，需要知道被排除的那部分有多少、长什么样。
两种解释：规则有效，还是样本被筛掉了
对“成功页面告警少”这一现象，至少有两种成立条件不同的解释。
- 解释一：检测确实有效。成立条件是，被拦截样本与成功样本来自同一批请求，且拦截依据可复核，例如命中明确的特征串、可疑域名或异常编码。此时成功页面干净，是规则在入口处起作用的结果。
- 解释二：选择偏差。成立条件是，成功页面只是全部请求的一个子集，而被排除的部分恰好是高风险部分，比如需要鉴权、动态渲染、跨域跳转的页面。此时低告警率反映的是样本构成，不是检测能力。
两种解释都会表现为“成功页面看起来正常”，区别在于被排除样本的处置记录是否存在、是否可追溯。
区分两种解释的证据：对照被拦截样本的判定依据
能区分上述解释的证据，不是成功页面的数量，而是两类样本的判定依据是否同源。可以检查三点：
- 被拦截样本是否保留了原始请求特征，例如完整 URL、参数、响应片段或命中规则编号。
- 成功样本与被拦截样本是否经过同一套判定流程，而不是一个走静态扫描、另一个走人工白名单。
- 是否存在“未判定”的中间状态，例如超时、解析失败、跳过扫描。这类样本既不在成功集合，也不在拦截集合，最容易被忽略。
如果被拦截样本只有计数、没有特征，就无法确认它们和成功样本的差异来自检测规则还是访问来源。此时只能得出“两类样本处置路径不同”，不能推出规则覆盖率或漏报率。
缺少完整数据时的最小动作
在没有全量日志或后台权限的情况下，仍可执行一个最小动作：选取一段时间内可获取的成功页面清单，同时记录同一时间段内被拒绝、超时或跳过扫描的请求数量与类型。若后者无法获取，就明确标注“被排除样本未知”，而不是用成功页面的结果代替整体结论。
这个动作的结果会直接影响下一步：如果被排除样本数量可观且类型集中，应先补齐这部分样本的特征记录，再评估检测效果；如果被排除样本极少且类型分散，成功页面的观察才具备一定的参考价值。无论哪种情况，都不能仅凭成功页面的告警数量断言检测规则有效或无效。
一个假设例子：两组样本的对照方法
假设某次抽查中，成功页面共 200 个，其中触发告警的为 2 个；同期被拦截请求为 50 个，但只记录了总数，没有记录命中特征。此时不能计算漏报率，因为被拦截样本的判定依据缺失。可做的是：先对这 50 个请求补记类型，例如是命中特征串、域名黑名单，还是仅因超时被拒。补记后若发现其中多数命中同一特征，而成功页面中不含该特征，说明两类样本的差异可能来自入口筛选；若补记后发现拦截依据与成功页面的扫描依据一致，则成功页面的低告警才更可能反映真实分布。这个例子只说明比较方法，数字用于区分样本构成，不代表任何实际检测效果。
