如何验证靶场的隔离边界?

隔离靶场的“隔离”不能由部署形态推定。即使验证任务运行在 Docker 容器中，也必须通过可观察证据确认：靶场是否能接触宿主机、是否能访问非预期网络、是否会泄露提交代码和凭据，以及任务结束后残留是否可控。验证对象应是自有或已获书面授权的代码仓库，测试过程本身也要限定在授权范围内。

先验证边界，而不是先验证漏洞

第一项是权限与宿主机边界。检查验证服务是否以最小权限运行，是否启用了不必要的特权，是否挂载了宿主机目录。尤其要重点核查 Docker socket；如果后端容器直接持有宿主机的 /var/run/docker.sock，容器一旦被验证代码影响，风险面会显著扩大。宿主机目录应尽量不挂载，确有必要时也应采用只读和最小范围配置。验证结果不能只记录“容器启动成功”，还要记录任务实际拥有的权限和可访问资源。

第二项是网络边界。理想状态下，验证容器对外无连接，或只能访问明确受控的内部服务。对于会执行 PoC 的场景，应观察其出站请求是否被限制，并核对请求目标、响应内容和放行范围。靶场内出现“服务可达”或“端口开放”，只能说明链路存在，不能直接证明漏洞成立，更不能把它当作越界成功的证据。

第三项是数据边界。使用不含敏感信息的测试仓库完成首轮试运行，检查代码、配置文件、密钥和数据库连接串是否进入日志或 PostgreSQL，任务结束后能否清除临时文件、容器和不必要的记录。验证报告应保留足以复核的结论与证据，但不应长期保存无关敏感内容。

用证据证明边界有效

一次合格的边界验证，应同时留下配置证据、运行过程证据和清理证据：前者说明权限、挂载和网络策略，后者说明实际请求与访问结果，最后一项确认容器、代码副本和凭据残留已被处理。若发现网络未限制、宿主机资源可访问或敏感数据在日志中回显，应先修正隔离配置，再进行漏洞复现。只有当“能访问什么、不能访问什么、任务结束后留下什么”都能被复核，靶场的隔离边界才不是口头承诺，而是可验证的安全属性。