上周三凌晨两点，网络我盯着 Nessus 扫描报告里那条“Apache Log4j RCE”告警，渗透手边咖啡凉了半杯。多久这已经是做次最好本月第三次对同一套边缘系统做渗透测试——距离上次全面评估才过了 11 天。客户安全负责人发来消息：“你们是网络不是太频繁了？预算扛不住。”我回他：“那你愿意赌这 11 天里没人偷偷种了内存马？渗透”
渗透测试不是体检，没有“一年一次”的多久万能公式。我见过金融客户每季度做一次黑盒，做次最好也见过创业公司上线前只跑一遍自动化扫描就敢开门。网络频率取决于三件事：你的渗透资产变化速度、威胁暴露面、多久以及上次测试后遗留的做次最好高危漏洞有没有真正闭环。去年给一家电商做复测，网络他们三个月前修了 SQL 注入，渗透结果新上的多久促销模块又把同样的参数拼进了订单查询接口。如果按“半年一次”的节奏，这个洞能活到双十一。
具体点说。互联网暴露面大的系统——比如对外 API、VPN 网关、邮件门户——我建议至少每季度做一次外部渗透。不是全量深挖，而是针对变更部分做增量测试。我们内部有个粗暴的指标：每 100 个新提交的代码分支，至少触发一次自动化 DAST 扫描加人工验证。上个月一个客户在 GitLab 合并请求里加了个调试接口，没鉴权，直接返回数据库连接串。从提交到被我们扫出来，中间隔了 6 小时。要是等半年一次的渗透，这 6 小时够黑产拖走三张表了。
内网渗透的频率更看“人”和“架构”。如果运维团队稳定、堡垒机日志全量留存、每月做一次权限复核，那内网横向测试可以放到半年一次。但要是你刚并购了一家公司，或者把开发测试环境接进了生产域，别犹豫，两周内安排一次。去年一个制造业客户，IT 和 OT 网络混用，我们做完内网渗透后建议他们隔离，他们拖了四个月。结果勒索软件从办公区一台未打补丁的打印服务器跳进了工控网，停产两天。那之后他们改成每两个月做一次内网假设突破测试。
合规驱动和风险驱动是两码事。等保要求“定期”渗透，没写具体天数。但 PCI DSS 明确要求每年一次外部、一次内部，且重大变更后必须重测。我见过最离谱的是一家持牌支付机构，每年 12 月请人做一次渗透，报告用来续牌照。平时开发随便推代码，WAF 规则半年没更新。这种“年更”渗透就是给审计看的，攻击者可不看日历。
我的实操建议：把渗透测试拆成三层。第一层是持续自动化——每次上线前跑 SAST 和依赖检查，每周对核心域名做一次轻量扫描，发现新端口或新路径就告警。第二层是季度人工——针对外部边界和关键业务逻辑做深度测试，重点验证权限绕过和支付篡改。第三层是事件驱动——出现重大漏洞披露（比如今年的 XZ 后门）、架构大改、或发生安全事件后，72 小时内启动专项渗透。这样一年下来，全量深度测试可能就两次，但覆盖密度比“一年一次大扫除”高得多。
别被“渗透测试”这四个字框住。很多时候，你需要的不是再雇一队人来打一遍，而是把上次报告里的中危漏洞真正修掉。我见过一个客户，连续三年渗透报告里都有同一个“未授权访问 Redis”的问题，每次都说“下个迭代修”。这种频率再高也是白花钱。反过来，如果你们研发团队能自己跑起 nuclei 模板，每天扫一遍已知 CVE，那外部渗透的频率可以降到半年一次——因为你已经把“已知”的风险消化在日常里了。
最后说个真事。某次攻防演练，蓝队抱怨“我们刚做过渗透，怎么还被拿下”。我看了他们的报告日期：演练前 9 个月。这 9 个月里他们上了微服务、换了网关、开了新端口。攻击队用的入口，恰好是渗透报告里没覆盖的那个新 API。所以别问“多久做一次最好”，问“我的系统上一次发生有意义的变化是什么时候”。那个时间点，就是你下一次渗透的起点。