转转自建devops平台建设历程之静态代码扫描实践

简介
静态代码扫描的意义
整体构成
静态扫描流程：
整体交互：
其他-人员权限：
规则挑选和推广
步骤
存在问题
总结

简介
在2017年年底转转自建的devops平台beetle上线之后，参考业内公司的建设模型，转转开始了自己的devops工具域的建设。静态代码扫描是最早开始的一个能力之一。下面详细介绍一下，在转转的具体实践。
静态代码扫描的意义
静态扫描是一种软件安全分析方法，它通过检查源代码或二进制文件的静态特征，识别潜在的安全漏洞和编码错误。
可以根据配置好的规则，扫描代码中的安全问题、语法错误、潜在逻辑错误、代码风格等方面的问题。如跨站点脚本（XSS）、SQL注入等、空指针引用、未初始化变量等、命名规则等 。
能在开发测试流程中，帮助开发测试人员在代码初期发现并修复这些问题，减少问题出现概率。提高后续质量。
对于转转来讲，它是一种，持续的可重复的低成本测试兜底策略。在转转开发自测需求数量占比70%左右的场景中，这种可重复的，低成本的兜底策略是非常重要的。接下来介绍一下，在转转的具体实践。
整体构成

静态扫描整体构成
流水线管理：使用转转的CICD流程工具，内部叫beetle，是一款自研的轻量级平台。
扫描流程：使用社区版的sonarQube进行核心功能管理。使用jenkins进行扫描任务的调度，调度到可用的扫描机器上。
流程，编译时异步触发，在开发测试过程中，进行展示/拦截。在部署沙箱的时候强制拦截。保证增量问题都被修改。
静态扫描流程：

静态扫描流程
触发时机：在分支编译时，根据分支名自动创建jenkins的sonar编译任务，如果任务已存在，则直接分析。每次手动编译或者自动都会触发一次静态扫描。
扫描完成：jenkins任务扫描完成后，会上报结果到内部soanrQube平台，sonar会在后台运行分析线程。分析完成后，结果会在sonarQube平台上展示。
增量计算：由于历史原因，很多服务有很多存量的静态问题，在一次需求的分支开发中，无法要求开发同学将存量的全部问题都修改完，成本太高，会直接导致大家不愿意使用。所以只要求拦截分支修改带来的增量问题。要求增量问题为0。增量计算方式为：获取当前分支的扫描结果，获取master分支的扫描结果。取差集。

两种增量计算方案
增量计算，我们采用过两种方案
获取开发分支和master分支的静态扫描结果。做差集（目前在用）。
获取开发分支静态扫描结果，获取分支变更代码行号，更具行号进行匹配。方案2使用了非常长的时间，直到业务开始推进存量bug清零时发现问题。如：修改代码块A，导致接下来的代码块B（代码未变更）被静态扫描出问题。使用代码diff的方式，会有误差。
整体交互：
流水线中展示

流水线中展示
按需配置

按需配置
其他-人员权限：

人员权限
sonarQube默认是账号密码登录，在公司内部如果使用这种方式，无疑成本是很高的。同时也不方便权限的控制。
人员基本信息：sonarQube配置Ldap，获取基础的人员账号信息。
sso登录：参考sonar-auth-gitlab-plugin和gitlab交互的方式，修改了部分插件的代码，认证服务改为转转内部服务，实现OAuth认证，实现单点登录。（没有直接使用gitlab做sso登录是因为gitlab版本较低，不支持企业微信sso登录的相关配置）
权限同步：由于sonarQube平台能查看到工程的源码，基于这点不能开放全部的权限给所有用户，需要将源码和分支的权限同步到sonarQube中。在编译的过程中，通过soanr的api将开发工程对应的组成员，工程成员和分支人员同步到sonarQube平台。实现权限的限制和同步。
以上几个部分，介绍了静态扫描在转转CICD流程中是如何实现和集成。下面将介绍下具体在业务推广中的经验。
规则挑选和推广
静态代码扫描的意义开发和测试同学本身都是认可的，是一种静态的提前发现问题的手段，对于开发和测试流程来讲，不会增加明显的成本。
步骤
首先和开发测试各个leader达成共识。转转通过技术委员会，进行这个事情的同步，做到各个部门认同。
其次是规则的挑选，sonar的规则集有很多，有自带的，有findbugs，有p3c。使用非官方规则集越多，规则越多，扫描速度越慢。多不见得就好，规则到，问题多，对用户的干扰也大。
这部分，由开发leader共同挑选扫描的规则。保留核心规则。
然后将整个流程集成到CICD流水线中，做到用户不需要感知具体的操作，只需要关心扫描出来的增量结果。
最后根据业务的反馈和发现的线上问题不断的进行规则的增减。

推广流程
存在问题
sonarQube使用的社区版，扫描任务完成后，sonarQube要对扫描结果进行分析，后台分析线程只有一个。如果单个工程的分析时间过长，极易导致后台积压，阻断流程。
对于后端工程，转转分析均值在10s左右，并行分析量还有很大的空间，没有积压的情况。对于代码量大的工程，比如app工程，分析时间在4分钟左右，很容易造成积压。但是由于app编译的特性，编译耗时长，编译频次低，转转采用了单独搭建了一套sonar系统，将app和后端工程隔离，解决了这个问题。
总结
目前装转转的后端工程已经强制接入了增量问题拦截。静态扫描和代码覆盖率(动态)两个工具已经成为转转开发测试流程中两个非常重要的兜底工具。尤其是在开发自测流程中，能有效的避免一些低级的共性的问题。
关于作者 陈秋，转转工程效率负责人，主要负责配置管理和devops体系建设。欢迎大家留言、交流互相学习。