去年秋天，帮助一个做跨境电商的查找朋友半夜给我打电话。他的企业独立站突然被支付网关封了，理由是漏洞“存在未授权交易风险”。他查了两天没头绪，帮助最后发现是查找客服系统里一个上传接口没做文件类型校验——攻击者上传了一个伪装成图片的脚本，拿到了服务器权限，企业接着在后台偷偷跑了上千笔小额测试交易。漏洞这个漏洞本身不复杂，帮助但它藏得深，查找不在主站，企业在一个几乎没人维护的漏洞老旧子域名上。

找企业漏洞这件事，帮助很多人第一反应是查找扫描器跑一遍。工具当然有用，企业但真正要命的问题往往不在扫描器能覆盖的地方。我见过一个案例：某公司官网用的是最新版框架，WAF也配了，但他们的HR部门用了一个开源招聘系统，版本停留在三年前，默认管理员密码没改。攻击者没碰主站，直接从那个招聘系统进去，横向移动到内网，最后把客户数据库拖走了。扫描器不会告诉你“这个系统虽然在外网，但没人管”。

所以第一步不是扫，是理。把企业所有对外的资产列出来——域名、子域名、IP段、API端点、第三方托管页面、甚至员工在GitHub上泄露的测试环境地址。很多公司自己都说不清自己有多少个对外系统。我习惯用被动信息收集加少量主动探测，先画一张资产地图。这张图越完整，后面越省事。

资产理清之后，看配置。配置错误比代码漏洞更常见，也更致命。比如S3存储桶权限设成公开可写，比如Elasticsearch端口直接暴露在公网没设密码，比如Kubernetes的dashboard用默认令牌就能进。这些不需要什么高深技术，但造成的后果往往是全量数据泄露。有个做SaaS的客户，他们的测试环境数据库用了弱密码，里面恰好有一份三个月前的生产数据快照。攻击者没攻破生产环境，但拿到了几乎一样的数据。

代码层面的漏洞，得看业务逻辑。SQL注入、XSS这些老面孔依然存在，但真正难防的是逻辑漏洞。比如密码重置功能，验证码返回在HTTP响应里；比如优惠券系统，可以无限次叠加使用；比如订单接口，能把别人的订单ID遍历出来。这类问题扫描器基本扫不到，得靠手工测。我通常会挑几个关键流程——注册、登录、支付、找回密码——把每个请求都拦下来，改参数、换顺序、重放，看系统怎么反应。

还有一类容易被忽略的：人。不是社会工程学那种，而是企业内部人员无意中暴露的信息。比如技术博客里贴的报错截图带了内部IP，比如招聘JD里写了“熟悉内部自研框架X”，比如离职员工在知乎上吐槽“我们的鉴权就是摆设”。这些碎片拼起来，能省掉很多盲测时间。

找到漏洞之后，怎么报告也有讲究。别一上来就甩一堆高危漏洞列表，企业安全团队每天收几百封扫描报告，看不过来。挑最要命的那个，写清楚复现步骤、影响范围、修复建议，最好附上你验证时用的请求和响应。如果可能，给出一个临时缓解措施——比如先加个WAF规则挡住，再慢慢改代码。企业要的是能落地的东西，不是炫技。

最后说个观察：很多企业不是不知道有漏洞，是不知道哪个漏洞最紧急。资产太多，人力太少，修不过来。外部帮助的价值不在于发现多少个漏洞，而在于帮他们排优先级。一个能直接拿shell的未授权访问，比一百个需要用户交互的XSS重要得多。找漏洞的人得有点产品思维——站在对方角度想，这个洞被利用的概率有多大，后果有多严重，修起来要多久。想清楚这些，再开口。