#security#devops#testing#tooling#compliance
CodeQL Models-as-Data実装戦略：検出結果を「運用できる予防策」に変える
コードスキャン運用が止まる典型は、検出は増えるのに現場が捌けず、やがて信頼を失うことです。GitHub CodeQLでsanitizer/validatorをmodels-as-dataとして宣言できるようになったことで、組織固有の実装文脈を宣言的に反映しやすくなりました。
何が変わるのか
従来、誤検知低減のためにはQuery自体を拡張する必要があり、保守負荷が高いのが課題でした。models-as-dataは、検出ロジックの本体を壊さず、文脈調整をデータ拡張で管理できる点が大きいです。
barrier / barrier guardの実務的価値
- barrier：ここで汚染データの伝播を止める、という宣言
- barrier guard：条件分岐で安全判定が成立する、という宣言
これにより、社内共通関数やフレームワーク特有の安全化処理を自然にモデル化できます。
3層モデルで運用する
- 共通基盤層：全社標準ライブラリ
- ドメイン層：認証・決済・分析など領域別
- チーム層：期限付き暫定調整
責任者を層ごとに固定すると、モデル肥大化を防げます。
変更管理の型
モデル変更は「設定」ではなく「セキュリティコード変更」です。
- 対象クエリ種別の明記
- 期待動作を示すコード例
- 変更前後の検出差分
- 過少検知時のロールバック計画
この型がないと、静かに検知穴が広がります。
検証ハーネスを先に作る
本番適用前に最低限必要なのは以下です。
- 既知脆弱サンプル
- 既知安全サンプル
- 過去インシデント再現コーパス
- スキャン時間の性能予算チェック
精度（precision）と再現率（recall）の推移を継続可視化します。
役割分担
- AppSec：コアモデルの管理
- Platform：フレームワーク語彙の提供
- Service Team：誤検知/見逃しの実例提供
三者連携の仕組みを持つ組織は改善速度が速いです。
成果を測るKPI
- 誤検知率の低下
- triage時間の短縮
- 再オープン脆弱性比率
- モデル変更のリードタイム
- 言語別適用カバレッジ
「検出件数」ではなく「安全運用のスループット」を見るのがポイントです。
よくある失敗
- barrierを広く張りすぎて実脆弱性を隠す
- テストコーパス更新なしでモデル追加
- マルチ言語で整合が崩れる
- 暫定モデルの放置
対策として、期限付き運用と四半期棚卸しを標準化します。
90日導入計画
- 1カ月目：誤検知多発ルールと共通ライブラリ棚卸し
- 2カ月目：初期モデルパックと検証ハーネス導入
- 3カ月目：変更審査フローと品質ダッシュボード定着
90日後には「どの変更が検知品質をどう変えたか」を説明できる状態が目標です。
まとめ
models-as-dataは、セキュリティ知識を属人化から資産化へ移すための実装手段です。統制付きで運用すれば、誤検知疲れを減らしながら予防的なコードスキャン体制を強化できます。
