sonarqube扫描报告之安全热点
作者：互联网
sonarqube扫描报告之中有一个“安全热点”，按照自己的理解，安全热点就是安全漏洞嘛，或者安全问题。 在准备sonar培训的时候，自己特意去了解扫描报告的各种问题类型，看到下文解释“安全热点”非常透彻，于是收藏在此。
什么是安全热点？
安全热点突出显示开发人员需要审查的安全敏感代码段。经过审查，您要么会发现没有威胁，要么需要应用修复程序来保护代码。
查看热点的另一种方式可能是深度防御的概念，其中在应用程序中放置了几个冗余保护层，以便在发生攻击时变得更有弹性。
漏洞还是热点？
热点和漏洞之间的主要区别在于在决定是否应用修复之前需要进行审查：
- 使用热点，可以突出显示安全敏感的一段代码，但可能不会影响整体应用程序安全性。由开发人员审查代码以确定是否需要修复以保护代码。
- 对于漏洞，已发现需要立即修复的影响应用程序安全性的问题。
一个例子是RSPEC-2092，其中建议使用cookie 安全标志来防止通过非 HTTPS 连接发送 cookie，但需要进行审查，因为：
- HTTPS 是抵御 MITM 攻击的主要保护措施，因此安全标志只是在网络安全发生某些故障时的附加保护。
- cookie 可能被设计为随处发送（包括非 HTTPS 网站），因为它是跟踪 cookie 或类似的。
通过热点，我们尝试为用户提供一些自由，并教育他们如何根据上下文（预算、威胁等）选择最相关/最合适的保护措施。
为什么安全热点很重要？
虽然修复单个热点的需要取决于上下文，但您应该将安全热点视为提高应用程序健壮性的重要部分。固定热点越多，您的代码在遭受攻击时就越安全。查看安全热点允许您：
- 了解风险——了解何时以及为何需要应用修复以降低信息安全风险（威胁和影响）。
- 确定保护措施– 在查看热点时，您将了解如何避免编写有风险的代码、确定哪些修复已到位，并确定仍需要实施哪些修复以修复突出显示的代码。
- 识别影响– 通过热点，您将学习如何根据对整体应用程序安全性的影响应用修复程序来保护您的代码。热点页面中包含推荐的安全编码实践，以帮助您进行审核。
生命周期
安全热点具有专用的生命周期。要更改状态，用户需要管理安全热点权限。默认情况下启用此权限。具有浏览权限的用户可以评论或更改分配给安全热点的用户。
状态
在整个生命周期中，安全热点采用以下状态之一：
- To Review – SonarQube 设置的新安全热点的默认状态。已报告安全热点，需要检查。
- 已审核– 开发人员已手动评估安全热点并决定是否应用修复程序。
工作流程
按照此工作流程查看安全热点并应用保护代码所需的任何修复程序。
审核优先级
当 SonarQube 检测到一个安全热点时，它会根据其审查优先级从高到低添加到安全热点列表中。具有高审查优先级的热点最有可能包含需要保护并首先需要您注意的代码。
审核优先级由每个安全规则的安全类别决定。在 OWASP 前 10 名和 CWE 前 25 名标准中排名靠前的类别中的规则被认为具有高审查优先级。排名不高或未在 OWASP 前 10 名或 CWE 前 25 名标准中提及的类别中的规则被评为中或低。
查看热点
在查看热点时，您应该：
- 查看什么是风险选项卡以了解为什么会引发安全热点。
- 从“您是否有风险”选项卡中，阅读“问自己是否存在”部分以确定您是否需要应用修复程序来保护热点中突出显示的代码。
- 从“如何修复它”选项卡中，如果您确定代码不安全，请按照推荐的安全编码实践来修复您的代码。
完成这些步骤后，将安全热点设置为以下之一：
- 已修复– 如果您已应用修复程序来保护热点突出显示的代码。
- 安全- 如果代码已经安全并且不需要修复。（例如，其他更相关的保护措施已经到位）。
- 审查- 如果您需要其他用户的审查。
回顾历史
“审查历史记录”选项卡显示安全热点的历史记录，包括分配的状态以及审查者对热点的任何评论。
在 IDE 中查看热点
直接在 IDE 中查看安全热点可以帮助您更好地了解其上下文并确定它是否安全。这是您将作为经过身份验证的用户看到的在 IDE 中打开按钮的用途。
此功能可供以下用户使用：
- 适用于 Visual Studio 4.29 及更高版本的SonarLint
- 适用于 IntelliJ 4.13 及更高版本的SonarLint
- VS Code 1.20 及更高版本的SonarLint
- Eclipse 5.7 及更高版本的SonarLint
项目需要在合适的IDE中打开，并通过SonarLint的连接方式绑定到服务器。
请记住，SonarQube 分析的修订或分支可能与您在 IDE 中打开的不同。在这种情况下，SonarLint 将尽最大努力在您的本地代码中定位安全热点。
安全热点和漏洞有什么区别？
安全热点和漏洞的不同之处在于：
- 安全热点是一段对安全敏感的代码，突出显示但不一定影响整体应用程序安全。由开发人员审查代码以确定是否需要修复以保护代码。
- 漏洞是影响应用程序安全的问题，需要立即修复。
有关更多详细信息，请参阅安全热点页面。
为什么我看不到任何漏洞或安全热点？
由于以下原因，您可能看不到任何漏洞或安全热点：
- 您的代码是在未使用任何安全敏感 API 的情况下编写的。
- 漏洞或安全热点规则可用，但未在您的质量配置文件中激活，因此不会引发安全热点或漏洞。
- SonarQube 目前可能没有很多适用于您的语言的规则，因此它不会引发任何或仅少数漏洞或安全热点。
| 概念 | 定义 |
|---|---|
| 分析仪 | 分析源代码以计算快照的客户端应用程序。 |
| 数据库 | 存储配置和快照 |
| 服务器 | 用于浏览快照数据和进行配置更改的Web 界面 |
质量
| 概念 | 定义 |
|---|---|
| 漏洞 | 表示代码中出现错误的问题。如果这还没有打破，它会，而且可能是在最糟糕的时刻。这需要修复。昨天。 |
| 代码气味 | 代码中与可维护性相关的问题。保持原样意味着维护人员最多会比他们对代码进行更改更难。最坏的情况是，他们会对代码的状态感到困惑，以至于在进行更改时会引入额外的错误。 |
| 成本 | 查看修复成本 |
| 债务 | 见技术债 |
| 问题 | 当一段代码不符合规则时，快照上会记录一个问题。问题可以记录在源文件或单元测试文件中。有 3 种类型的问题：错误、代码异味和漏洞 |
| 措施 | 给定时间给定文件或项目的度量值。例如，类 MyClass 上的 125 行代码或项目 myProject 上 30.5% 的重复行密度 |
| 公制 | 一种测量。随着时间的推移，指标可以具有不同的值或度量。示例：代码行数、复杂性等。度量可以是定性的（给出组件的质量指示、重复行的 EG 密度、测试的行覆盖率等）或定量的（不给出质量指示）在组件上，EG 代码行数，复杂度等） |
| 新代码定义 | 您密切关注代码中引入新问题的变更集或时期。理想情况下，这是因为previous_version，但如果您不使用类似 Maven 的版本控制方案，您可能需要设置一个时间段，例如 21 天，从特定分析开始，或使用参考分支。 |
| 质量简介 | 一套规则。每个快照都基于单个质量配置文件。另见质量概况 |
| 规则 | 应遵循的编码标准或实践。不遵守编码规则会导致错误、漏洞、安全热点和代码异味。规则可以检查代码文件或单元测试的质量。 |
| 修复成本 | 修复漏洞和可靠性问题所需的估计时间。 |
| 快照 | 在给定时间针对给定项目的一组措施和问题。每次分析都会生成一个快照。 |
| 安全热点 | 需要手动检查的安全敏感代码段。经过审查，您要么会发现不存在威胁，要么会发现存在需要修复的易受攻击的代码。 |
| 技术债 | 修复所有可维护性问题/代码异味所需的估计时间 |
| 漏洞 |
一个与安全相关的问题，代表攻击者的后门。另请参阅安全相关规则。 |
原文链接：https://www.cnblogs.com/cndevops/p/15389826.html
标签：审查,修复,漏洞,sonarqube,代码,扫描,安全,热点 来源： https://www.cnblogs.com/Uni-Hoang/p/15434499.html