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ファイルは --- で始まる

マッピング

このリポジトリのマッピングディレクトリには、ネイティブアナライザID（例：Bandit、Brakemanなど）を対応するSemgrepルールにマッピングするYAML設定ファイルが含まれています。

マッピングファイルの意図は、第一に、アナライザ固有の情報を実際のルールから分離すること、第二に、異なる目的のために（言語やアナライザの境界を越えて）ルールパックやルールセットを生成するための非侵襲的な方法を提供することです。

マッピングファイルは 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のルールの1つを参照）が含まれています。rules 配列は、このルールが参照するリポジトリ内のファイルを指します。言い換えると、B301 のロジックは上記のスニペットにリストされた4つのファイルで実装されています。

ルール分割をサポートするために、id と primary_id の2つの異なるタイプの識別子を使用しています。複数の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スキーマ変更（例：オプションフィールドの追加/削除）。
3. メジャーバージョンのインクリメント：後方互換性のないYAMLスキーマ変更（例：必須フィールドの追加/削除）。

SASTルールのリリースプロセス

新しいSASTルールのリリースは、有効になるためにsemgrepアナライザに組み込まれなければなりません。新しいsemgrepリリースをリクエストするには、SASTリリースIssueテンプレートの指示に従ってリリースIssueを作成してください。

クレジット

以下の著者の皆様の貴重な貢献に深く感謝いたします。