开发阶段就开始扫描，别等到上线不少团队都是直至项目将近上线之际才记起要去做代码漏洞扫描，于此刻发觉问题，修复成本颇高得令人咋舌。代码漏洞扫描实际价值在于前置，于撰写代码的期间便将其融入到开发流程当中。我见识过诸多项目，上线之前扫描出大量高危漏洞，结果因要赶工期，仅修复表面问题，底层风险全然未动。
切实起作用的做法是使扫描工具对接版本控制系统，每当代码提交或者合并请求时便自动触发一回扫描。例如运用SonarQube或者GitLab自带的SAST功能，去检测常见的安全缺陷。进而每次修改代码时都能够立刻知晓有无引入新的漏洞，而非到最后进行统一扫描。我记得存在一个电商平台，在早期开发阶段坚持于每次合并之前开展扫描，结果上线之后几乎未曾出现过安全事件，这便是前置扫描所具备的益处。
当然，扫描并非跑一趟就结束，代码会发生变化，漏洞库同样在更新，先前扫描出的问题或许因新依赖的引入再次出现，所以扫描需做成持续的进程，每周抑或每次大版本更新都需重新运行一回。
代码漏洞扫描工具一般会输出数量众多的问题，这些问题按照从超高危险等级到超低危险等级的顺序排列得明明白白。不过实际情况是，团队没办法一下子把所有问题都修复完成，必须要有一个优先顺序。对于那些低危险等级的误报问题或者仅仅在非常极端的条件下才会触发的问题，可以把它们往后搁置。而真正需要密切关注的是那些具有高危险等级、能够通过远程方式加以利用、并且会对核心业务逻辑产生影响的漏洞。
我常常给出依照漏洞的可供利用的性质以及业务所产生的影响来进行排序的建议。举例言之，存在一个SQL注入漏洞，要是出现在用户登录的接口之处，那么这便是高危之中的高危情形，必然得马上修复。然而要是属于低危的信息泄露状况，所暴露的仅仅是非敏感的字段，并且仅仅在特定的日志里出现，如此便能够排在较后的位置。
另一种常见的情形是，扫描工具汇报了诸多第三方依赖的漏洞，这类问题处理时要格外谨慎，直接升级版本或许会引入不兼容的变更，致使功能出现问题，更好的举措是先查看这个依赖是否真的被运用到了，有无替代的方案，要是确实需要使用，再评估漏洞的实际状况，有些CVE可能仅仅是理论风险，实际利用条件严苛，暂时能够接受。
确实，自动化扫描工具能够覆盖大部分常见漏洞，像XSS、CSRF、SQL注入这些。然而，工具终归存在局限，例如业务逻辑漏洞、权限绕过这类需要理解业务场景的问题，扫描工具基本上没办法应对。我碰到过不少案例，扫描报告显示全绿，可是安全测试一测就暴露出严重问题，问题在于业务逻辑设计存在缺陷上。
是以靠谱之举措乃工具扫描与人工代码评审相结合，扫描工具司职抓取常规问题，人工评审则致力于寻觅工具所无法察觉之深层缺陷，评审之际可着重留意权限控制、数据校验逻辑、加密方式诸多方面，尤其是关乎支付、用户数据、权限管理等核心模块，务须有人逐行予以审视。
此外，扫描工具所呈现的结果并非全然正确无误。误报这种情况属于常态，存在一些扫描规则过于严苛，会将正常的书写方式标记为漏洞。此时就需要进行人工判断，若确定属于误报，可以在工具内对其标记为忽略，然而必须备注好原因，以此防止下次扫描时再次出现。
智云检测是具备正规软件测评资质的第三方软件检测机构，专业高效出具第三方软件测试报告。
