目录
- 1. sonar安装
- 1.1 简介
- 1.1.1 客户端
- 1.1.2 sonar 版本区分
- 1.1.2.1 社区版
- 1.1.2.2 开发者版
- 1.1.2.3 企业版
- 1.2 安装部署
- 1.2.1 修改文件句柄数
- 1.2.2 创建挂载目录
- 1.2.3 创建docker-compose.yml
- 1.2.4 启动
- 1.2.4.1 访问测试
- 1.2.5 安装插件
- 1.2.5.1 汉化插件
- 1.3 静态分析插件介绍
- 1.3.1 什么是静态代码分析
- 1.3.1.1 静态代码分析优势
- 1.3.2 java静态分析插件
- 1.3.2.1 Checkstyle
- 1.3.2.2 FindBugs
- 1.3.2.3 PMD
- 1.3.3 几种插件对比
- 1.3.3.1 技术对比
- 1.3.3.2 分析对比
- 2. Sonar使用
- 2.1 Maven代码扫描
- 2.1.1 创建项目
- 2.1.2 Maven 分析项目
- 2.1.2.1 生成sonar分析的命令
- 2.1.2.2 项目配置 Sonar
- 2.1.2.3 单元测试覆盖率
- 2.1.3 执行扫描任务
- 2.1.3.1 没有单元测试覆盖率
- 2.1.3.1 单元测试覆盖率
- 2.2 使用SonarLint
- 2.2.1 扫描模式区别
- 2.2.1.1 独立模式
- 2.2.1.2 连接模式
- 2.2.2 安装插件
- 2.2.3 配置SonarLint
- 2.2.3.1 添加sonarqube server
- 2.2.3.2 配置项目
- 2.2.4 联动测试
- 2.2.4.1 分析代码
- 2.2.4.2 关闭服务器bug
- 2.2.4.3 查看本地扫描结果
- 2.3 指标分析
- 2.3.1 总览
- 2.3.2 质量阈值
- 2.3.3 可靠性
- 2.3.4 漏洞严重级别
- 2.3.4.1 阻断
- 2.3.4.2 严重
- 2.3.4.3 重要
- 2.3.4.4 次要
- 2.3.5 安全性
- 2.3.5.1 热点和漏洞
- 2.3.5.2 安全热点
- 2.3.5.3 漏洞
1. sonar安装
1.1 简介
sonar是一款静态代码质量分析工具,支持Java、Python、PHP、JavaScript、CSS等25种以上的语言,而且能够集成在IDE、Jenkins、Git等服务中,方便随时查看代码质量分析报告。
通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具,比如findbugs、Jenkins,通过不同的插件对这些结果进行再加工处理,通过量化的方式度量代码质量的变化,从而可以方便地对不同规模和种类的工程进行代码质量管理。
简单来说,SonarQube是一个质量平台,用于收集质量数据(代码扫描结果、测试覆盖率等),并对数据进行各维度的统计分析。
1.1.1 客户端
Sonar的客户端共有四种
- Sonar-Scanner:一个独立的扫描器,通过简单的命令就能对项目进行静态扫描,并将扫描结果上传至SonarQube
- sonar maven:一个maven插件,能通过maven命令执行静态扫描。
- sonar ant插件:ant上的插件。
- sonar IDE插件:可以直接集成到IDE中(比如IntelliJ)。
1.1.2 sonar 版本区分
SonarQube除了开源的社区版之外,还有开发者版、企业版和数据中心版等不同的发行版本,以满足不同类型的客户需求,以下是根据SonarSource官网整理的各个版本之间的差异。
1.1.2.1 社区版
社区版就是通常大家所说的开源版本的SonarQube,通过其核心的代码质量和安全问题的扫描能力,以及质量门禁的功能,成为了目前代码静态扫描事实上的标准。
据有以下功能
- 60多个插件
- DevOps工具链集成
- 代码质量和安全
- 支持15种语言
- 支持5种IDE
此外,开源版支持15种常见的开发语言,尤其是在互联网行业中广泛使用Java和JavaScript的情况下,通过与构建工具(如maven/gradle插件)以及持续集成工具(如Jenkins)的集成,基本能满足个人和团队的日常代码扫描所需。
1.1.2.2 开发者版
当然,在开源社区版本的基础上,SonarQube还提供了开发者版。在全部社区版功能的基础上,新增了以下的功能
- Branch analysis(分支分析)
- Pull Request decoration(PR/MR注释)
- Detection of injection vulnerabilities(注入漏洞探测)
- SonarLint notifications(SonarLint通知)
- 22 Programming Languages Covered(尤其新增了c/c++/plsql)
- Developer Edition is available up to 20M Lines of Code.
对于金融行业来说,开发者版本支持了C/C++以及Oracle PL/SQL这三种语言,这样就为核心交易类系统以及遗留的业务系统展开代码扫描扫清了障碍。
另外一个非常有用的功能是多分支分析,社区版主要适合主干开发的团队,而目前Gitlab/Github-Flow以及特性分支等也非常流行,具备多分支分析能力,让SonarQube与现有团队的工作模式更加贴合。
1.1.2.3 企业版
对于大型跨国公司或者是集团性企业来说,开发者版就有些不够用了。当然,只要肯花钱,SonarQube也还有适用的版本。
- Portfolio Management(项目集管理)
- Executive Reporting(管理层报告)
- Security Reports(安全报告)
- Project Transfer(项目汇聚)
- 27 Programming Languages Covered
- Enterprise Edition is available up to 100M Lines of Code.
从上述特性清单来看,企业版主要是关注于管理层面的增强了。例如,多个应用可以汇聚成一条产品线或者事业部,通过其项目集管理也可以把若干个SonarQube项目汇聚到一个统计口径之下。
1.2 安装部署
1.2.1 修改文件句柄数
系统配置,避免启动问题
# 系统配置,避免启动问题
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p
1.2.2 创建挂载目录
mkdir -p ~/sonarqube && cd ~/sonarqube
# 创建所有的sonarqube映射文件
mkdir -p ~/sonarqube/postgres && \
mkdir -p ~/sonarqube/data && \
mkdir -p ~/sonarqube/extensions && \
mkdir -p ~/sonarqube/logs && \
mkdir -p ~/sonarqube/conf
# 创建数据库挂载
mkdir -p ~/sonarqube/postgresql &&\
mkdir -p ~/sonarqube/datasql
# 目录设置为 777 权限,避免权限问题
chmod 777 ~/sonarqube/*
1.2.3 创建docker-compose.yml
vi ~/sonarqube/docker-compose.yml
version: '3'
services:
postgres:
image: postgres:9.6.24
restart: always
container_name: sonarqube_postgres
ports:
- 5432:5432
volumes:
- ~/sonarqube/postgresql/:/var/lib/postgresql
- ~/sonarqube/datasql/:/var/lib/postgresql/data
environment:
TZ: Asia/Shanghai
POSTGRES_USER: sonar
POSTGRES_PASSWORD: sonar
POSTGRES_DB: sonar
networks:
- sonar-network
sonar:
image: sonarqube:8.9.9-community
restart: always
container_name: sonarqube
depends_on:
- postgres
volumes:
- ~/sonarqube/extensions:/opt/sonarqube/extensions
- ~/sonarqube/logs:/opt/sonarqube/logs
- ~/sonarqube/data:/opt/sonarqube/data
- ~/sonarqube/conf:/opt/sonarqube/conf
ports:
- 9000:9000
environment:
SONARQUBE_JDBC_USERNAME: sonar
SONARQUBE_JDBC_PASSWORD: sonar
SONARQUBE_JDBC_URL: jdbc:postgresql://postgres:5432/sonar
networks:
- sonar-network
networks:
sonar-network:
driver: bridge
1.2.4 启动
docker-compose up -d
1.2.4.1 访问测试
浏览器访问:ip+端口,如:192.168.245.139:9000,账号密码都是
admin
登录后进入项目页面
1.2.5 安装插件
可以进入应用市场下载一些常见的插件,一般是通过github下载,可能出现现在不下来的情况,可以手动下载后将jar包放进对应的
extensions/downloads
下载目录就可以,然后点击install就可以进行安装了
1.2.5.1 汉化插件
Chinese Pack是一个sonar的汉化插件,安装后就可以体验中文界面了,以下是各版本的对应关系
SonarQube | 9.0 | 9.1 | 9.2 | |||||||
sonar-l10n-zh | 9.0 | 9.1 | 9.2 | |||||||
SonarQube | 8.0 | 8.1 | 8.2 | 8.3 | 8.4 | 8.5 | 8.6 | 8.7 | 8.8 | 8.9 |
sonar-l10n-zh | 8.0 | 8.1 | 8.2 | 8.3 | 8.4 | 8.5 | 8.6 | 8.7 | 8.8 | 8.9 |
SonarQube | 7.0 | 7.1 | 7.2 | 7.3 | 7.4 | 7.5 | 7.6 | 7.7 | 7.8 | 7.9 |
sonar-l10n-zh | 1.20 | 1.21 | 1.22 | 1.23 | 1.24 | 1.25 | 1.26 | 1.27 | 1.28 | 1.29 |
SonarQube | 6.0 | 6.1 | 6.2 | 6.3 | 6.4 | 6.5 | 6.6 | 6.7 | ||
sonar-l10n-zh | 1.12 | 1.13 | 1.14 | 1.15 | 1.16 | 1.17 | 1.18 | 1.19 | ||
SonarQube | 5.4 | 5.5 | 5.6 | |||||||
sonar-l10n-zh | 1.9 | 1.10 | 1.11 | |||||||
SonarQube | 4.0 | 4.1 | ||||||||
sonar-l10n-zh | 1.7 | 1.8 | ||||||||
SonarQube | 3.1 | 3.2 | 3.3 | 3.4 | 3.5 | 3.6 | 3.7 | |||
sonar-l10n-zh | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 |
下载地址:https://github.com/xuhuisheng/sonar-l10n-zh,找到对应的版本下载后上传到dowload文件夹
在应用市场进行重启即可
再次访问就变成了中文界面了
1.3 静态分析插件介绍
1.3.1 什么是静态代码分析
静态代码分析是指无需运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性,找出代码隐藏的错误和缺陷,如参数不匹配,有歧义的嵌套语句,错误的递归,非法计算,可能出现的空指针引用等等。
在软件开发过程中,静态代码分析往往先于动态测试之前进行,同时也可以作为制定动态测试用例的参考。统计证明,在整个软件开发生命周期中,30% 至 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。
但是,由于静态代码分析往往要求大量的时间消耗和相关知识的积累,因此对于软件开发团队来说,使用静态代码分析工具自动化执行代码检查和分析,能够极大地提高软件可靠性并节省软件开发和测试成本。
1.3.1.1 静态代码分析优势
- 帮助程序开发人员自动执行静态代码分析,快速定位代码隐藏错误和缺陷。
- 帮助代码设计人员更专注于分析和解决代码设计缺陷。
- 显著减少在代码逐行检查上花费的时间,提高软件可靠性并节省软件开发和测试成本。
1.3.2 java静态分析插件
1.3.2.1 Checkstyle
Checkstyle 是 SourceForge 的开源项目,通过检查对代码编码格式,命名约定,Javadoc,类设计等方面进行代码规范和风格的检查,从而有效约束开发人员更好地遵循代码编写规范。
此外,Checkstyle 支持用户根据需求自定义代码检查规范,在配置面板中,用户可以在已有检查规范如命名约定,Javadoc,块,类设计等方面的基础上添加或删除自定义检查规范。
检查内容
- Javadoc 注释:检查类及方法的 Javadoc 注释
- 命名约定:检查命名是否符合命名规范
- 标题:检查文件是否以某些行开头
- Import 语句:检查 Import 语句是否符合定义规范
- 代码块大小,即检查类、方法等代码块的行数
- 空白:检查空白符,如 tab,回车符等
- 修饰符:修饰符号的检查,如修饰符的定义顺序
- 块:检查是否有空块或无效块
- 代码问题:检查重复代码,条件判断,魔数等问题
- 类设计:检查类的定义是否符合规范,如构造函数的定义等问题
1.3.2.2 FindBugs
FindBugs 是由马里兰大学提供的一款开源 Java 静态代码分析工具,FindBugs 通过检查类文件或 JAR 文件,将字节码与一组缺陷模式进行对比从而发现代码缺陷,完成静态代码分析,FindBugs 既提供可视化 UI 界面,同时也可以作为 Idea 插件使用。
检查内容
- Bad practice 坏的实践:常见代码错误,用于静态代码检查时进行缺陷模式匹配
- Correctness 可能导致错误的代码,如空指针引用等
- 国际化相关问题:如错误的字符串转换
- 可能受到的恶意攻击,如访问权限修饰符的定义等
- 多线程的正确性:如多线程编程时常见的同步,线程调度问题。
- 运行时性能问题:如由变量定义,方法调用导致的代码低效问题。
1.3.2.3 PMD
PMD 是由 DARPA 在 SourceForge 上发布的开源 Java 代码静态分析工具,PMD 通过其内置的编码规则对 Java 代码进行静态检查,主要包括对潜在的 bug,未使用的代码,重复的代码,循环体创建新对象等问题的检验。
检查内容
- 可能的 Bugs:检查潜在代码错误,如空 try/catch/finally/switch 语句
- 未使用代码(Dead code):检查未使用的变量,参数,方法
- 复杂的表达式:检查不必要的 if 语句,可被 while 替代的 for 循环
- 重复的代码:检查重复的代码
- 循环体创建新对象:检查在循环体内实例化新对象
- 资源关闭:检查 Connect,Result,Statement 等资源使用之后是否被关闭掉
1.3.3 几种插件对比
1.3.3.1 技术对比
Java 静态分析工具 | 分析对象 | 应用技术 |
---|---|---|
Checkstyle | Java 源文件 | 缺陷模式匹配 |
FindBugs | 字节码 | 缺陷模式匹配;数据流分析 |
PMD | Java 源代码 | 缺陷模式匹配 |
1.3.3.2 分析对比
代码缺陷分类 | 示例 | Checkstyle | FindBugs | PMD |
---|---|---|---|---|
引用操作 | 空指针引用 | √ | √ | √ |
对象操作 | 对象比较(使用 == 而不是 equals) | √ | √ | |
表达式复杂化 | 多余的 if 语句 | √ | ||
数组使用 | 数组下标越界 | |||
未使用变量或代码段 | 未使用变量 | √ | √ | |
资源回收 | I/O 未关闭 | √ | ||
方法调用 | 未使用方法返回值 | √ | ||
代码设计 | 空的 try/catch/finally 块 | √ |
2. Sonar使用
2.1 Maven代码扫描
2.1.1 创建项目
点击创建项目就可以创建一个项目,为项目创建令牌
选择手工创建项目即可
点击手工后,输入项目标识符以及项目名称,标识符是为了区分不同的项目,输入完成后,在输入令牌点击创建即可
创建令牌后,会生成一个token,这个token是需要保存的,只会在这里显示一次
2.1.2 Maven 分析项目
2.1.2.1 生成sonar分析的命令
点击后面的
Maven
分析项目,会生成一个maven分析项目的命令保存下来
mvn sonar:sonar \
-Dsonar.projectKey=taxi \
-Dsonar.host.url=http://192.168.245.139:9000 \
-Dsonar.login=7aafcd2c4da5c2e80bde66a3a0970d3278d359d6
2.1.2.2 项目配置 Sonar
我们需要配置 Maven 的 setting.xml文件,增加 sonarQube 配置
<!-- Apache Maven 配置 -->
<pluginGroups>
<pluginGroup>com.spotify</pluginGroup>
<!-- 添加一个maven扫描的配置 -->
<pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
</pluginGroups>
<profiles>
<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<!-- 配置 Sonar Host地址,默认:http://localhost:9000 -->
<sonar.host.url>
http://192.168.245.139:9000
</sonar.host.url>
</properties>
</profile>
</profiles>
2.1.2.3 单元测试覆盖率
项目中一般要求需要编写测试用例,可以使用sonar统计单元测试的覆盖率,需要在maven项目由以下配置
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.8</version>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>target/jacoco.exec</dataFile>
<outputDirectory>target/jacoco-reports</outputDirectory>
</configuration>
</execution>
</executions>
<configuration>
<systemPropertyVariables>
<jacoco-agent.destfile>target/jacoco.exec</jacoco-agent.destfile>
</systemPropertyVariables>
</configuration>
</plugin>
2.1.3 执行扫描任务
2.1.3.1 没有单元测试覆盖率
配置完成setting.xml后就可以到项目中执行maven的执行命令了,可以执行以下命令
mvn sonar:sonar -Dsonar.projectKey=hitch -Dsonar.login=7c73f9b0176966c98ae9f52f129a3123227af29e
然后在项目中执行相关命令
执行后就可以等待sonar扫描即可
扫描完成后就可以看到分析的项目问题了
2.1.3.1 单元测试覆盖率
配置完成项目后,就需要执行sonar扫描命令了,如果需要单元测试执行如下命令
mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install -Dmaven.test.failure.ignore=true -Dsonar.core.codeCoveragePlugin=jacoco -Dsonar.projectKey=robocode -Dsonar.login=7e469127ed58539844f1c68dd0cb77f60e02d0e6 sonar:sonar
在项目中执行maven命令
执行后就可以等待sonar扫描完成即可
扫描完成后就可以看到分析的项目问题了
2.2 使用SonarLint
SonarLint是一款强大快速的能帮助开发者发现代码里的bug或是代码质量优化点的扩展工具。支持很多主流的语言:JAVA、js、PHP、Python,也支持主流的IDE们,idea、Eclipse、vs。在idea里更是以插件的形式无缝接入。
2.2.1 扫描模式区别
2.2.1.1 独立模式
使用插件内置规则进行检查,由于刚安装完插件之后设置是默认打开自动检测的,所以现在你的最底层工具栏里应该会多一项sonarlint,你打开不同的Java文件,检测会自动进行 ,检测结果也会直接展示在那里。
- 优点:无须配置,开箱即用,检查速度快;
- 缺点:内置规则与SonarQube服务器规则的不一致,会造成检查结果的不一致。
使用
2.2.1.2 连接模式
需连接SonarQube服务器
- 优点:简单配置后,即可使用SonarQube服务器的规则和配置项进行检查,检查结果保持最大一致。
- 缺点:项目需先接入SonarQube。
2.2.2 安装插件
打开IDEA,File-> Setteings->Plugins,在搜索栏搜索SonarLint,然后安装,安装完后点击Restart IntelliJ IDEA重启idea
2.2.3 配置SonarLint
对于企业级的开发,很多企业可能对代码风格和检查项有自己的要求。这就可以为公司的开发者提供sonarqube服务器,在其上进行配置,然后开发者连接以后就可以让sonarlint按照公司的定义来进行检查了。
2.2.3.1 添加sonarqube server
依次点击File–>Settings–>Other Settings–>SonarLint General Settings,并进行如下操作:
配置本地nodejs.exe,然后添加
sonarqube
服务器
2.2.3.2 配置项目
输入刚刚创建的Token
最后选择对应的projectKey即可
可以配置响应的模块来查看进行检测项目
2.2.4 联动测试
使用了连接模式后,我们对于
sonarqube
服务求上面的规则变更会反映到我们的本地sonarlint插件上
2.2.4.1 分析代码
该类存在四个空指针的问题,我们假设改代码不会出现空指针问题
2.2.4.2 关闭服务器bug
我们到
sonarqube
将该问题给改为不会修复
,并点击评论即可
2.2.4.3 查看本地扫描结果
再次来查看下本地的扫描结果,发现该bug提示已经消失。
2.3 指标分析
2.3.1 总览
2.3.2 质量阈值
表示扫描是否通过,如果没有通过会显示失败,就需要进行修改代码了
2.3.3 可靠性
可靠性主要反应代码的bug数量,分为A-E五个等级,计算规则如下
- A :0 Bug 最高等级A,表示代码无bug
- B :at least 1 Minor Bug 代码只要有一个次要bug,等级就为B
- C:at least 1 Major Bug 只要包含一个重要bug,等级将为C
- D:at least 1 Critical Bug 只要有一个严重bug,等级评估为D
- E:at least 1 Blocker Bug 只要有一个最高等级的阻断级别的bug,可靠性评估为E,最低级别
2.3.4 漏洞严重级别
2.3.4.1 阻断
直接获取重要服务器(客户端)权限的漏洞。
包括但不限于远程任意命令执行、上传 webshell、可利用远程缓冲区溢出、可利用的 ActiveX 堆栈溢出、可利用浏览器 use after free 漏洞、可利用远程内核代码执行漏洞以及其它因逻辑问题导致的可利用的远程代码执行漏洞; 直接导致严重的信息泄漏漏洞,包括但不限于重要系统中能获取大量信息的SQL注入漏洞; 能直接获取目标单位核心机密的漏洞。
2.3.4.2 严重
直接获取普通系统权限的漏洞
包括但不限于远程命令执行、代码执行、上传webshell、缓冲区溢出等; 严重的逻辑设计缺陷和流程缺陷。包括但不限于任意账号密码修改、重要业务配置修改、泄露; 可直接批量盗取用户身份权限的漏洞。包括但不限于普通系统的SQL注入、用户订单遍历; 严重的权限绕过类漏洞。包括但不限于绕过认证直接访问管理后台、cookie欺骗。 运维相关的未授权访问漏洞,包括但不限于后台管理员弱口令、服务未授权访问
2.3.4.3 重要
需要在一定条件限制下,能获取服务器权限、网站权限与核心数据库数据的操作
包括但不限于交互性代码执行、一定条件下的注入、特定系统版本下的getshell等; 任意文件操作漏洞。包括但不限于任意文件写、删除、下载,敏感文件读取等操作; 水平权限绕过,包括但不限于绕过限制修改用户资料、执行用户操作。
2.3.4.4 次要
能够获取一些数据,但不属于核心数据的操作
在条件严苛的环境下能够获取核心数据或者控制核心业务的操作, 需要用户交互才可以触发的漏洞,包括但不限于XSS漏洞、CSRF漏洞、点击劫持。
2.3.5 安全性
安全性主要反应代码中可能存在的漏洞的数量
2.3.5.1 热点和漏洞
热点和漏洞之间的主要区别:在决定是否应用修复之前需要进行审查
2.3.5.2 安全热点
可以突出显示安全敏感的一段代码,但可能不会影响整体应用程序安全性。由开发人员审查代码以确定是否需要修复以保护代码。
2.3.5.3 漏洞
已发现需要立即修复的影响应用程序安全性的问题