#security#api#observability#devops#reliability
ステートフルAPI脆弱性スキャン運用：検知から修正までつなぐ実装設計
API攻撃は、いまや単発のペイロード勝負ではありません。認証の弱点、ビジネスロジックの不整合、トークン運用ミスを複数リクエストで連鎖させる攻撃が主流です。1リクエスト単位のスキャンだけでは、本番リスクを取りこぼします。
最近のCloudflareのアクティブディフェンス系の発信が示す通り、実務は「危険な文字列を探す」から「攻撃者セッションを再現する」へ移行しています。
ステートフル化で何が変わるか
従来型はエンドポイント単位で検査します。ステートフル型はフロー単位で検査します。
- 登録 → 検証 → 権限遷移
- カート更新 → 決済直前の競合
- トークン更新 → 再利用（replay）
- 分散Gateway跨ぎのクォータ逸脱
分析単位が「リクエスト」から「シナリオ」に変わるのが本質です。
実運用アーキテクチャ（3つのループ）
ループ1：発見と契約抽出
- OpenAPI仕様と実トラフィックから経路を同定
- 未文書エンドポイントを抽出
- ルートごとの認証方式・データ分類を付与
ループ2：状態遷移ベースの攻撃再現
- 分岐を持つセッショングラフを生成
- 実時間に近いタイミングで遷移を再生
- 不変条件破壊（権限昇格、負残高、失効認可利用）を検知
ループ3：ランタイム相関
- スキャン結果をWAF/API Gatewayログに突合
- 実トラフィックから悪用可能性を再評価
- 現在の構成では到達不能な検知を抑制
この相関がないと、理論上の検知だけが増えて現場が止まります。
優先度設計（4軸）
各検知を次の4軸でスコアリングします。
- 現行構成での悪用可能性
- 影響半径（テナント/財務/規制）
- 既存検知網の欠落度
- 修正容易性とオーナー明確性
その上で P0/P1/P2 に振り分けます。重要なのは、セキュリティ部門だけの台帳にしないことです。プロダクト・基盤・SREが同じキューを見る体制にしないと、修正が進みません。
45日導入プレイブック
- 重要APIジャーニーを2本選びシナリオ化
- 監視モードで誤検知傾向を把握
- request ID / session ID / identity claimでログ連結
- 抑制ルールに失効日を必須化
- Jira連携時にSLAラベルを自動付与
- 週次で攻撃経路レビュー会を開催
- 検知→修正完了の所要日数を計測
典型的な失敗
- 品質調整前に「ゲート化」して開発を止める
- ビジネスロジック脆弱性の責任者が不明
- 期限なし抑制で恒久的死角を作る
- AppSecとAPI運用の可観測性が分断
KPI
- 実行可能な検知率（actionable / total）
- 検知から修正までの平均日数
- 再発（reopen）率
- 高リスク経路のカバレッジ
- 修正後に遮断できた攻撃試行数
まとめ
ステートフルAPIスキャンは、ツール導入より運用接続が勝負です。シナリオ設計、ランタイム相関、責任あるキュー運用をそろえると、検知はノイズではなく再発防止の資産になります。
