Semgrep ルール バリアント クリエイター

既存の Semgrep ルールを新しいターゲット言語にポートします。適用可能性の分析とテスト駆動型の検証を含みます。

使用するべき場面

理想的なシナリオ:

• 既存の Semgrep ルールを 1 つ以上のターゲット言語にポートする場合
• 汎用の脆弱性パターンの言語固有バリアントを作成する場合
• ポリグロット コードベース全体でルール カバレッジを拡大する場合
• 等価な構造を持つ言語間でルールを変換する場合

使用してはいけない場面

次の場合はこのスキルを使用しないでください:

• 新しい Semgrep ルールを最初から作成する場合 (semgrep-rule-creator を使用してください)
• 既存のルールをコードに対して実行する場合
• 脆弱性パターンが根本的に適用されない言語
• 同一言語内での軽微な構文の違い

入力仕様

このスキルに必要な入力:

1. 既存の Semgrep ルール - YAML ファイルパスまたは YAML ルール コンテンツ
2. ターゲット言語 - ポート先の 1 つ以上の言語 (例: "Golang と Java")

出力仕様

適用可能な各ターゲット言語に対して、以下を生成します:

<original-rule-id>-<language>/
├── <original-rule-id>-<language>.yaml     # ポート済み Semgrep ルール
└── <original-rule-id>-<language>.<ext>    # アノテーション付きテスト ファイル

sql-injection を Go と Java にポートする場合の出力例:

sql-injection-golang/
├── sql-injection-golang.yaml
└── sql-injection-golang.go

sql-injection-java/
├── sql-injection-java.yaml
└── sql-injection-java.java

却下すべき論理的根拠

Semgrep ルールをポートする際、以下の一般的なショートカットは却下してください:

論理的根拠	失敗する理由	正しいアプローチ
「パターン構造は同じ」	言語によって AST が異なる	常にターゲット言語の AST をダンプする
「同じ脆弱性、同じ検出」	データフローは言語間で異なる	ターゲット言語のイディオムを分析する
「ルールはテストを必要としない (オリジナルは機能した)」	言語のエッジケースは異なる	ターゲット用の新しいテストケースを作成する
「適用可能性をスキップする - 明らかに適用される」	一部のパターンは言語固有	最初に完全な適用可能性分析を行う
「すべてのバリアントを作成してからテストする」	エラーが複合し、デバッグが困難になる	言語ごとに完全なサイクルを完了する
「ライブラリ相当は十分に似ている」	表面的な類似性は相違点を隠している	API のセマンティクスが一致することを検証する
「構文を 1 対 1 で変換するだけ」	言語は異なるイディオムを持っている	ターゲット言語のパターンを研究する

厳格性レベル

このワークフローは 厳格 です - ステップをスキップしないでください:

• 適用可能性分析は必須: パターンが変換されると仮定しないでください
• 各言語は独立: 次の言語に進む前に完全なサイクルを完了してください
• 各バリアントのテストファースト: テストケースなしでルールを書かないでください
• 100% テスト合格が必須: 「ほとんどのテストが合格」は受け入れられません

概要

このスキルは、既存の Semgrep ルールの言語固有バリアントの作成をガイドします。各ターゲット言語は独立した 4 フェーズ サイクルを通過します:

各ターゲット言語について:
  フェーズ 1: 適用可能性分析 → 判定
  フェーズ 2: テスト作成 (テストファースト)
  フェーズ 3: ルール作成
  フェーズ 4: 検証
  (次の言語に移る前に完全なサイクルを完了)

基礎知識

semgrep-rule-creator スキルは Semgrep ルール作成の基礎の権威あるリファレンスです。 このスキルは既存のルールを新しい言語にポートすることに焦点を当てていますが、品質の高いルール作成の核となる原則は変わりません。

以下のガイダンスについては semgrep-rule-creator を参照してください:

• Taint モード対パターン マッチング - 脆弱性の種類に適したアプローチの選択
• テストファースト方法論 - テストがルールより先に来る理由と効果的なテストケースの書き方
• 回避すべきアンチパターン - 過度に広いパターンや過度に具体的なパターンなどの一般的な間違い
• テストが合格するまでの反復 - 検証ループとデバッグ技術
• ルール最適化 - テスト合格後の冗長パターンの削除

ルールをポートする際、これらの同じ原則を新しい言語コンテキストで適用しています。ルール構造またはアプローチについて不確実な場合は、まず semgrep-rule-creator を参照してください。

4 フェーズ ワークフロー

フェーズ 1: 適用可能性分析

ポートする前に、パターンがターゲット言語に適用されるかどうかを判定します。

分析基準:

1. ターゲット言語に脆弱性クラスが存在するか?
2. 等価な構造 (関数、パターン、ライブラリ) が存在するか?
3. セマンティクスは意味のある検出のために十分に類似しているか?

判定オプション:

• APPLICABLE → バリアント作成に進む
• APPLICABLE_WITH_ADAPTATION → 進めるが大きな変更が必要
• NOT_APPLICABLE → この言語をスキップし、理由を文書化する

詳細なガイダンスについては applicability-analysis.md を参照してください。

フェーズ 2: テスト作成 (テストファースト)

常にルールの前にテストを作成してください。

ターゲット言語のイディオムを含むテスト ファイルを作成します:

• 最小 2 つの脆弱なケース (ruleid:)
• 最小 2 つの安全なケース (ok:)
• 言語固有のエッジケースを含める

// ruleid: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = " + userInput)

// ok: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = ?", userInput)

フェーズ 3: ルール作成

1. AST を分析: semgrep --dump-ast -l <lang> test-file
2. パターンを翻訳 してターゲット言語の構文に合わせる
3. メタデータを更新: language キー、メッセージ、ルール ID
4. イディオムに適応: 言語固有の構造を処理する

翻訳ガイダンスについては language-syntax-guide.md を参照してください。

フェーズ 4: 検証

# YAML を検証
semgrep --validate --config rule.yaml

# テストを実行
semgrep --test --config rule.yaml test-file

チェックポイント: 出力は All tests passed を表示しなければいけません。

Taint ルールのデバッグの場合:

semgrep --dataflow-traces -f rule.yaml test-file

詳細なワークフローとトラブルシューティングについては workflow.md を参照してください。

クイック リファレンス

タスク	コマンド
テストを実行	semgrep --test --config rule.yaml test-file
YAML を検証	semgrep --validate --config rule.yaml
AST をダンプ	semgrep --dump-ast -l <lang> <file>
Taint フローをデバッグ	semgrep --dataflow-traces -f rule.yaml file

ルール作成との主な相違点

側面	semgrep-rule-creator	このスキル
入力	バグ パターンの説明	既存ルール + ターゲット言語
出力	単一のルール+テスト	複数のルール+テスト ディレクトリ
ワークフロー	単一の作成サイクル	言語ごとの独立したサイクル
フェーズ 1	問題分析	言語ごとの適用可能性分析
ライブラリ調査	常に関連	オプション (オリジナルがライブラリを使用する場合)

ドキュメント

必須: ルールをポートする前に、関連する Semgrep ドキュメントを読んでください:

• Rule Syntax - YAML 構造とオペレーター
• Pattern Syntax - パターン マッチングと メタ変数
• Pattern Examples - 言語ごとのパターン リファレンス
• Testing Rules - テスト アノテーション
• Trail of Bits Testing Handbook - 高度なパターン

次のステップ

• 適用可能性分析のガイダンスについては、applicability-analysis.md を参照してください
• 言語翻訳のガイダンスについては、language-syntax-guide.md を参照してください
• 詳細なワークフローと例については、workflow.md を参照してください