プロンプトとコンテキスト
あなたは多数のリポジトリを抱える開発者プラットフォームのオーナーです。セキュリティチームは、すべてのプルリクエストに追加・更新・削除された依存関係と脆弱性の影響を表示し、高リスクなパッケージが検出された場合はマージをブロックすることを求めています。一方、エンジニアリングチームは誤検知（偽陽性）、ライセンス競合、待ち時間の増加を懸念しています。プラットフォームはマニフェストやロックファイルを読み取ることができ、パイロット期間として4週間が与えられていると仮定します。目標は、デリバリーを遅らせることなく、本番環境に到達する依存関係リスクを低減することです。
面接官が評価するポイント
面接官は測定可能な成果を求めています：本番環境に混入する高リスクな依存関係、修正までの時間、ゲートのブロック率、誤検知率、開発者の待ち時間のp95などです。優れた回答では、可視化（コメントやレポート）と強制（マージのブロック）を明確に区別し、すべてのリポジトリに一律のルールを適用するのではなく、リポジトリのリスクやエコシステムのカバー範囲に応じてポリシーを段階的に適用します。
最初に確認すべき明確化の質問
- どの脆弱性の深刻度やライセンス義務をブロック対象とするか？法的義務は、悪用可能性単体よりも厳格な対応が必要になる場合があります。
- どのエコシステムやロックファイルがカバーされているか？解析されていないリポジトリを安全と見なすことはできません。
- 修正の担当者（オーナー）とSLAは誰が持つか？オーナーシップがなければ、ゲートには例外が蓄積されるだけです。
- 緊急リリースのためのパスはどうなっているか？期限付きで監査可能な一時的適用免除（ウェイバー）が必要です。
- 目的は発見、強制、またはその両方か？誤検知が多い場合は、レポート専用モードから開始すべきです。
30秒の回答フレームワーク
「高リスクな依存関係の変更、修正時間の中央値およびp95、ゲートのブロック率、適用免除率のベースラインを測定します。次に、完全な依存関係グラフと安定したチェックを備えた高リスクリポジトリでパイロットを実施します。まずレポートのみを行い、次に重大（critical）な検出事項をブロックし、その後に高（high）の検出事項を評価します。成功にはリスク低減とデリバリーのガードレールが含まれている必要があります。誤検知や待ち時間が制限を超えた場合は、レポート専用モードに戻してルールを修正します。」
ステップごとの詳細な回答
- リスクのセグメンテーション。 悪用可能性、本番環境への露出度、データの機密性、ライセンス義務によってリポジトリを分類します。単なる脆弱性スコアだけで順位付けしてはいけません。
- データの検証。 マニフェスト、ロックファイル、依存関係の提出が解析されているか確認します。サポートされていないエコシステムは、安全とするのではなく『不明』としてマークします。
- ポリシーの設計。 低リスクリポジトリにはコメントを付与し、高リスクリポジトリでは重大な検出事項をブロックします。ライセンスには明確なSPDXの許可・拒否セットを使用し、人手によるレビューを残します。
- メトリクスの定義。 プライマリメトリクスは、本番環境に入る高リスク依存関係の割合と修正p95です。ガードレールには、ブロック率、誤検知率、ビルド待ち時間のp95、免除率、セキュリティチームの工数が含まれます。
- 段階的なロールアウト。 高リスクリポジトリの10%から開始します。ルールのヒット状況、修正結果、免除理由、有効期限を記録します。平均値によってギャップが隠れないよう、エコシステムごとに個別に比較します。
- リリースとロールバック。 組織のルールセットを通じて拡大し、すべてのポリシー変更のバージョン管理を行います。ブロック率や待ち時間がガードレールを超えた場合は、開発チームにチェックの回避を覚えさせるのではなく、レポート専用モードに切り替えます。
代替案としては、リリースポリシーをリリースブランチのみに限定する、日次スキャンを行う、ランタイム依存関係と開発用依存関係で閾値を分ける、または最初にロックファイルのカバー範囲を改善することが挙げられます。主な課題がインベントリの不足である場合、依存関係グラフを完成させることの方が、より厳格なブロックよりも価値があります。
模範回答
「私はこれをリスク管理プロダクトとして扱います。第1週には、本番環境に入る高リスク依存関係、発見から修正までのp95、依存関係チェックのブロック率、手動免除率の4つのベースラインを測定します。第2週には、完全なグラフと指名されたセキュリティオーナーを持つ高リスクリポジトリでレポート専用モードをパイロット運用します。第3週には、重大な検出事項のみをブロックし、明示的なSPDXライセンスルールを使用し、すべての免除に理由と有効期限を義務付けます。目標として、新規の高リスク依存関係の40%削減、修正p95の維持（悪化なし）、ブロック率5%未満、ビルド待ち時間p95の増加を10%未満に抑えることを求めます。もし2%以上の依存関係が未解析であれば、拡大を停止してインベントリを修正します。緊急免除が10%を超える場合は、ポリシーまたはオーナーシップモデルが誤っています。」
よくある間違い
- 間違い: すべての脆弱性を即座にブロックする → 失敗する理由: 深刻度、悪用可能性、本番露出度がセグメント化されていない → 対策: まずレポートから始め、リポジトリのリスクに応じて強制する。
- 間違い: スキャンのヒット件数ばかりを最適化する → 失敗する理由: ヒット件数はリスク低減を証明しない → 対策: 本番環境への混入率と修正レイテンシを追跡する。
- 間違い: ロックファイルやエコシステムのカバー範囲を無視する → 失敗する理由: 未解析の依存関係が誤った安心感を生む → 対策: カバー範囲を前提条件とし、不明なものはマークする。
- 間違い: 恒久的な免除を許可する → 失敗する理由: ゲートの権威が徐々に失われる → 対策: 理由、オーナー、有効期限を必須とする。
フォローアップの質問と回答
開発者が誤検知に対して異議を申し立てた場合、ゲートを無効化すべきか？
ルール、エコシステム、深刻度ごとに誤検知を分類し、証拠を収集している間はレポート専用モードを維持します。誤検知が目標SLA内に収まらない場合にのみレポート専用の強制に戻し、ルールの改修を完了条件（exit criterion）とします。
重大な脆弱性に修正バージョンが存在しない場合はどうするか？
『修正版なし（no fix available）』を明示的に表現します。セキュリティオーナーによる一時的な免除の承認、補償的コントロール、およびレビュー期日の設定を義務付けます。スキャンの失敗を決して成功扱いに変更してはいけません。
ポリシーがデリバリーを遅らせていないことをどのように証明するか？
リポジトリおよび変更タイプごとに、パイロット前とパイロット中の待ち時間p95、マージスループット、ロールバック率を比較し、同時に免除率も報告します。全社的な平均値は、小規模なチームで発生している深刻なブロッキングを覆い隠してしまう可能性があります。
組織全体への拡大はいつ行うか？
高リスクリポジトリのカバー率、説明可能なルールヒット、修正SLA、待ち時間のガードレールが2つのリリースサイクルにわたって目標を満たし、免除が期限内にクローズされるようになった後にのみ拡大します。