35条新增Semgrep规则：基础设施、供应链和Ruby

我们发布了又一组自定义Semgrep规则，使我们的公共规则总数达到115条。本篇博客将简要介绍新规则，然后深入探讨两个Semgrep功能：正则模式（特别是与通用模式的对比）以及对Terraform和Nomad等技术的HCL语言支持。借助这些功能，我们可以在不仅仅是应用程序代码中搜索安全漏洞。这次新发布加入了我们现有的Semgrep规则集、公共CodeQL查询和测试手册，作为我们长期努力与安全社区分享技术专长的一部分。

Semgrep是一个功能强大的工具，包含许多可以利用的角落和缝隙，以从静态分析工具中获得最大价值。与我们之前的Semgrep规则发布帖子一样，本文将重点介绍一些有趣的Semgrep功能。公开发布规则是一个很好的开始，但我们觉得通过解释规则为何如此编写，我们可以做得更好。

对于这次发布，我们重点关注了与GitHub Actions中缺乏短期OIDC令牌相关的供应链问题；Terraform代码中的基础设施问题、Nomad作业和不安全的数据库连接；以及Ruby代码中的一般应用安全问题。这些Ruby规则中的许多是在我们最近的Ruby Central（rubygems.org）审计期间编写的。我们将在不久后发布有关此次审计的更多信息。

事不宜迟，以下是我们新增的规则：

Semgrep不仅仅适用于编程语言

本系列的第一篇文章包括对两个较少为人知的Semgrep功能的观点：通用模式和YAML支持。本文介绍了另外两个考虑因素：正则表达式与通用模式以及用于基础设施即代码（IaC）安全的HashiCorp配置语言（HCL）支持。我们将继续将Semgrep应用于所有形式的文本数据的趋势。

启发式：正则表达式与通用模式

正则表达式模式是Semgrep的另一个较少为人知的功能。这就是所谓的pattern-regex操作符和regex语言。但为什么你会在Semgrep规则中使用正则表达式呢？这难道不是违背了像Semgrep这样的静态分析工具的目的吗？为什么不直接使用ripgrep或经典的grep呢？通用模式不是使regex模式变得多余吗？

以下启发式将帮助你理解何时使用regex模式。你对以下问题的“是”回答越多，你就越应该使用regex模式。

启发式#1：你正在寻找的文本通常跨越单行代码吗？

在正则表达式中处理多行空白是很痛苦的。如果你发现自己正在搜索多行模式，并且无法使用特定语言的规则，那么通用模式可能是最好的选择。所以请记住：当使用regex模式时，你正在搜索的文本几乎总是跨越单行。

启发式#2：这种模式存在于多种语言或类型的文本文件中吗？

Semgrep的美妙之处在于它是一个一站式商店，适用于所有文本分析。如果你正在搜索的文本可能存在于多种语言中，那么它可能适合regex模式。例如，考虑URL参数。如果你正在搜索，比如，sslmode=disable，那么以下正则表达式将是一个好的开始：[?&]sslmode=(disable|allow|prefer)。这很棒，因为它将在任何语言中的任何PostgreSQL库的任何连接URI中找到这个不安全的URL参数。我们不必为不同的库和语言编写单独的规则。它还会在shell脚本、文档、CI作业等中找到这种模式。

启发式#3：你想与他人分享你的正则表达式吗？

再次，Semgrep的美妙之处在于它将ripgrep或经典grep等工具的功能整合到一个工具下。当你快速迭代正则表达式并在代码中搜索模式时，ripgrep可能很有用，但一旦到了编纂、测试和发布正则表达式的时候，Semgrep规则就真正闪耀了。你的正则表达式发现将存在于你的Python和Kubernetes发现旁边，你可以从一个位置跟踪所有发现并管理规则。

启发式#4：你需要匹配特定字符或字符类吗？

Regex模式和通用模式通常服务于类似的需求。我们之前的帖子讨论了通用模式的优势，那么你何时应该使用regex模式？当你想要匹配特定字符或字符类，或使用其他正则表达式功能（如交替）时，regex模式优于通用模式。例如，在上面的sslmode正则表达式中，我们搜索由字符类?和&前缀的sslmode。这两个前缀使我们更加确信我们找到的实际上是一个URL参数。据我们所知，在通用模式中没有简单的方法来表达这一点。我们总是可以使用pattern-either，但对于更复杂的表达式来说，这可能会变得非常冗长。另一方面，通用模式的主要优势是它支持省略号操作符（即…），这允许轻松跳过不匹配的元素和用于多行模式的空白。

如你所见，通常有多种方法可以在Semgrep中搜索特定的代码模式。上述启发式为你可能想要使用regex模式时提供了一个良好的基线。更重要的考虑是regex模式存在，并且它是你在搜索文本数据时工具带中的一个宝贵工具。

HCL支持和IaC安全

基础设施即代码（IaC）已经改变了云管理。它通过版本控制环境带来了更快的部署、改进的一致性和可重复性，以及更好的安全性，这些环境以前依赖于手动配置。通过将基础设施编码化，组织可以将这些定义与CI/CD管道无缝集成，从而实现自动化测试、部署和静态分析。

