转转自建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体系建设。欢迎大家留言、交流互相学习。

声明:文中观点不代表本站立场。本文传送门:http://eyangzhen.com/423092.html

联系我们
联系我们
分享本页
返回顶部