Semgrep 静的解析

セキュリティスキャンとカスタムルール作成のための高速なパターンベースの静的解析。

利用可能な MCP ツール

ご利用の環境で Semgrep MCP ツールが利用可能な場合は、スキャンに優先的に使用してください:

• semgrep_scan — 組み込みルールセットを使用して、コードファイルのセキュリティ脆弱性をスキャンします。絶対ファイルパスと、オプションの設定（例: p/security-audit、auto）を指定してください。
• semgrep_scan_with_custom_rule — 作成したカスタム YAML ルールを使用してコードをスキャンします。コードコンテンツとルールをインラインで指定してください。
• semgrep_findings — Semgrep AppSec Platform からリポジトリの既存の検出結果を取得します。
• semgrep_rule_schema — Semgrep ルール作成用の完全なスキーマを取得します。
• get_supported_languages — Semgrep がサポートするすべての言語をリストします。

MCP ツールが利用できない場合は、以下の CLI コマンドにフォールバックしてください。

Semgrep を使用する場合

理想的なシナリオ:

• 高速なセキュリティスキャン（時間ではなく分単位）
• パターンベースのバグおよび脆弱性検出
• コーディング標準とベストプラクティスの強制
• 既知の脆弱性パターンの検出（OWASP、CWE）
• コードベース用のカスタム検出ルール作成
• Taint モードを使用したデータフロー解析

インストール（CLI）

# pip（推奨）
python3 -m pip install semgrep

# Homebrew
brew install semgrep

# Docker
docker run --rm -v "${PWD}:/src" semgrep/semgrep semgrep --config auto /src

---

パート 1: スキャンの実行

クイックスキャン

semgrep --config auto .                    # ルールを自動検出

ルールセットの使用

semgrep --config p/<RULESET> .             # 単一ルールセット
semgrep --config p/security-audit --config p/trailofbits .  # 複数

ルールセット	説明
p/default	一般的なセキュリティとコード品質
p/security-audit	包括的なセキュリティルール
p/owasp-top-ten	OWASP Top 10 脆弱性
p/cwe-top-25	CWE Top 25 脆弱性
p/trailofbits	Trail of Bits セキュリティルール
p/python	Python 固有
p/javascript	JavaScript 固有
p/golang	Go 固有

出力形式

semgrep --config p/security-audit --sarif -o results.sarif .   # SARIF
semgrep --config p/security-audit --json -o results.json .     # JSON

特定のパスをスキャン

semgrep --config p/python app.py           # 単一ファイル
semgrep --config p/javascript src/         # ディレクトリ
semgrep --config auto --include='**/test/**' .  # テストを含める

設定

.semgrepignore

tests/fixtures/
**/testdata/
generated/
vendor/
node_modules/

誤検知の抑制

password = get_from_vault()  # nosemgrep: hardcoded-password
dangerous_but_safe()  # nosemgrep

---

パート 2: カスタムルールの作成

カスタムルールを作成する場合

• プロジェクト固有の脆弱性パターンを検出する
• 内部コーディング標準を強制する
• カスタムフレームワーク用のセキュリティチェックを構築する
• データフロー解析用の Taint モードルールを作成する

アプローチの選択

アプローチ	使用時期
Taint モード	信頼できないソースから危険なシンク（インジェクション脆弱性）へデータが流れる場合
パターンマッチング	データフロー要件のない構文パターン（非推奨 API、ハードコードされた値）

インジェクション脆弱性には Taint モードを優先してください。 パターンマッチングだけでは、eval(user_input)（脆弱）とeval("safe_literal")（安全）を区別できません。

クイックスタート: パターンマッチング

rules:
  - id: hardcoded-password
    languages: [python]
    message: "Hardcoded password detected: $PASSWORD"
    severity: ERROR
    pattern: password = "$PASSWORD"

クイックスタート: Taint モード

rules:
  - id: command-injection
    languages: [python]
    message: User input flows to command execution
    severity: ERROR
    mode: taint
    pattern-sources:
      - pattern: request.args.get(...)
      - pattern: request.form[...]
    pattern-sinks:
      - pattern: os.system(...)
      - pattern: subprocess.call($CMD, shell=True, ...)
    pattern-sanitizers:
      - pattern: shlex.quote(...)