HashiCorp配置语言（HCL）是许多IaC工具的基础，包括Terraform、Nomad和Consul。认识到IaC日益增长的重要性，Semgrep早在2021年就引入了HCL支持。通过专用的HCL支持，Semgrep现在允许采用统一的方法，将相同水平的审查应用于应用程序代码和基础设施配置，确保它们在CI/CD管道中和谐地工作。

我们了解到，即使是最直接的Semgrep规则也可以发现2024年仍然构成风险的重大问题。以在开发期间禁用TLS验证的常见做法为例。如果此配置被无意中部署，它可能会暴露敏感数据。以下是如何使用Semgrep在Vault基础设施中轻松检测此类漏洞：

1
2
3
4
5
6
7
8
9

rules:
  - id: vault-skip-tls-verify
    message: |
      Found Terraform Vault instance with TLS verification disabled
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: provider "vault" { ... }
      - pattern: skip_tls_verify = true

图1：搜索禁用TLS验证的Semgrep规则（hcl/terraform/vault-skip-tls-verify.yaml）

另一个常见的错误是硬编码凭据——Semgrep可以轻松捕捉的安全风险：

1
2
3
4
5
6
7
8
9

rules:
  - id: vault-hardcoded-token
    message: |
      Found Terraform Vault instance with hardcoded token
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: provider "vault" { ... }
      - pattern: token = "..."

图2：搜索硬编码Vault令牌的Semgrep规则（hcl/terraform/vault-hardcoded-token.yaml）

通过将此步骤与配置你的CI/CD管道以阻止具有未解决Semgrep发现的PR（我们的推荐实践之一）相结合，你可以轻松地将这些问题排除在生产基础设施之外。

HCL的结构化性质也使其特别有效地检测更复杂的模式，并确保我们将误报率尽可能低。例如，考虑以下规则，该规则识别缺少OIDC主题的GitHub Actions的AWS角色策略——一个关键的错误配置，可能允许任何GitHub仓库在CI中承担该角色：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

rules:
  - id: aws-oidc-role-policy-missing-sub
    message: |
      Found AWS role policy for GitHub Actions missing OIDC subject. This
      means any GitHub repository can assume this role in CI.
    languages: [hcl]
    severity: WARNING
    patterns:
      - pattern-inside: |
          {
            ...
            Statement = [...]
            ...
          }
      - pattern-inside: |
          {
            ...,
            "Action": "sts:AssumeRoleWithWebIdentity",
            ...
          }
      - pattern: |
          {
            ...
            "Condition": {
                ...
                "StringEquals": {
                    ...
                    "token.actions.githubusercontent.com:aud": ...,
                    ...
                }
                ...
            }
            ...
          }
      - pattern-not: |
          {
            ...
            "Condition": {
                ...
                "StringEquals": {
                    ...
                    "token.actions.githubusercontent.com:sub": ...,
                    ...
                    "token.actions.githubusercontent.com:aud": ...,
                    ...
                }
                ...
            }
            ...
          }
      # 剩余pattern-not被截断以节省空间

图3：搜索缺少OIDC主题的Semgrep规则（hcl/terraform/aws-oidc-role-policy-missing-sub.yaml）

GitHub Actions的角色策略可以通过多种方式配置，我们可以使用pattern-inside和pattern-not来正确上下文化我们正在寻找的模式（即，未定义主题的实例）。此规则是一个强大的例子，说明Semgrep如何帮助强制执行安全策略并防止可能导致严重漏洞的配置错误。

文本是通用接口

如果文本是通用接口，那么Semgrep可以帮助保护任意接口，从字节和字符串到IaC、YAML等。将Semgrep的力量与正则表达式、通用模式、YAML和IaC支持相结合，使我们能够超越编程语言中的代码。随着行业将所有内容转向“即代码”解决方案，我们需要能够将可扩展的工具应用于供应链、CI/CD和IaC等领域。

通过IaC，你可以将静态分析的相同严格性应用于你的基础设施，就像你对应用程序代码一样，早期发现问题并避免生产中的昂贵错误——即所谓的“左移”。针对生产环境的手动审计和动态扫描速度慢且扩展性差。我们鼓励你尝试我们新发布的Terraform和Nomad规则，探索Semgrep的terraform规则，并考虑将它们纳入你的项目中。据我们所知，这些是第一个针对Nomad的开源Semgrep规则——我们很高兴与社区分享这一事实，希望激励其他人在此基础上进行构建。

如果你想了解更多关于我们在Semgrep上的工作，我们以多种方式使用了它的功能，例如保护机器学习管道、发现goroutine泄漏和保护Apollo GraphQL服务器。

如果你对为你的项目定制Semgrep规则感兴趣，请联系我们！

如果你喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 Semgrep不仅仅适用于编程语言 文本是通用接口 近期帖子 构建安全消息传递很难：对Bitchat安全辩论的 nuanced 看法 使用Deptective调查你的依赖项 系好安全带，Buttercup，AIxCC的评分回合正在进行中！ 使你的智能合约成熟超越私钥风险 Go解析器中意想不到的安全隐患 © 2025 Trail of Bits。 使用Hugo和Mainroad主题生成。