新开发系统如何漏扫

新系统上线前漏扫，新开最怕的发系不是扫出漏洞，而是统何扫了个寂寞。我见过太多团队，漏扫把漏扫工具往CI流水线里一挂，新开绿勾一打，发系就以为安全了。统何结果上线第一周，漏扫被安全组用最基础的新开SQL注入打穿，原因很简单——扫描器根本没登录进系统后台。发系

漏扫的统何本质是模拟攻击者视角。攻击者不会只盯着登录页打，漏扫他们会翻接口文档、新开试未授权访问、发系猜弱口令进管理端。统何可很多漏扫配置只扫了公开页面，内页全靠爬虫硬闯，碰到JS渲染的SPA应用直接抓瞎。我去年审计过一套电商系统，扫描报告显示“零高危”，但手动用Burp Suite抓包，发现订单导出接口没做鉴权，任何人改个订单号就能下载全平台用户手机号。

所以第一步，你得让扫描器“看见”完整应用。登录态怎么处理？别用万能账号硬登，那会污染业务数据。正确做法是搭一套独立测试环境，灌入脱敏数据，然后给扫描器配一个专用测试账号，权限尽量接近管理员。如果系统有验证码或二次认证，得在测试环境关掉或者用固定验证码。这一步不做到位，后面全白费。

第二步，别光依赖商用扫描器。AWVS、Nessus这类工具确实强，但它们的规则库有滞后性，新出的漏洞类型往往要等几个月才更新。我习惯在漏扫流程里加一层“轻量级自研检测”——写几十行脚本，重点查三类问题：硬编码密钥是否泄露在JS文件里、敏感接口是否缺少限流、越权漏洞是否能用两个普通账号交叉验证。这层脚本不追求全面，但能补上商业工具的盲区。

第三步，看报告别只看CVSS分数。高危漏洞固然要修，但中低危里往往藏着真正的雷。比如一个“信息泄露”级别的漏洞，如果泄露的是内部API的加密盐值，那实际危害可能比某个“高危”的反射型XSS大得多。我习惯让开发团队在修复时写清楚“这个漏洞怎么被利用的”，写不出来就说明没真懂，修了也是白修。

还有个小细节，漏扫时间点别总放在上线前夜。新系统开发过程中，每两周就该跑一次轻量扫描。等所有功能都开发完了再扫，一堆漏洞扎堆出现，开发排期根本排不过来。我见过最离谱的项目，上线前三天扫出40个漏洞，最后只修了8个“必须修”的，剩下的带着上线，结果三个月后其中一个成了数据泄露的入口。

漏扫工具本身也会误报。有些扫描器把纯前端渲染的404页面当成目录遍历漏洞，把带“test”参数的接口当成SQL注入。处理误报要有耐心，但别直接忽略。我常用的办法是让扫描器把请求和响应都记录下来，人工抽查10%的告警，确认哪些是真实问题，哪些是工具抽风。这10%的抽查，往往能发现工具没报但确实存在的逻辑漏洞。

最后说句实在话。漏扫只是安全测试的一环，它替代不了代码审计和渗透测试。新系统如果涉及资金交易、用户隐私数据，花点钱请外部团队做一次真人渗透，比买十个扫描器都值。扫描器是筛子，人是网，漏网之鱼永远靠人抓。