[Proposal] semgrep scan レイヤー復活 — カスタムルールによる FP フリーの静的セキュリティチェック

[code-sandbox-mcp]

Written by: OpenCode (DeepSeek V4 Flash)

Context

scan (semgrep) レイヤーは #257 / #267 で設計上削除され、#326 で残存コードも除去された。

削除理由（#267 より）:

• semgrep の結果は edit ループではノイズになることが多く、利用実績がほぼなかった
• セキュリティスキャンは CI や専用ツールに委ねる方が適切
• verify の責務をテストに集中させることで設計を明確化

しかし、これらの判断は semgrep を p/python + p/security-audit の公式ルールセットで使った場合の話。カスタムルール 5-6 個に絞れば FP はほぼゼロになる可能性がある。

動作検証結果

semgrep v1.170.0 でカスタムルール 10 個をテスト。

結果: 9/9 脆弱性を検出（pickle.load, yaml.load, eval, exec, os.system, subprocess+shell=True）、0 FP。
セーフパターン（pickle.loads, yaml.safe_load, subprocess shell=False）は正しく未検出。

判明した制約

項目	結果
カスタムルール (pattern:/pattern-not:)	正常動作
公式 semgrep-rules (develop) の patterns: リスト形式	v1.170.0 と非互換で 0 findings
pattern-not 内の ...	一部ケースで期待通り機能しない場合あり

Decision Drivers

1. セキュリティの予防: CI より edit→verify ループ内検出の方がフィードバックが早い
2. ノイズ除去: 公式ルールセット丸ごとでなく必要なルールだけ選ぶ
3. 低メンテナンス: ルール 5-6 個で十分、メンテナンスコストはほぼゼロ

Considered Options

• Option 1: verify_in_container に scan オプション追加（デフォルト off）。カスタムルールのみ使用。
• Option 2: 独立した scan_in_container ツールとして追加。lint/type_check と同列。
• Option 3: 現状維持（削除状態を継続）。

Decision Outcome

未確定（本 issue で議論）。