Snyk Codeのルール拡張を設定してカスタムサニタイザーをマッピングし、偽陽性アラートを根本解消する

エンタープライズ環境でSnyk Codeによる静的アプリケーションセキュリティテスト（SAST）を展開する際、アプリケーションセキュリティ（AppSec）担当者やセキュリティアーキテクトが直面する最大の課題が、自社内製ライブラリに起因する大量の偽陽性（誤検知）と開発現場のアラート疲れです。Snyk Codeは、AI技術と記号的実行を組み合わせたDeepCodeエンジンを用いて、信頼できないデータが流入する起点（ソース）から危険な処理が実行される終点（シンク）までの汚染データフロー（テイントフロー）をファイル横断で追跡します。

しかし、開発チームが社内共通のセキュリティSDK、入力検証ラッパー、自作のエスケープ関数などを利用している場合、既定の解析エンジンはそれらの独自関数がペイロードを無害化しているかどうかを自動的には判断できません。その結果、本来安全に実装されているコードに対してもSQLインジェクション、クロスサイトスクリプティング（XSS）、パストラバーサルといった深刻な脆弱性アラートが大量に発生してしまいます。

Web UI上での都度無視や、各リポジトリに配置する.snykファイルによる除外に依存する方法は、運用負荷が極めて高く、真の脆弱性を見落とす危険性も孕んでいます。この課題を抜本的に解決するのが、SnykのEnterpriseプランで提供されている**ルール拡張（Rule Extensions）**機能です。自社製関数の完全修飾名（Fully Qualified Name：FQN）を特定のセキュリティルールと結びつけ、適切なサニタイズ動作タイプを定義することで、組織全体で偽陽性を体系的に抑制しながら、本来検出すべきリスクを確実に捉え続けることが可能になります。

テイントフロー分析と偽陽性発生のメカニズム

カスタムサニタイザーを正確に構成するためには、Snyk Codeのテイントフロー分析の基本構造を理解する必要があります。

[ソース (Source): 外部の未検証入力]
       │
       ▼
[自社製セキュリティ検証関数] ──► (ルール拡張未設定の場合、解析エンジンには不透明)
       │
       ▼ (汚染フラグが維持されたまま伝播)
[シンク (Sink): センシティブな実行処理] ──► 偽陽性アラート (False Positive) の発生

1. ソース（Source）：HTTPリクエストパラメータ、ヘッダー、アップロードファイル、外部メッセージキューなど、信頼できないデータがシステムに流入する境界。
2. 伝播経路（Propagation Path）：変数の代入、関数の引数渡し、オブジェクトプロパティの変換などを通じて、データが複数ファイルにわたって移動する経路。
3. サニタイザー（Sanitizer）：危険な文字をエスケープ、除去、またはホワイトリスト検証し、安全なデータへと変換する防御処理。
4. シンク（Sink）：無害化されていないデータを受け取ると重大な被害をもたらす危険な関数やAPI（SQLクエリ実行、DOM描画、ファイルパス解決など）。

標準的なSASTルールは、言語標準ライブラリや一般的なOSSフレームワークのサニタイザーしか把握していません。そのため、企業独自の安全クラス（例：MyOrg.Security.Encoder.CleanHtml や PathValidator.assertSafePath）を経由しても、エンジンは「汚染が継続している」と判断し、シンクに到達した時点でアラートを出力します。

従来の個別対応が破綻する理由

• Web UIでの手動無視：既存のスキャン結果に対してのみ有効であり、新規リポジトリの導入や別ブランチでのPR作成時に同一コードパターンで再びアラートが発生します。
• リポジトリごとの.snykファイル：多数のリポジトリに分散して管理が煩雑化し、開発者が広範なワイルドカード除外を設定して重大な脆弱性を覆い隠してしまうリスクが生じます。
• ルールの全面無効化：開発チームからの不満を解消するためにルール自体（XSSチェック全般など）をオフにすると、深刻なセキュリティホールを見過ごすことになります。

ルール拡張を利用すれば、エンジンレベルで自社関数を正当なサニタイザーとして登録できるため、対象ポリシー配下のすべてのリポジトリにおいて汚染伝播チェーンが根本から遮断されます。

4つのサニタイズ動作タイプと適切な選定

セキュリティ関数はその振る舞いによってデータの処理方式が異なります。Snyk Codeのルール拡張では、4種類のサニタイズタイプ（APIにおける extension_type）が用意されています。

1. フロー通過型（Flow Through）

入力値を受け取り、無害化した新たな戻り値を返す変換系関数に使用します。

package com.company.utils;

public class SecurityUtils {
    public static String escapeHtml(String data) {
        if (data == null) return "";
        return data.replace("<", "&lt;").replace(">", "&gt;");
    }
}

