可以在多个位置配置项目分析设置。下面是层次结构：

  • 在 UI 中定义的全局属性适用于所有项目（从顶部栏转到”管理>配置 >常规设置” )
  • 在 UI 中定义的项目属性覆盖全局属性值（在项目级别，转到项目设置> 常规设置)
  • 在项目分析配置文件定义的项目分析参数将覆盖 UI 中定义的参数
  • 分析/命令行参数，在启动分析时定义（使用命令行），”-D”覆盖项目分析参数

    SonarQube-规则

在SonarQube中，分析程序提供在源代码上执行的规则来生成问题。有四种类型的规则:

  • Code Smell (Maintainability domain)
  • Bug (Reliability domain)
  • Vulnerability (Security domain)
  • Security Hotspot (Security domain)

    规则

    默认情况下，点击带单栏Rules时，你将看到SonarQube实例上安装的分析程序带来的所有可用规则。你可根据以下条件缩小范围:
    image.png

规则细节

要查看规则的详细信息，请点击它。除了基本规则数据之外，您还可以查看其中活动的配置文件（如果有）以及已经引发了多少未解决的问题。
只有拥有正确的权限时，才能使用以下两个操作:

  • Add/Remove Tags
  • Extend Description

规则模板和自定义规则

Rule Templates and Custom Rules
规则模板(Rule templates)由创建提供，允许用户在SonarQube中定义自己的规则。它位于Rules -> Template。
要从模板创建自定义规则，你必须填写一下信息:

  • Name
  • Key (auto-suggested)
  • Description (Markdown format is supported)
  • Default Severity
  • Status
  • The parameters specified by the template

扩展编码规则

Extending Coding Rules
可以添加自定义编码规则。

规则类型和严重性

Rule Types and Severities
Type:

  • Bug
  • Vulnerability
  • Code Smell
  • Security Hotspot

Severity:

  • Blocker
  • Critical
  • Major
  • Minor
  • Info

安全相关的规则

Security-related Rules
SonarQube质量类型有三种不同的规则:

  • Reliability (bug)
  • Vulnerability (security)
  • Maintainability (code smell)

但另外一种方式，只有两种类型:

  • security rule
  • 其它

两者之间的区别并不在它们捕获的内容，而在于她们来自何处以及强加于它们的标准。

从安全相关的规则的期望是什么

What to expect from security-related rules
需要明确的是，SonarQube语言插件中实现的大多数规则的标准是非常严格: 没有误报。对于正常规则，你应该能够确信任何报告给你的问题确实是一个问题。
但对于与安全相关的规则，情况略有不同。例如，许多安全指南讨论了应如何处理敏感数据。但是，由于规则中不可能确定哪些数据是敏感，哪些是不敏感。因此选择变为： 保持无误判标准并且不实施与安全相关的规则，或者实施与安全的规则不同的标准。
这就是为什么与安全相关的规则很广泛。官方的想法是，该规则将标记任何可疑的内容，并将其留给安全审核人员来剔除误报并发送真正的问题进行补救。
安全热点是一种特殊类型的问题，用于识别安全审核人员应审核的敏感区域，以确定它们是否真的是漏洞。有关热点和审计过程的详细信息，请参阅安全审核和报告。

与安全相关的规则来自何方

Where security-related rules come from
绝大多数与安全相关的规则源于既定标准:

  • CWE(Common Weakness Enumeration)：是美国MITRE机构提出的一套语言标准，用于描述软件安全弱点的通用化描述语言。每个CWE条目都包含了CWE标识符/弱点类型名称、类型的描述、弱点的行为、弱点的利用方法、利用弱点的可能性、可能导致的后果、应对措施、代码示例、对应的CVE漏洞数量、参考信息等内容。
  • SANS Top 25-CWE/SANS TOP 25 Most Dangerous Software Errors
  • OWASP Top 10-OWASP Top 10 Application Security Risks

要查找与任何这些标准相关的规则，你可以按标签或文本搜索规则。

CWE

CWE标准代表Common Weakness Enumeration:
Common Weakness Enumeration (CWE™) 是一个常见软件弱点的正式列表或字典，可能出现在软件的体系结构、设计代码或实现中。可能导致可利用的安全漏洞。创建CWE是为了描述软件安全漏洞的通用语言，作为针对这些弱点的软件安全工具的衡量标准；并为弱点识别、缓解和预防工作提供共同的基线标准。
CWE是弱化的描述的层次结构。层次结构中的最低级别是弱点基础(Weakness Base)，它描述了细腻度的弱点。
符合特定要求的工具可以认证为CWE兼容。这些要求是:

  • 您必须能够使用CWE标识符搜索与CWE相关的规则。要在SonarQube平台中执行此操作，只需将CWE标识符（例如CWE-595）放在规则页面上的搜索文本输入中并运行搜索
  • 规则必须与其相关的CWE项目准确链接。要查看SonarQube规则的CWE映射，请参阅规则说明底部的规则参见部分
  • 您必须能够从问题中识别相关的CWE。要在SonarQube平台中执行此操作，请参阅相关规则
  • 产品文档必须包含CWE和CWE兼容性的说明
  • 除了通过CWE id搜索规则外，您还可以通过 cwe rule tag 进行搜索

SANS TOP 25

