为什么 SonarQube 9.9 LTS 是 Python 开发人员的必备工具

SonarQube 9.9 LTS具有强大的 Python 分析器，具有 250 条（好吧，249 条）规则，以确保 Python 开发人员可以编写适合生产和开发的干净代码。

在此 LTS 版本中，与 SonarQube 8.9 LTS 相比，Python 分析方面有显着进步。喝杯咖啡，放松心情，听我带您完成这些改进！

使用声纳云？您也会在那里发现所有这些改进。

分析引擎更新

Typeshed 的预计算符号可提高性能和准确性

为了提供准确的分析，SonarQube 依赖于 Python 标准库以及 Python 开发人员使用的通用库的类型信息。此类型信息由Typeshed（Python 存根的集合）提供。

在 SonarQube 8.9 LTS 中，此信息是在分析时计算的，这是昂贵的。也不可能收集所有可用信息，例如基于所使用的 Python 版本的条件类型信息。

SonarQube 9.9 LTS 以更好的性能从 Typeshed 中提取更多的数据（一次性计算符号，随 SonarQube 一起提供，而不是每次分析），从而实现更好的性能和更好的结果的分析。

可提供Python版本，分析结果更准确

正如刚才提到的，SonarQube 现在可以考虑特定于所使用的 Python 版本的类型信息。

与 Python 2 相比，Python 3 有许多重大更改，当某些代码模式在 Python 3 中是错误但在 Python 2 中不是错误时，这会对我们的错误检测规则产生影响！

使用 SonarQube 9.9 LTS 的开发人员现在可以设置sonar.python.version分析参数，以检测特定于 Python 2 或 Python 3 的问题。

考虑这段代码：

def get_first(items):
    res = filter(lambda x: x > 1, items)    return res[0]

如果您使用 Python 3，这里会出现一个问题：filterAPI 返回一个没有__getitem__方法的迭代器。这对于 Python 2 来说不是问题，因为相同的 API 返回一个列表。如果您将代码库迁移到 Python 3，这是一个很容易犯的错误。

SonarQube 9.9 LTS 知道所使用的 Python 版本，可以正确地对此代码提出问题。

支持 Python 3.10 和 3.11

说到 Python 版本……新的 SonarQube LTS 意味着支持新版本的语言，这需要 SonarQube 更新在提出问题的情况下解析和理解代码的方式。

在 SonarQube 9.9 LTS 中，增加了对 Python 3.10 和 3.11 的支持，解析新的结构，例如语句和语法的许多模式match。except*

这也意味着现有规则已更新，不会对这些结构产生误报。

通过符号分析增强漏洞检测

SonarSource早在 2020 年 5 月就收购了 RIPS Technologies （2020 年春季世界上还发生了一些其他事情，所以如果您忘记了也不必担心）！

我们不仅结识了很多优秀的同事，还获得了他们检测 Python 漏洞的先进技术。经过几个月的工作，我们充分利用了 Sonar 和 RIPS 引擎的优点，为 Python 开发了一个新的安全引擎。我们实际上完全更换了引擎，从所谓的定点分析转向符号分析。

这意味着 Python 的安全引擎现在是字段敏感的，SonarQube 9.9 LTS 的商业版本可以精确跟踪对象的哪个字段被恶意用户输入污染（或未被污染）。对于您来说，这意味着误报更少，因此您可以专注于修复真正的漏洞，而不是分析假漏洞。

修复误报

在误报主题上，改进的不仅仅是安全规则。Sonar 投入了大量的精力来确保只提出真正的问题，并且我们的开发人员始终会审查 Python 规则提出的问题，以确保它们是准确且相关的。他们还通过商业支持渠道收到来自我们社区的报告。

不包括通过分析引擎更新修复的所有 FP，我们的开发人员在 SonarQube 9.9 LTS 中解决了31 个特定的误报！

新规则

回到基础

有时，我们很容易过于关注令人印象深刻的新规则，以至于退一步，我们发现有一些不太复杂（但仍然重要）的规则需要实施！

SonarQube 9.9 LTS 带来了其他 linter 通常提供的九个规则，例如跟踪 TODO 标签并确保每个文件中包含版权/许可证标头。

您可以在此处找到这些规则的完整列表。

编写干净且无错误的正则表达式

