10-8 · 章 10 · 2 分で読めます

セキュリティガードレールが機能しなくなったとき：パイプラインの効果を測定し改善する方法

CI/CDパイプラインにセキュリティスキャンや品質ゲートを導入しても、時間とともに効果が低下する。本記事では、ガードレールの効果を測定する3つの指標（誤検知率、バイパス率、平均対応時間）と、継続的に改善するための実践的なチェックリストを紹介する。

セキュリティガードレールが機能しなくなったとき：パイプラインの効果を測定し改善する方法

パイプラインにセキュリティスキャン、コンプライアンスチェック、品質ゲートを設定した。すべて順調に見えた。しかし6ヶ月後、開発者はあちこちで例外申請を提出し、セキュリティチームは誤検知の山に埋もれ、誰もパイプラインの結果を信頼しなくなっている。

これはツールの問題ではない。ガードレールの効果（エフェクティブネス）の問題だ。

今日導入したガードレールは、6ヶ月後のチームには適合しない。チームは変わる。ライブラリは更新される。コンプライアンスルールは進化する。新たな攻撃ベクトルが出現する。ガードレールを評価しなければ、二つのことが起こる：緩すぎて実際の問題を見逃すか、厳しすぎて開発者が回避策を見つけるかだ。

ガードレールが機能しているかどうかを知るには？

ガードレールの効果を測定する最も簡単な方法は、パイプラインがすでに生成しているデータを見ることだ。これのために別の可観測性プラットフォームは必要ない。CI/CDシステム、セキュリティツール、チケットシステムにすでに数字は揃っている。

まずは3つの指標から始めよう。

GitHub Actionsワークフローから誤検知率を計算するには、APIに対してこのスクリプトを実行する：

#!/bin/bash
# GitHub Actionsのセキュリティスキャン結果から誤検知率を計算する
# 前提条件: gh CLIが認証済み、jqがインストール済み

REPO="owner/repo"
DAYS=30

# セキュリティスキャンワークフローの完了した全ワークフロー実行を取得
gh api "/repos/$REPO/actions/runs?event=pull_request&status=completed&created=>=$(date -d "$DAYS days ago" -I)" \
  --jq '.workflow_runs[] | select(.name | test("security-scan")) | .id' \
  | while read -r run_id; do
      # 各実行のアノテーション（警告/失敗）を取得
      gh api "/repos/$REPO/check-runs/$run_id/annotations" \
        --jq '.[] | select(.annotation_level == "failure") | .message'
    done \
  | sort | uniq -c | sort -rn | head -20

# 上位の検出結果を手動でレビューし、誤検知を推定
# その後計算: 誤検知数 / 総検出数 * 100

誤検知率（False Positive Rate）：手動レビューの結果、無害と判明した検出結果の割合。この数値が高いと、チームは疲弊してスキャン結果を無視し始める。30%の誤検知率ならまだ許容できるかもしれない。70%になると、ガードレールは保護ではなくノイズだ。

バイパス率（Bypass Rate）：例外メカニズムを通った変更の割合。この数値が上昇し続けるなら、ガードレールが厳しすぎるか、現実と乖離している。毎月増加するバイパス率は、ルールがチームの実際の働き方に合っていないという警告サインだ。

平均対応時間（Mean Time to Respond）：検出結果が出現してから誰かが対応するまでの時間。結果が何日も放置されるなら、ガードレールは実質的に何も守っていない。対応に1週間かかる検出結果は、存在しないも同然だ。

これらの数値を毎スプリントまたは毎月確認しよう。ただし、チャートを眺めるだけでは不十分だ。数字の背後にあるパターンを読み取る必要がある。

数字だけでなくパターンを読む

複数のチームで同じルールのバイパス率が高い場合、そのルール自体が間違っている可能性が高い。しきい値が低すぎるのかもしれない。そのルールがその種類のコードに適用されないのかもしれない。ツールの設定が間違っているのかもしれない。

特定のチームだけが多くの例外を提出し、他のチームがまったく提出しない場合、そのチームのコンテキストが異なることを示している。コードベースが古いのかもしれない。依存関係が異なるのかもしれない。デプロイモデルが標準ルールに適合しないのかもしれない。

