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

文摘   2024-10-25 12:01   重庆  

来源|转转QA

作者|陈秋


以下为作者观点:


简介

在2017年年底转转自建的devops平台beetle上线之后,参考业内公司的建设模型,转转开始了自己的devops工具域的建设。静态代码扫描是最早开始的一个能力之一。下面详细介绍一下,在转转的具体实践。

静态代码扫描的意义

静态扫描是一种软件安全分析方法,它通过检查源代码或二进制文件的静态特征,识别潜在的安全漏洞和编码错误。

可以根据配置好的规则,扫描代码中的安全问题、语法错误、潜在逻辑错误、代码风格等方面的问题。如跨站点脚本(XSS)、SQL注入等、空指针引用、未初始化变量等、命名规则等 。

能在开发测试流程中,帮助开发测试人员在代码初期发现并修复这些问题,减少问题出现概率。提高后续质量。

对于转转来讲,它是一种,持续的可重复的低成本测试兜底策略。在转转开发自测需求数量占比70%左右的场景中,这种可重复的,低成本的兜底策略是非常重要的。接下来介绍一下,在转转的具体实践。

整体构成

静态扫描整体构成

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

静态扫描流程:

静态扫描流程

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

两种增量计算方案

增量计算,我们采用过两种方案

  1. 获取开发分支和master分支的静态扫描结果。做差集(目前在用)。
  2. 获取开发分支静态扫描结果,获取分支变更代码行号,更具行号进行匹配。方案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流程中是如何实现和集成。下面将介绍下具体在业务推广中的经验。

规则挑选和推广

静态代码扫描的意义开发和测试同学本身都是认可的,是一种静态的提前发现问题的手段,对于开发和测试流程来讲,不会增加明显的成本。

步骤

  1. 首先和开发测试各个leader达成共识。转转通过技术委员会,进行这个事情的同步,做到各个部门认同。
  2. 其次是规则的挑选,sonar的规则集有很多,有自带的,有findbugs,有p3c。使用非官方规则集越多,规则越多,扫描速度越慢。多不见得就好,规则到,问题多,对用户的干扰也大。
    这部分,由开发leader共同挑选扫描的规则。保留核心规则。
  3. 然后将整个流程集成到CICD流水线中,做到用户不需要感知具体的操作,只需要关心扫描出来的增量结果。
  4. 最后根据业务的反馈和发现的线上问题不断的进行规则的增减。
推广流程


存在问题

sonarQube使用的社区版,扫描任务完成后,sonarQube要对扫描结果进行分析,后台分析线程只有一个。如果单个工程的分析时间过长,极易导致后台积压,阻断流程。

对于后端工程,转转分析均值在10s左右,并行分析量还有很大的空间,没有积压的情况。对于代码量大的工程,比如app工程,分析时间在4分钟左右,很容易造成积压。但是由于app编译的特性,编译耗时长,编译频次低,转转采用了单独搭建了一套sonar系统,将app和后端工程隔离,解决了这个问题。

总结

目前装转转的后端工程已经强制接入了增量问题拦截。静态扫描和代码覆盖率(动态)两个工具已经成为转转开发测试流程中两个非常重要的兜底工具。尤其是在开发自测流程中,能有效的避免一些低级的共性的问题。


关于作者 陈秋,转转工程效率负责人,主要负责配置管理和devops体系建设。欢迎大家留言、交流互相学习。






1.测试灵魂三问及解决方案

2.原生鸿蒙,真正独立!部分应用只有基础功能,原因是必须进行大量稳定性测试?

3.实践分享|QA工程师如何利用生成式AI提高QA任务的生产力

4.阿里云开源AI应用开发框架Spring AI Alibaba,帮助开发者快速构建AI应用

5.MTSC2024上海大会,现场录播视频

6.AI测试|自己搭一个AI Agent玩玩


TesterHome社区
测试之家(TesterHome)由一线测试工程师发起和运营的测试技术社区,社区主旨是公益、开源、分享、落地,紧跟前沿技术趋势,致力于推进软件质量保障与安全,是软件质量保障领域的风向标。我们的理念:Coding Share Show Cool
 最新文章