正则表达式 (regex) 是符号和字符的序列，表示要在较长文本中搜索的字符串或模式。正则表达式是一个令人难以置信的工具，可以表达条件，否则需要很多行代码才能捕获相同的模式。

虽然如今使用正则表达式对于开发人员来说非常常见，但这并不容易处理。编写正则表达式很容易出错且耗时，而且很难很好地记录它们。一旦编写完成，识别其中的错误可能非常困难。

它们不仅难以编写，而且由于其大小和复杂性，通常难以阅读和理解。

举个例子：

pattern = re.compile(		r'[a-z\:\//\.]+(youtube|youtu)\.(com|be)/(watch\?v=|embed/|.+\?v=)?([^"&?\s]{11})?')

此正则表达式旨在匹配类似https://www.youtu.be/watch?v=dQw4w9WgXcQ和 的URLhttps://www.youtube.com/embed/dQw4w9WgXcQ

此正则表达式中的第三个捕获组是(watch\?v=|embed/|.+\?v=)?考虑 URL 格式的变化。您可能没有注意到此捕获组中的第三个替代方案.+\?v=是多余的，因为它已在第一个替代方案中涵盖watch\?v=，并且永远不会应用于/embed/URL。

因此，可以通过删除多余的替代组来简化此正则表达式，从而使我们的可读性更好一些：

pattern = re.compile(		r'[a-z\:\//\.]+(youtube|youtu)\.(com|be)/(watch\?v=|embed/)?([^"&?\s]{11})?')

对于开发人员来说，自己很难发现这一点。对于 SonarQube 来说一点也不难。

在 SonarQube 9.9 LTS 中，我们的开发人员引入了21 条新规则来帮助 Python 开发人员编写高效、无错误、安全且不太复杂的正则表达式！您可以在rules.sonarsource.com找到与正则表达式相关的所有Python 规则。

编写更好的单元测试

如果您使用unittest或pytest框架来编写 Python 单元测试，那么您很幸运，因为 SonarQube 9.9 LTS 添加了专门与分析测试代码相关的规则。 

请参阅此处的所有规则。

使用针对 AWS CDK 的规则构建安全的 AWS 基础设施

越来越多的开发人员使用AWS CDK来描述他们的 AWS 基础设施，将编程语言的灵活性与云基础设施的复杂性结合起来。

CDK 提供了预配置且经过经验测试的默认值，但模式和结构的创建仍然可能导致安全配置错误。

SonarQube 9.9 LTS 提供了19 条规则来提高用 Python 编写的 AWS CDK 代码的安全热点，以确保您的 IaC 与源代码一样安全。

新的错误检测规则通过符号执行跟踪数据流

SonarQube 9.9 LTS 添加了对 使用符号执行检测高级 Python 错误的支持。

符号执行引擎的目的是访问所有可行的执行路径，甚至跨方法调用，以查找源代码中棘手的错误。

考虑下面的代码：

def hello(name):  print("Hello " + name.upper())def foo():
  name = None
  hello(name) # Triggers an AttributeError

None在此示例中，变量在函数中初始化，其值在另一个函数中使用。None访问的属性会触发AttributeError. 

这是一个更复杂的示例：

def get_field(space, w_node, name, optional):
    w_obj = w_node.getdictvalue(space, name)
    if w_obj is None:        if not optional:            raise oefmt(space.w_TypeError,                "required field \"%s\" missing from %T", name, w_node)
        w_obj = space.w_None
    return w_obj@staticmethoddef from_object(space, w_node):
    w_n = get_field(space, w_node, 'n', False)
    w_lineno = get_field(space, w_node, 'lineno', False)
    w_col_offset = get_field(space, w_node, 'col_offset', False)
    _n = w_n
    if _n is None:
      raise_required_value(space, w_node, 'n') # Noncompliant

这里发生了很多事情：

• _n 是一个别名 w_n

• 鉴于 get_field  call 的第四个参数是 False , 并且 w_obj  将为 None，将会引发异常，因此不会有返回值 get_field

• 现在，唯一可能的返回值 get_field  必须不同于 None

• 因此，条件 _n is None 始终为 False，并且某些后续代码永远不会被评估。

此类错误非常常见，并且很难自行解决。SonarQube 9.9 LTS 现在在这些情况下提出了问题，共有九个规则检测类似的复杂错误。

这些规则可在 SonarQube 的商业版本中找到。