SANS Top 25列表是由SANS组织编制的CWE中列出的25个最危险错误的集合。当前的SANS列表分为三类：

  • Insecure Interaction Between Components
  • Risky Resource Management
  • Porous Defenses

要查找与SANS Top 25相关的规则，您可以对类别或相关CWE项目执行文本搜索，或执行规则标记搜索。

OWASP Top 10

OWASP代表Open Web Application Security Project。它是:
501(c)(3)全球非营利慈善组织，致力于提高软件的安全性。我们的使命是使软件安全可见，以便全世界的个人和组织能够就真正的软件安全风险做出明智的决策。
OWASP Top 10列出了各种各样的弱点，每个弱点都可以映射到许多单独的规则。
OWASP TOP 10在SonarQube中也对应相关的tag。
要查找与OWASP Top 10相关的规则，您可以对类别执行文本搜索，或执行规则标记搜索。

规则和标签
Built-in Rule Tags
标签(tag) 是一种对问题(issue)和规则(rule)进行分类的方法。问题会继承引发它们的规则上的标记。有些标签适用于特定语言，但是更多的标签出现在各种语言中。用户可以为规则和问题添加标签。但大多数规则都有一些开箱即用的标签。
以下是一些非全面的、包含一些內建标签:

  • brain-overload- 一次有太多的东西要留在脑海里
  • bad-practice- 代码可能按设计工作，但它的设计方式被广泛认为是一个坏主意
  • cert- 设计CERT标准中的规则
  • clumsy- 用于完成可以更清晰和简洁地完成的事情的额外步骤
  • confusing- 将使维护者更长时间地理解，而不是代码实际所做的事情
  • convention- 编码约定，如格式化、命名、空格…
  • cwe- CWE安全规则
  • design- 代码设计存在一些问题
  • lock-in- 使用特定于环境的功能
  • misra- MISRA标准相关的规则
  • owasp- 与OWASP TOP 10安全标准相关的规则
  • pitfall- 没有什么不对，但未来可能出现问题;已经为下一个人设置了一个陷阱，他可能会陷入其中并搞砸了代码
  • sans-top25- 与SANS Top 25 Coding Errors安全相关
  • suspicious- 它不能保证这是一个bug，但它看起来很可疑。至少，代码应该重新检查并且可能为了清晰而重构
  • unpredictable- 代码可以在当前条件下正常工作，但如果条件发生变化可能会失败
  • unused- 未使用的代码
  • user-experience- 代码在技术上没有任何问题，但它可能会使您的部分或全部用户讨厌您

    常用配置

    首先在需要扫描的目录下创建sonar-project.properties文件,写入如下配置 ```groovy sonar.projectKey=gpcore #sonar平台中相对应项目的key sonar.projectName=gpcore #sonar平台中相对应项目的名字 sonar.sources=. #sonar检测的源文件目录，‘.’表示当前根目录下的所有文件目录;包含主要源文件的目录的逗号分隔路径 sonar.exclusions=/*_test.go,/vendor/ #检测中排除的源文件（排除的源文件不参与检测，一般排除单元测试文件、配置文件等） sonar.tests=. #sonar检测的测试文件目录，‘.’表示当前根目录下的所有文件目录;包含测试源文件的目录的逗号分隔路径。从构建系统中读取Maven，Gradle，MSBuild项目。否则默认为空。 sonar.test.inclusions=/_test.go #检测中的测试源文件（指定单元测试文件） sonar.test.exclusions=/vendor/** #检测中排除的测试源文件（排除的源文件不参与检测）

简单的来说只需要添加sonarqube参数， 指定模式/git项目/commitid/分支。 -Dsonar.analysis.mode=preview -Dsonar.gitlab.ref_name=分支名称 -Dsonar.gitlab.project_id=仓库组/仓库名称 -Dsonar.gitlab.commit_sha=提交sha ```

安全设置

参考文档：https://docs.sonarqube.org/latest/instance-administration/security/

强制要求必须登录SonarQube

用管理员账号登录SonarQube，打开Administration > Configuration > General Settings > Security，开启Force user authentication，点击Save保存生效。
开启该选项后，不允许匿名运行mvn sonar:sonar代码扫描，必须提供SonarQube Token。

修改默认的项目可见性为private

用管理员账号登录SonarQube，打开Administration > Projects > Management，修改Default visibility of new projects为private。
这样新建项目后，只有该项目的授权用户才能看到该项目的代码。
对已有的项目，打开项目级别的Adminstration > Permissions，手工修改项目可见性。

去掉Anyone组的权限

用管理员账号登录SonarQube，打开Administration > Security > Global Permissions，去掉Anyone组的所有权限。

去掉Project Creator的权限

用管理员账号登录SonarQube，打开Administration > Security > Permission Templates，打开Default template，去掉Project Creator的所有权限。

生成用户Token

用该用户登录SonarQube，打开MyAccount > Security，来生成一个Token。
在按项目作多租户隔离的场景，需要为每个项目在SonarQube上创建一个用户，并使用该用户的Token来作代码扫描。

设置项目账号权限

用管理员账号登录SonarQube，打开项目级别的Adminstration > Permissions，选择Users，输入用户名称查询，然后设置该用户权限。一般只需要设置Browse，See Source Code和Execute Analysis即可。
在按项目作多租户隔离的场景，需要为每个项目在SonarQube上创建一个用户，并设置只有该用户才有相应权限。