去年秋天，漏洞一家做跨境电商的扫描客户找我救火。他们的和渗优惠券系统被人用脚本刷了十二万张，损失接近七位数。透性事后复盘，测试CTO 说半年前做过一次漏洞扫描，开展报告显示“无高危风险”。漏洞我打开那份报告一看，扫描扫描器只测了登录页和几个静态页面，和渗而真正出问题的透性 `/api/v1/coupon/redeem` 接口根本没在扫描范围内。这就是测试典型的把漏洞扫描当成了安全工作的全部。

漏洞扫描本质上是开展个自动化比对工具。它拿着已知漏洞库去匹配目标系统的漏洞指纹——比如检测到 Apache 2.4.49 就报 CVE-2021-41773 路径穿越。快，扫描便宜，和渗能覆盖大量资产。但它的盲区同样明显：业务逻辑漏洞、权限绕过、竞态条件，这些它根本看不懂。扫描器不会知道“用户 A 把订单 ID 改成用户 B 的就能查看他人收货地址”这种问题，因为这不是代码层面的 bug，是设计层面的缺陷。

渗透测试不一样。它模拟真实攻击者的思路，手工去验证漏洞是否可利用。我见过一个案例：扫描器报告某后台“存在弱密码风险”，但没当回事。渗透测试时，测试人员用 `admin/admin123` 直接登进去了，然后在文件上传功能里传了个 JSP 木马，十分钟拿到服务器权限。扫描器说的“弱密码风险”和渗透测试证明的“可完全控制服务器”，中间隔着一整个利用链。

那是不是只做渗透测试就够了？也不对。渗透测试受限于测试人员的时间、经验和覆盖范围。一个中等规模的 Web 应用，手工测一遍至少三到五天。资产多的时候，你不可能每个 IP 都手工测。漏洞扫描能在几小时内扫完几千个 IP，先把已知漏洞的底子摸清楚。我的习惯是：扫描器跑第一轮，把低垂的果实摘掉——比如没打补丁的 Struts2、默认口令的 Redis。然后渗透测试针对核心业务模块深入打点。

具体怎么开展？我拿一个电商项目举例。扫描阶段用 Nessus 扫服务器层，用 AWVS 扫 Web 层，同时跑一遍目录扫描和端口扫描。拿到结果后先人工过滤误报——扫描器经常把 404 页面报成“目录遍历”。然后进入渗透测试：先测认证模块，看有没有验证码绕过、短信轰炸、密码重置逻辑缺陷。再测订单模块，尝试越权查看他人订单、修改价格、重复提交优惠券。最后测支付回调，看能不能伪造支付成功通知。每一步都要截图、录屏、保存请求响应。

有个细节很多人忽略：测试账号的权限要覆盖所有角色。普通用户、VIP 用户、商家、管理员，每个角色都得测一遍。我遇到过只测了普通用户就收工的团队，结果管理员后台的某个接口没做权限校验，普通用户直接访问就能拿到全量用户数据。

报告怎么写也有讲究。别堆一堆 CVSS 评分就完事。业务方看不懂“CVSS 9.8”，但看得懂“攻击者可以零成本刷走你所有优惠券”。每个漏洞都要写清楚：怎么复现、影响是什么、修复建议具体到代码或配置层面。比如“在 `/api/coupon/redeem` 接口增加用户维度限流，同一用户每秒最多请求一次”，而不是“建议加强接口安全”。

最后说个现实问题：很多公司做完渗透测试，报告往文件夹里一扔就完了。漏洞修复没人跟进，三个月后同样的漏洞还在。我的做法是测完一周后主动找开发团队过一遍修复进度，高危漏洞必须看到修复后的验证截图才算闭环。安全这事，测出来只是开始，改掉才算数。