この関数を XSS ルールに対して flows_through_sanitizer として登録すると、戻り値がHTTPレスポンスなどのシンクに渡されてもアラートは抑止されます。

2. True時サニタイズ（If True）

ガード条件として使用されるブール検証関数に適用します。

package com.company.utils;

public class SecurityUtils {
    public static boolean isAlphaNumeric(String data) {
        return data != null && data.matches("^[a-zA-Z0-9]*$");
    }
}

コード内での利用例：

if (SecurityUtils.isAlphaNumeric(username)) {
    // このブロック内でのみ汚染が解除され、ファイルアクセスが安全とみなされる
    File userProfile = new File("/data/profiles/" + username);
} else {
    // elseブロック内では汚染状態が維持される
    response.sendError(400, "Invalid username");
}

3. False時サニタイズ（If False）

危険な文字列パターンを検知するブラックリスト形式の判定関数に適用します。

package com.company.utils;

public class SecurityUtils {
    public static boolean containsJavascriptProtocol(String data) {
        if (data == null) return false;
        return data.toLowerCase().trim().startsWith("javascript:");
    }
}

コード内での利用例：

if (!SecurityUtils.containsJavascriptProtocol(redirectUrl)) {
    // 戻り値がfalseの場合のみ汚染が解除され、安全にリダイレクト可能
    response.sendRedirect(redirectUrl);
} else {
    response.sendError(400, "Invalid redirect URL");
}

4. 任意呼び出し後（Any Usage）

入力値が不正な場合に例外をスローして後続処理を遮断するアサーション関数に適用します。

package com.company.utils;

public class SecurityUtils {
    public static void validateFileId(String fileId) {
        if (fileId == null || !fileId.matches("^[a-zA-Z0-9_-]+$")) {
            throw new IllegalArgumentException("Invalid File ID format");
        }
    }
}

コード内での利用例：

// 不正値の場合はここで例外が発生し処理が中断
SecurityUtils.validateFileId(fileId);

// 正常終了した場合、以降の行ではfileIdが安全とみなされる
File file = new File("/data/uploads/" + fileId);

注意・危険性：例外をスローせず、かつオブジェクトを破壊的に更新しない通常の関数に対して誤って any_usage_sanitizer を設定すると、検証を通過していない不正なデータであっても安全と誤認され、重大な偽陰性（見落とし）を引き起こします。

完全修飾名（FQN）の正確な記述ルール

Snyk Codeのエンジンは**完全修飾名（FQN）**を用いて厳密に関数を特定します。部分修飾名（PQN）やワイルドカードはサポートされていません。主要言語ごとの命名仕様は以下の通りです。

• Java：package.name.ClassName.methodName
  • 例：com.company.utils.SecurityUtils.escapeHtml
  • 注意点：ソースコード内でワイルドカードインポート（import com.company.utils.*）を多用すると静的解決が妨げられることがあるため、明示的なインポートが推奨されます。
• C#：global::Namespace.Class.Method
  • 例：global::MyCorp.Security.InputSanitizer.Clean
  • 必須要件：C#では先頭に必ず global:: プレフィックスを付与する必要があります。
• Kotlin：
  • クラス内メソッド：package.name.ClassName.methodName（例：com.company.utils.Validator.clean）
  • ファイル直下のトップレベル関数：package.name.FileNameKt.functionName（例：com.company.utils.FiltersKt.sanitizeInput）
• Python：module.submodule.function_name または module.ClassName.method_name
  • 例：corp_security.filters.clean_sql_input
  • 制限：デコレータ関数（@sanitize）を直接FQNとしてマッピングすることはできません。
• JavaScript / TypeScript：module_name.export_name または npm_package.export_name
  • 例：corp-sec-lib.escapeHtml
  • デフォルトエクスポート：末尾に .default を付与（例：security.cleaner.default）。
  • 注意点：深い相対パス（../../utils）によるインポートは解決精度を落とすため、パッケージ名または絶対パスの利用が推奨されます。
• Go：host.com/user/project/package.Function
  • 例：github.com/myorg/secutils/filter.SanitizeString
  • 構造体メソッド：github.com/myorg/secutils/filter.XSSFilter.Clean
• Apex：ClassName.methodName または Namespace.ClassName.methodName
  • 例：MyCorp.SecurityUtils.escapeHtml

Web UIおよびREST APIによる設定手順

ルール拡張は、Snyk Web UIまたはパブリックREST APIを経由して設定します。

Web UIでの設定フロー

