去年有个客户找我，漏洞说他们的扫描试安全团队刚做完一轮漏洞扫描，报告里列了三百多个漏洞，和渗问我能不能帮忙“全部修掉”。透测我拿过报告翻了翻，漏洞发现其中两百多个是扫描试同一类问题——某台测试服务器上装了旧版OpenSSL，扫描器把每个调用到它的和渗服务都算了一遍。真正需要立刻处理的透测，不到十个。漏洞这件事挺典型：很多人把漏洞扫描当成了安全工作的扫描试全部，以为扫完修完就万事大吉。和渗
漏洞扫描本质上是透测个自动化匹配过程。工具拿着已知漏洞的漏洞特征库，去比对目标系统的扫描试版本号、配置项、和渗开放端口。它快，能覆盖大范围资产，适合做基线检查。但它的局限也很明显：只能发现已知问题，对逻辑漏洞、权限绕过、业务流缺陷基本无能为力。我见过一个电商系统，扫描报告全绿，结果我手动试了试订单接口，把价格参数从199改成-1，直接零元购。扫描器不会去猜这种业务逻辑。
渗透测试是另一回事。它更像模拟攻击，测试人员带着思路去尝试突破。工具只是辅助，核心是人的判断。比如看到登录页面，扫描器只会检查有没有SQL注入点、有没有弱密码；渗透测试人员会想：能不能枚举用户名？验证码能不能复用？密码重置流程有没有逻辑缺陷？去年我测一个后台，发现它的“忘记密码”功能在验证手机号后返回一个token，但token的生成规则是md5(手机号+固定盐)。我拿自己的手机号算出token，替换成管理员的手机号，直接重置了管理员密码。这种漏洞扫描器永远扫不出来。
两者不是替代关系，是互补的。扫描适合日常巡检，每周跑一次，看看有没有新暴露的服务、新出现的CVE。渗透测试适合关键节点，比如上线前、大版本更新后、或者发生安全事件后。我通常建议客户：扫描常态化，渗透按需做。但有个前提——扫描结果得有人工复核。很多团队直接把扫描器的原始报告丢给开发，开发一看三百个漏洞直接崩溃，最后随便修几个交差。正确做法是先过滤：区分误报、确认可利用性、按业务影响排优先级。
成本上差别也大。扫描工具一年几万到几十万不等，渗透测试按人天算，一个中等规模的Web系统，完整测下来至少五到十人天。小公司预算有限，可以先用开源扫描器（比如Nuclei、OpenVAS）做基础覆盖，关键系统再请人做渗透。别指望扫描器能替代渗透测试，也别觉得渗透测试一次就能解决所有问题——系统在变，攻击手法也在变。
最后说个观察：很多安全事件不是因为没做扫描或渗透，而是做了之后没人跟进。扫描报告躺在邮箱里，渗透报告锁在柜子里。工具和人都到位了，流程没闭环，等于白做。