Semgrep detect-non-literal-regexpの誤検知は、到達不能な分岐を型で消して直した

結論

Semgrepのdetect-non-literal-regexpがE2Eテストのnew RegExp(c.path.replace(...))を検知したが、この分岐は実行時に到達しないdead branchだった。 PageCase型のallowUrlをoptionalからrequiredに変え、?? new RegExp(...)というフォールバック式そのものを削除することで、挙動を一切変えずに検知を解消した。

症状

権限マトリクスをロールごとに検証するE2Eテスト（authorization-matrix.spec.ts）に、次のフォールバックがありました。

// 修正前
type PageCase = {
  label: string;
  path: string;
  allow: readonly RoleKey[];
  /** 許可ロールで到達したときに満たすべき URL (省略時は path にそのまま留まる)。 */
  allowUrl?: RegExp;
};

// 修正前
await expect(page).toHaveURL(c.allowUrl ?? new RegExp(c.path.replace(/[/]/g, "\\/")));

このコードが原因で、main ブランチの SAST（Semgrep）が detect-non-literal-regexp の指摘でブロッキングとして赤くなりました。new RegExp(...) に渡す文字列が動的に見えることを検知するルールです。

原因

指摘された new RegExp(c.path.replace(...)) は、c.allowUrl が省略されたときだけ評価されるフォールバック分岐でした。ですが PAGE_CASES に定義されている全エントリは、この修正が入る時点ですでに例外なく allowUrl を宣言しています。つまり c.allowUrl が undefined になるケースが存在せず、?? new RegExp(...) 側は実行時に一度も評価されない dead branch でした。

Semgrepのdetect-non-literal-regexpは、静的解析であるため「この分岐が実行時に到達するかどうか」までは追跡しません。new RegExp(...)という構文だけを見て、渡しているc.pathがテスト内の静的なPAGE_CASES配列から来るコンパイル時のリテラルであることも、その分岐自体が到達不能であることも判断できないため、構文としては非リテラルな正規表現構築だが実害はない箇所として検知していました。

直し方

コード側を変更し、Semgrepが追跡している「非リテラルなnew RegExp」そのものを消しました。

// 修正後
type PageCase = {
  label: string;
  path: string;
  allow: readonly RoleKey[];
  /**
   * 許可ロールで到達したときに満たすべき URL の正規表現 (必須)。各ケースが明示的に宣言する。
   * 以前は optional にし expectPageOutcome で `new RegExp(c.path)` へ動的フォールバックしていたが、
   * PAGE_CASES は全件 allowUrl を持つため当該フォールバックは到達不能 (dead branch) であり、
   * 非リテラル `new RegExp(...)` が Semgrep detect-non-literal-regexp の誤検知を生んでいた。
   */
  allowUrl: RegExp;
};

// 修正後
await expect(page).toHaveURL(c.allowUrl);

allowUrlを必須型に変えたことで、?? new RegExp(...)のフォールバック式自体が不要になり削除できます。Semgrepのルールセットやsemgrep ciの設定は一切変更していません。抑制コメント（# nosemgrep等）も使っていません。ルールを弱めるのではなく、ルールが指摘していたコードそのものを消す方向で解消しています。

再発防止

抑制で直す誘惑はありましたが、抑制は「この1箇所の指摘を黙らせる」だけで、allowUrlの宣言忘れというコード側のリスクは残ります。今回のようにallowUrl?: RegExpをrequiredに変えると、将来PAGE_CASESにallowUrlを書き忘れたエントリを追加しようとした時点でTypeScriptの型検査自体が落ちます。Semgrepの指摘を「静的解析の限界（到達可能性を追跡できない）」として片付けず、その指摘が刺さっている型の緩さそのものを直すことで、検知の解消と将来の宣言漏れ防止を同時に得られました。