1. Snyk Web UIにログインし、対象の**グループ（Group）**を選択します。
2. Group settings（グループ設定） ➔ Snyk Code ➔ Rule Extensions（ルール拡張） に移動します。
3. Create sanitizer をクリックし、必須属性を入力します。
   • Sanitizer：特定したFQNを入力（例：com.company.utils.SecurityUtils.escapeHtml）。
   • Rule key：対応する脆弱性ルールを選択（例：XSS、Sqli、PT、CommandInjection、OR、LogForging など）。
   • Sanitization type：前述の4種類から該当するタイプを選択。
4. 管理属性の設定：
   • Scope：グループ全体に適用するか、特定組織（Organizations）に限定するかを指定。
   • Description：Jiraチケット番号や変更理由などの説明を記載。
   • Status：Draft（下書き） または Published（公開） を選択。
5. Save をクリックして保存します。

最初はステータスを Draft に設定しておき、影響テストで検証を完了させた後に Published へ切り替える運用が安全です。

公開前の安全性検証：影響テスト（Impact Testing）

ルール拡張を即座に本番公開すると、FQNのスペルミスで無効化されたり、指定したサニタイズタイプが緩すぎて真の脆弱性を隠蔽したりするリスクがあります。Snykには、変更が既存プロジェクトのスキャン結果にどのような差分を与えるかをシミュレーションできる**影響テスト（Impact Testing）**が備わっています。

APIによる自動テストの流れ

ステップ1：テストの実行要求

POST /rest/groups/{group_id}/sast/rule_extensions/tests に対してリクエストを送信します。

POST /rest/groups/b1d4c802-9a3e-4b62-9e81-2c1a84f5093e/sast/rule_extensions/tests HTTP/1.1
Host: api.snyk.io
Authorization: token YOUR_API_TOKEN
Content-Type: application/json

{
  "data": {
    "type": "tests",
    "attributes": {
      "project_id": "a3b8d4e1-7f1c-4a09-8b7e-2c6f5d1a0b3f",
      "org_id": "123e4567-e89b-12d3-a456-426614174000",
      "fully_qualified_name": "com.company.utils.SecurityUtils.escapeHtml",
      "rule_keys": ["XSS"],
      "extension_type": "flows_through_sanitizer"
    }
  }
}

正常に受け付けられると、202 Accepted とともに test_id が返却されます。

ステップ2：ステータスのポーリング

GET /rest/groups/{group_id}/sast/rule_extensions/tests/{test_id} を定期取得し、ステータスが STARTED から COMPLETED に遷移するのを待ちます。

ステップ3：結果レポートの確認

GET /rest/groups/{group_id}/sast/rule_extensions/tests/{test_id}/results から差分結果を取得します。

{
  "data": {
    "attributes": {
      "total_count": 4,
      "removed_findings": {
        "count": 4,
        "changes": [
          {
            "rule_id": "java/XSS",
            "rule_name": "Cross-site Scripting (XSS)",
            "file_path": "src/main/java/com/company/web/UserController.java",
            "severity": "high",
            "priority_score": 710
          }
        ]
      },
      "added_findings": {
        "count": 0,
        "changes": []
      }
    }
  }
}

結果評価のポイント

• removed_findings：サニタイザー定義により解消されたアラート一覧。消去されたアラートが意図通りの偽陽性であるかをレビューします。
• added_findings：副次的に新規発生したアラート（通常のサニタイザー定義では0件が期待されます）。
• total_count = 0：対象プロジェクトに対して変更効果がゼロであることを意味します。FQNの誤り、ルールキーの不一致、またはインポート構造の未解決が疑われます。

エンタープライズAppSec運用のベストプラクティス

1. セキュリティSDKの集中集約：各開発チームがアドホックな検証関数を作るのではなく、社内共通のセキュリティライブラリ（共通Jar、Goモジュール、NPMパッケージ等）に集約し、そのインターフェースに対してのみルール拡張を定義します。
2. インポート構文の標準化：ワイルドカードインポートやリフレクション経由の動的呼び出しを抑制し、SASTエンジンが確実に関数参照を解決できるコーディング規約を策定します。
3. ライフサイクル連動監査：共通ライブラリのバージョンアップや関数名変更が発生した際は、即座にルール拡張のFQNも更新する運用フローを構築します。
4. 段階的ロールアウト：ドラフト登録 ➔ 影響テスト ➔ 単一組織でのパイロット検証 ➔ グループ全体公開という手順を踏むことで、安全かつ確実にアラート疲れを解消します。

ルール拡張を組織的なガバナンスプロセスとして運用することで、開発体験を大幅に改善しながら、堅牢なアプリケーションセキュリティ体制を維持できます。

参考文献

• Rule Extensions | Snyk User Docs
• Custom sanitizers | Snyk User Docs
• Configure Rule Extensions | Snyk User Docs
• Identify your sanitizer's FQN | Snyk User Docs
• Impact testing | Snyk User Docs
• Supported rules | Snyk User Docs