パターン構文クイックリファレンス

構文	説明	例
...	任意のものにマッチ	func(...)
$VAR	メタ変数をキャプチャ	$FUNC($INPUT)
<... ...>	深い式マッチ	<... user_input ...>

オペレータ	説明
pattern	正確なパターンにマッチ
patterns	すべてがマッチ（AND）
pattern-either	任意がマッチ（OR）
pattern-not	マッチを除外
pattern-inside	コンテキスト内のみマッチ
pattern-not-inside	コンテキスト外のみマッチ
metavariable-regex	キャプチャされた値に対する正規表現

ルールのテスト

テストファースト必須。 アノテーション付きのテストファイルを作成します:

# test_rule.py
def test_vulnerable():
    user_input = request.args.get("id")
    # ruleid: my-rule-id
    cursor.execute("SELECT * FROM users WHERE id = " + user_input)

def test_safe():
    user_input = request.args.get("id")
    # ok: my-rule-id
    cursor.execute("SELECT * FROM users WHERE id = ?", (user_input,))

テストを実行:

semgrep --test --config rule.yaml test-file

コマンドリファレンス

タスク	コマンド
テストを実行	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

ルール作成ワークフロー

1. 問題を分析する — バグパターンを理解し、Taint とパターンのどちらのアプローチかを判定する
2. 最初にテストケースを作成する — ルールの前に ruleid: と ok: アノテーションを書く
3. AST を分析する — semgrep --dump-ast を実行してコード構造を理解する
4. ルールを書く — シンプルに始めて、反復する
5. 100% パスするまでテストする — 「見落とした行」や「間違った行」がないことを確認する
6. パターンを最適化する — テストがパスした後でのみ冗長性を削除する

出力構造:

<rule-id>/
├── <rule-id>.yaml     # Semgrep ルール
└── <rule-id>.<ext>    # テストファイル

詳細リファレンス

公式 Semgrep ドキュメント:

• ルール構文 — 完全な YAML 構造、オペレータ、オプション
• ルールスキーマ — 完全な JSON スキーマ仕様

避けるべきアンチパターン

範囲が広すぎる:

# 悪い例: 任意の関数呼び出しにマッチ
pattern: $FUNC(...)

# 良い例: 特定の危険な関数
pattern: eval(...)

安全なケースが不足:

# 悪い例: 脆弱なケースのみテスト
# ruleid: my-rule
dangerous(user_input)

# 良い例: 安全なケースを含める
# ruleid: my-rule
dangerous(user_input)

# ok: my-rule
dangerous(sanitize(user_input))

拒否すべき正当化

ショートカット	間違っている理由
「Semgrep は何も見つからなかった。コードは安全だ」	Semgrep はパターンベース。複雑な関数間のデータフローは追跡できない
「パターンが完全に見えます」	テストされていないルールには隠れた誤検知/見落としがある
「脆弱なケースにマッチします」	脆弱性の検出はタスクの半分。安全なケースがマッチしないことを確認する
「Taint モードはやり過ぎです」	インジェクション脆弱性については、Taint モードがより高い精度を提供する
「テストケース 1 つで十分です」	エッジケースを含める: 異なるコーディングスタイル、サニタイズされた入力、安全な代替案

---

CI/CD インテグレーション

GitHub Actions

name: Semgrep

on:
  push:
    branches: [main]
  pull_request:
  schedule:
    - cron: '0 0 1 * *'

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: returntocorp/semgrep

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run Semgrep
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            semgrep ci --baseline-commit ${{ github.event.pull_request.base.sha }}
          else
            semgrep ci
          fi
        env:
          SEMGREP_RULES: >-
            p/security-audit
            p/owasp-top-ten
            p/trailofbits

---

リソース

• ルール構文: https://semgrep.dev/docs/writing-rules/rule-syntax
• パターン構文: https://semgrep.dev/docs/writing-rules/pattern-syntax
• レジストリ: https://semgrep.dev/explore
• プレイグラウンド: https://semgrep.dev/playground
• ドキュメント: https://semgrep.dev/docs/