同じライブラリを一貫して脆弱性としてフラグするスキャンが、チームがそのコンテキストでは悪用不可能と確認した後も続く場合、抑制リストを設定する必要がある。同じ誤検知で毎回全員の時間を無駄にしてはいけない。

ツール更新後に誤検知が急増した場合、新しいバージョンで検出ロジックが変更されたことを意味する。新しいデフォルトをそのまま受け入れるのではなく、ルールをレビューする必要がある。

これらのパターンが何を調整すべきかを教えてくれる。ただし、調整は無制限に許されるわけではない。

信頼を損なわずにガードレールを調整する方法

すべてのガードレール変更は、コード変更と同じプロセスを経る必要がある。文書化する。レビューする。テストする。記録する。これにより、チームが急いでいるからといってルールを緩めることを防ぐ。

定期的なガードレールレビューをスケジュールしよう。毎月または四半期ごとに、セキュリティチーム、プラットフォームチーム、開発チームの代表者が集まる。データを見る。どのルールを厳しくし、どのルールを緩めるべきかを議論する。変更に合意し、文書化する。

このミーティングは例外を承認するためのものではない。システムを改善するためのものだ。同じ例外が繰り返し出てくるなら、ルールを変更する。実際の問題を一度も捕捉しないルールは削除する。誤検知が多すぎるルールはしきい値を調整する。

よく見落とされるのが、実際にパイプラインを使う人々からのフィードバックだ。毎日ガードレールに対処している開発者は、どのルールが意味があり、どのルールが単にフラストレーションの原因かを正確に知っている。パイプラインが自分たちのコンテキストに当てはまらない理由で失敗し続けるなら、彼らはそれを無効にする方法を見つけるだろう。

苦情を待ってはいけない。定期的にフィードバックを求める。レトロスペクティブを活用する。短いアンケートを送る。あるいは、例外リクエストを含むプルリクエストのコメントを見るだけでもいい。それらのコメントは、ガードレールがどこで失敗しているかを正確に教えてくれる。

本当の目標はゼロ障害ではない

よくある誤解は、良いガードレールはパイプラインをほとんど失敗させないというものだ。それは間違いだ。良いガードレールは、本番環境に到達する前に実際の問題を捕捉し、安全な変更は迅速に通す。

ガードレールが無害な変更で頻繁に失敗すると、チームの信頼を失う。結果を無視し始める。読まずに例外を提出する。パイプラインを保護ではなく、官僚的な手続きとして扱う。

ガードレールがほとんど失敗しない場合、チームは安心すべきでないときに安心してしまう。パイプラインがすべてを捕捉するからと、セキュリティについて考えなくなる。しかし、すべてを捕捉するパイプラインなど存在しない。

この二つの極端な状態のバランスは、一度設定して終わりではない。測定、評価、調整を継続的に行うことで見つけるものだ。

ガードレールレビューの実践的チェックリスト

毎月または毎スプリント、このリストをチェックしよう：

各スキャンタイプの誤検知率を確認する。40%を超えている場合は調査する。
バイパス率のトレンドを確認する。3期間連続で上昇している場合は、バイパスされているルールをレビューする。
クリティカルな検出結果の平均対応時間を確認する。48時間を超えている場合は、アラートとエスカレーションパスを見直す。
最も多くの例外を生成した上位5つのルールをレビューする。それぞれのルールがまだ意味をなすかどうかを問う。
開発者から、パイプラインで最もフラストレーションを感じる点についてのフィードバックを1つ収集する。
先月、ツールや依存関係の更新によってスキャンの動作が変わったかどうかを確認する。

これには30分しかかからない。無駄なデバッグやフラストレーションを溜めた開発者に何時間も費やす手間を省ける。

効果的なガードレールの先にあるもの

ガードレールがうまく機能するようになったら、次のステップはそれらを一元的に管理することだ。異なるチームが独自にセキュリティツールを設定すべきではない。異なるプロジェクトが同じ種類のリスクに対して異なるルールを持つべきではない。ここでプラットフォームエンジニアリングの出番となる：全チームにわたってルール、ツール、設定を標準化する統一レイヤーだ。

しかし、それはまた別の記事のトピックだ。今は、現在のガードレールを測定可能で、レビュー可能で、調整可能にすることに集中しよう。評価しないガードレールは、ガードレールではない。それは単に、誰もが乗り越えることを覚える壁にすぎない。