Semgrep 规则

这是中央 Semgrep 规则仓库，托管用于 GitLab semgrep 分析器 的 Semgrep 规则。

仓库结构如下：

.
├── mappings
│   ├── find_sec_bugs.yml
│   ├── eslint.yml
│   └── ...
├── rules
│   ├── lpgl
│   │   ├── java
│   │   │   ├── webview
│   │   │   │   ├── rule-ignore_ssl_certificate_error.yml
│   │   │   │   ├── rule-ignore_ssl_certificate_error.java
│   │   │   │   └── ...
│   │   │   └── ...
│   │   ├── python
│   │   │   └── ...
│   │   └── ...
│   ├── lpgl-cc
│   │   ├── java
│   │   │   └── ...
│   │   └── ...
│   └── ...
├── c
│   ├── buffer
│   │   ├── rule-strcpy.yml
│   │   ├── test-strcpy.c
│   │   ├── rule-memcpy.yml
│   │   └── test-memcpy.c
│   └── ...
└── javascript
│   └── ...
└── ...

上述结构遵循以下模式：

rules/<license>/<language>/<ruleclass>/rule-<rulename>\.(yml|<ext>)

其中：

1. <license> 是下方所有规则的许可证
2. <language> 目标编程语言
3. <ruleclass> 规则类别的描述性名称
4. <rulename> 规则本身的描述性名称
5. <ext> <language> 的常用文件扩展名

较旧的规则遵循 <language>/<ruleclass>/rule-... 模式，在可能的情况下应优先使用上述较新的模式。

mappings 目录包含规则包配置。

Makefile

Makefile 定义了一些在规则工作时有用的目标：

$ make help
TARGETS:
  test                  test all rules with Semgrep
  watch                 watch for file changes and auto-run affected tests
  help                  prints this message

格式化指南

本仓库中的规则必须遵循以下格式：

• 字符串使用 "，否则使用 YAML 文字块 |
• 不折叠数组元素
• 最大行长度/文字宽度：100 个字符
• 缩进：2 个空格
• 每条规则都必须有对应的测试用例
• 如果提供，规则文件顶部需要有注释部分
• 每个 YAML 文件以 --- 开头

映射

本仓库中的 mappings 目录包含 YAML 配置文件，用于将原生分析器 ID（例如 Bandit、Brakeman 等）映射到相应的 Semgrep 规则。

映射文件的目的主要是将分析器特定的信息与实际的规则分离，其次是以一种非侵入性的方式生成用于不同目的的规则包或规则集（跨语言或分析器边界）。

映射文件位于 mappings/ 目录下，文件名指向由该文件中使用的规则集所代表的规则包和/或分析器。如果你希望规则包含在 GitLab 标准规则集中，并且该规则不属于 mappings/ 目录中已有的规则包（或分析器），你可以将映射添加到 mappings/gitlab_<license>_<language>.yml 文件中，其中 <license> 是由规则来源决定的合适许可证，<language> 是规则所指语言的占位符。

如果你想集成一条从头开始开发的新规则，可以将相应的映射添加到 mappings/gitlab_ee_<language>.yml 文件中。在决定你映射的特定规则应适用哪种许可证时，请参考此内部指南。

映射也用于自动组装规则包。下面的代码片段展示了 bandit 分析器的映射文件示例。native_id 部分包含有关原生分析器 ID 的一些信息，即原始分析器（此处为 bandit）附加到其发现结果上的元信息。实际的规则映射在 mappings 部分定义。每个映射将原生分析器规则 ID（下面的示例中为 B301）映射到本仓库中一组与特定原生规则相似或理想情况下等效的 semgrep 文件。

bandit:
  native_id:
    type: "bandit_test_id"
    name: "Bandit Test ID: $ID"
    value: "$ID"
  mappings:
  - id: "B301"
    rules:
    - path: "python/deserialization/rule-pickle"
      primary_id: "bandit.B301-1"
      id: "bandit.B301-1"
    - path: "python/deserialization/rule-cpickle"
      primary_id: "bandit.B301-2"
      id: "bandit.B301-2"
    - path: "python/deserialization/rule-dill"
      primary_id: "bandit.B301-3"
      id: "bandit.B301-3"
    - path: "python/deserialization/rule-shelve"
      primary_id: "bandit.B301-4"
      id: "bandit.B301-4"
  # ...

映射文件的详细结构说明如下。

1. id 用于在对应于映射文件的 semgrep 规则包中生成稳定且唯一的 semgrep 规则标识符。
2. primary_id 有助于生成稳定的漏洞主标识符，这些标识符在由 GitLab Semgrep 分析器 生成漏洞时附加到漏洞上（在 gl-sast-report.json 中），用于去重目的。
3. native_id 是精确匹配原生分析器生成的漏洞标识符结构的条目。该条目将被添加到由 GitLab Semgrep 分析器 生成的 gl-sast-report.json 中，并在漏洞报告中可用。
4. mappings 包含原生分析器 ID（上述情况中的 B301 指的是 python 分析器 bandit 的规则之一）。rules 数组指向仓库中该规则所指的文件。换句话说，B301 的逻辑体现在上述代码片段中列出的四个文件中。

我们使用两种不同类型的标识符 id 和 primary_id 来支持规则拆分：多个 semgrep 规则（id）可以映射到单个原生分析器的规则（primary_id）。

数据来源

本仓库中的规则和测试用例部分来源于以下列表中的来源：

1. https://github.com/returntocorp/semgrep-rules
2. https://github.com/PyCQA/bandit
3. https://github.com/nodesecurity/eslint-plugin-security
4. https://github.com/jsx-eslint/eslint-plugin-react
5. https://github.com/david-a-wheeler/flawfinder/blob/master/flawfinder.py

详细信息（包括许可信息和适当的归属）列于所有规则和测试文件的头部。

贡献

如果你知道本仓库中尚未包含的模式，或者可以对本仓库中的规则进行改进，你可以通过提出 issue 来贡献力量，甚至可以直接提交对规则文件/测试用例的改进。

版本控制

我们对此仓库采用以下语义化版本控制方案：

1. 补丁版本递增：用于更新/修补/添加规则。
2. 次版本递增：向后兼容的 YAML schema 变更（例如，添加/删除可选字段）。
3. 主版本递增：不向后兼容的 YAML schema 变更（例如，添加/删除必需字段）。

SAST 规则发布流程

新的 SAST 规则发布必须整合到 semgrep 分析器 中才能生效。要请求新的 semgrep 发布，请使用 SAST 发布问题模板 中的说明创建一个发布问题。

致谢

我们非常感谢以下作者所做的宝贵贡献。