在线网站安全检测，怎样记录改动前后的基线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fde873ed6d26.html
📄
在线网站安全检测，怎样记录改动前后的基线
记录改动前后的基线，核心是让每次检测都有可对照的版本：改动前保存一份可复现的检测配置与结果快照，改动后再用同一配置复测，把两次结果的差异逐项标注出来。基线不是一张截图，而是一组能重新跑出相同结论的资料。
先想清楚交付物：一份可对比的检测记录
从最终要交付的东西倒推，一份能用的基线记录至少包含四部分：检测范围（域名、子域、IP、端口、路径）、检测配置（扫描项、请求头、登录态、限速、时间窗口）、原始结果（报告文件、响应码、证书信息、告警清单）、差异说明（哪些变化是预期内的，哪些是异常）。
如果只留下一个结论“有风险”或“无风险”，改动后就无法判断差异来自代码变更、配置调整，还是检测环境本身变了。因此记录的对象是可复现的过程，而不是单次结论。
改动前：固定配置并保存可复现快照
改动前这一步做扎实，后面才有对照基础。建议按顺序执行：
- 确定检测目标清单，写明具体域名、IP 段和需要覆盖的路径，避免范围含糊。
- 固定检测配置：扫描深度、并发数、超时时间、User-Agent、是否携带 Cookie 或 Token，全部记下来。
- 保存原始输出：报告文件、HTTP 响应头、TLS 证书链、重定向链路，尽量保留原始文本而非截图。
- 记录检测时的环境：出口 IP、检测时间、目标侧是否有灰度或维护窗口。
- 给快照命名并归档，例如按日期和范围命名，保证改动后能取到同一份。
判断标准很简单：改动后换一个人，拿着这份记录能否跑出接近的结果。跑不出，说明配置记录不完整。
改动后：用同一配置复测并做差异比对
改动后复测时，最容易出错的是顺手改了扫描参数，导致差异无法归因。正确做法是保持配置不变，只让目标发生变化。
比对时按类别逐项看：
- 新增项：新出现的端口、路径、证书或告警，优先排查。
- 消失项：原来报出的问题不再出现，确认是修复了还是检测被拦截或超时。
- 状态变化：响应码、跳转目标、证书颁发者或有效期变化，往往是配置或部署改动引起。
- 无变化项：作为对照，说明检测环境稳定，差异可信。
如果同一现象出现多种解释，例如某个端口从开放变为关闭，可能是防火墙调整，也可能是服务下线，还可能是检测时网络抖动。此时不要直接下结论，先补一次复测或换出口 IP 验证，再写进差异说明。
责任分工与验收条件
基线记录要落到人。改动执行方负责说明改了什么、何时改的；检测执行方负责用固定配置复测并输出差异；复核方确认差异说明与证据一致。三方信息对不上时，以原始输出为准。
验收可以设成几条可检查的条件：改动前后各有一份完整快照；两次检测配置一致；差异清单逐条给出证据和判断；无法归因的项明确标记为待查，而不是含糊带过。满足这些条件，这份基线才算可用。
一个简化的记录示例
假设某次改动是把管理后台从 /admin 迁到 /manage。改动前快照记录：可访问路径包含 /admin，返回 200；改动后复测记录：/admin 返回 301 跳转到 /manage，/manage 返回 200。差异说明写“预期内的路径迁移，需确认旧路径跳转是否长期保留”。这是假设示例，用于说明记录格式，不代表真实项目结论。
下一步：选一个近期要改动的目标，按上面的清单先补一份改动前快照，再执行改动并复测，把差异说明写成可复核的文档。
