CodeQLのModels-as-DataがSanitizer/Validator対応強化, 大規模AppSec運用の実装指針
GitHub Changelogで公開されたCodeQLの更新により、models-as-dataでsanitizerとvalidatorをより直接的に表現しやすくなりました。これは単なる機能追加ではなく、企業の静的解析運用で長年の課題だった「誤検知の多さ」と「カスタムクエリ保守コスト」を同時に下げる現実的な転換点です。
なぜ今この機能が効くのか
多くの組織は、CodeQL導入初期は既定クエリで成果が出ますが、運用が進むほど課題が顕在化します。具体的には次の3つです。
- 社内共通ライブラリの入力検証ロジックが既定モデルに反映されず、誤検知が増える
- プロダクトごとの例外を手作業で抑制し、レビューと監査の負担が増える
- 「この警告は安全か」を毎回議論するため、開発速度が落ちる
sanitizer/validatorのモデル化をデータで管理できると、これらをクエリ改変ではなくポリシー運用として扱えます。つまり、解析エンジンをいじらずに、組織の実装実態を安全に反映できます。
実装の基本設計
実務では3層構造が扱いやすいです。
- 全社共通層: OSSや共通フレームワークで広く使う検証/エスケープAPIを定義
- ドメイン層: 認証基盤, API Gateway, データ整形ライブラリなど社内標準を定義
- サービス層: 特定サービスにだけ適用すべき例外ルールを定義
ポイントは、サービス固有の事情を全社に混ぜないことです。これを混ぜると、別プロダクトで本来検知すべきフローまで見逃す危険が出ます。
ロールアウト手順
最初から厳格にブロックすると反発が起きるため、段階移行が必須です。
- 第1段階: report-onlyで1週間運用し、検知傾向を確認
- 第2段階: 外部入力境界（公開API, ファイルアップロード, テンプレート描画）だけを必須化
- 第3段階: 誤検知率が安定したリポジトリから順次拡大
このとき、モデル変更には必ずロールバック手順を付けます。誤ったモデルで警告が抑制された場合、通常のバグよりも発見が遅れるためです。
追うべき指標
件数だけでは効果が測れません。次の指標を最低限追います。
- 真陽性率（導入前後比較）
- 手動抑制コメントの発生件数
- 警告トリアージ完了までの平均時間
- 本番事故に繋がる入力検証漏れの再発率
手動抑制が減らない場合、モデル設計が現場の実装に追いついていないと判断すべきです。
組織体制
言語別に責任者を置く体制が有効です。例としてTypeScript, Python, Javaごとに「モデルオーナー」を置き、横断整合は中央AppSecが担保します。これにより、現場知識不足の中央集権運用を避けつつ、統制も維持できます。
まとめ
今回の更新は、静的解析を「セキュリティチームの専用業務」から「開発基盤の共通能力」へ引き上げる材料です。モデルをデータとして統治し、段階導入とメトリクス監視を徹底できる組織ほど、速度と安全性を両立できます。
