プロンプトとコンテキスト
あるプラットフォームでは、バイナリやコンテナイメージのビルド来歴（provenance）ステートメントを生成でき、利用者はCLIを使用してアーティファクトのダイジェストに対してそのステートメントを検証できます。セキュリティチームは本番デプロイですべてのアーティファクトを検証することを求めていますが、開発者はレガシーなパイプライン、外部ビルダー、オフラインネットワークがすぐには対応できないことを懸念しています。構成証明が何を証明し何を証明しないのか、セグメンテーション、デフォルト設定、移行、指標、ロールバックを含むプロダクトの意思決定とローンチ計画を提案してください。中核となるスキルはプロダクトガバナンスとトレードオフの判断力であるため、これは product に関する質問です。
面接官が評価するポイント
第一に、「ステートメントが存在すること」と「ステートメントが信頼できること」を区別できているか：検証には署名、アーティファクトのダイジェスト、ワークフローのアイデンティティ、ポリシーコンテキストが依然として必要です。
第二に、ホビープロジェクト、エンタープライズの本番環境、規制環境に対して一律の必須スイッチを適用するのではなく、リスクと対応能力によってユーザーをセグメント化できているか。
第三に、監視（observe）から警告（warn）、選択的ブロック（selective block）、監査可能な例外を伴うデフォルトブロック（default block）への段階的な移行を設計できているか。
第四に、指標が生成されたステートメントの数ではなく、セキュリティ、開発者体験、カバレッジ、ビジネス成果をカバーしているか。
第五に、脅威モデルが侵害されたビルダー、誤ったポリシー、再パッケージされたイメージ、オフライン検証をカバーしているか。
最初に明確にすべき質問
- 対象ユーザーはオープンソースプロジェクト、一般的なSaaS、あるいは規制対象の本番プラットフォームのどれですか？
- ビルドは GitHub Actions、サードパーティCI、開発者マシン、または複数のソースのどこから来ますか？
- 本番環境はオンラインのステートメントを読み取れますか、それともオフラインや隔離されたネットワークをサポートする必要がありますか？
- 一時的な例外は許可されますか？ 誰が承認し、いつ期限切れになりますか？
- 検証はプラットフォーム、クラスタのアドミッション制御、それとも顧客のパイプラインのどこで実行されますか？
- 目標はサプライチェーンの監査性、未承認アーティファクトのブロック、インシデント対応の迅速化のどれですか？
30秒での回答
「私は構成証明を、検証可能なビルド起点シグナルと定義し、ソースコードが安全であることの自動的な保証ではないと位置づけます。リスクと移行能力に応じて、クリティカルな本番環境、通常の本番環境、開発環境、外部ビルドにセグメント化します。監視と警告から開始し、その後選択的にブロックし、最終的に高リスクな本番環境をスコープと期限付きの例外を設けてデフォルトブロックにします。指標には有効な検証カバレッジ、未承認アーティファクトのブロック数、誤検知ブロック、デプロイ遅延、例外率、インシデント対応時間が含まれます。侵害されたビルダー、再パッケージング、オフライン検証には個別の脅威モデルを用意し、段階的（グレイ）ロールアウトによって迅速で監査可能なロールバックを維持します。」
詳細なソリューション
ステップ1：ユーザーの課題と信頼境界を定義する
アーティファクト構成証明は、アーティファクトのダイジェストを主張されたビルド来歴にバインドし、利用者がそれを生成したワークフロー、コミット、ビルダーを特定できるようにします。これはソースに脆弱性がないことを証明するものではなく、侵害されたビルダーを修復するものでもありません。プロダクトの文言やポリシーでは、来歴、署名検証、スキャン、デプロイ承認を明確に分離する必要があります。
ステップ2：ユーザーをセグメント化する
クリティカルな本番サービス、通常の本番環境、開発プレビュー、外部コントリビューターを分離します。クリティカルな本番環境には厳格な検証と短い例外期間が必要です。開発環境は迅速なフィードバックを優先します。外部ビルドにはアップロードされたバンドルや信頼できる再ビルドが必要になる場合があります。セグメンテーションによって、デフォルト設定、サポートコスト、移行順序が決まります。
ステップ3：検証ループを設計する
プロデューサーはビルド後にステートメントを書き込みます。コンシューマーはそれをアーティファクトのダイジェストに対して検証し、リポジトリ、コミット、ブランチ、ビルダー、発行者をポリシーと照合します。結果はブール値のみを返すのではなく、ステートメントの欠落、ダイジェストの不一致、許可されていないソース、期限切れなど、アクション可能な理由を説明する必要があります。
ステップ4：段階的なポリシーを計画する
まず読み取り専用モードでカバレッジと失敗理由を測定します。次に非本番環境で警告を出します。その後、選択した本番サービスをブロックし、最終的にデフォルトブロックへと拡大します。各段階には、誤検知ブロック、検証遅延、レガシーパイプラインの移行、サポート件数に関する終了基準が必要です。例外には、責任者、理由、スコープ、有効期限を記録します。
ステップ5：複数のビルド起点をサポートする
GitHub Actions はステートメントを直接生成できますが、サードパーティCI、外部ビルダー、オフラインビルドにはインポートされた証拠または信頼できる発行者フローが必要です。JSONファイルをアップロードしただけで信頼できるステートメントと誤認されないよう、製品は証拠フォーマット、ダイジェストバインディング、検証コマンドを文書化する必要があります。
ステップ6：指標とガードレールを定義する
中核となる指標は、有効な本番検証カバレッジ、未承認アーティファクトのブロック率、誤検知ブロック率、デプロイ遅延のp95、移行時間、例外期限切れ率です。ガードレールには、ビルド失敗率、ロールバック時間、サポートチケット数、オフライン顧客のブロック、セキュリティインシデント中のステートメント可用性が含まれます。ステートメント数は利用指標であり、セキュリティの成果ではありません。
ステップ7：段階的ロールアウトとロールバックを準備する
ポリシーのバージョンと判定ログを保持しながら、組織、リポジトリ、またはサービス単位で有効化します。検証機能が利用できない場合は、フェイルクローズと制御されたフェイルオープンを区別します。クリティカルなパスでは手動承認により一時的にブロックし、低リスクな環境ではログを記録して続行させます。ロールバックは、既存の証拠や監査記録を削除することなく強制適用のみを無効化します。
高品質な回答サンプル
「プロダクトの目標は、ポリシーに違反する起点のアーティファクトが本番環境に到達するのを防ぐことであり、来歴によってコードが安全であると主張することではありません。私はリスクとビルド能力によって顧客をセグメント化し、GitHub Actions、サードパーティCI、オフラインビルダー向けの証拠パスを提供します。ローンチは監視、警告、選択的ブロック、デフォルトブロックの順に進め、誤検知ブロック、レイテンシ、移行率がしきい値を満たした場合にのみ拡大します。検証では、証拠の欠落、ダイジェストの不一致、許可されていない起点などの理由を明示し、例外には承認、期限、監査を義務付けます。検証機能の障害に対する制御されたフォールバックを用意しつつ、有効なカバレッジ、未承認ブロック、誤検知ブロック、インシデント対応時間を測定します。」
よくある間違い
- ステートメント数をセキュリティとみなす → 多くのステートメントが無効または未検証である可能性があります → 有効な検証とブロックの成果を測定してください。
- 初日からの強制適用 → レガシーユーザーやオフラインユーザーがブロックされます → セグメンテーション、段階的ロールアウト、移行期間を活用してください。
- 署名のみのチェック → 信頼できる発行者であれば何でも通過してしまいます → ワークフロー、コミット、リポジトリ、ビルダーのポリシーをチェックしてください。
- 来歴を脆弱性スキャンと呼ぶ → ユーザーが保護内容を誤解します → 起点、脆弱性、承認の主張を分離してください。
- 失敗理由を表示しない → 開発者が問題を修正できません → 構造化された理由と修復リンクを返してください。
- 永続的な例外 → 強制適用の効果が静かに低下します → スコープを限定し、承認し、期限を設定してください。
- 検証機能の停止を無視する → 1つの障害でリリースが広範囲に停止します → フェイルクローズ、制御されたフェイルオープン、ロールバックを定義してください。
- 単一のCIのみをサポートする → 複数のソースを持つ顧客が移行できません → インポート、バンドル、信頼できる発行者パスを提供してください。
フォローアップ質問
フォローアップ 1: 構成証明はコードが改ざんされていないことを証明しますか？
アーティファクトのダイジェストを主張されたビルド起点にバインドするため、利用者は一致を確認できます。しかし、ビルダー、依存関係、ソースが完全に安全であることを証明するものではありません。権限管理、スキャン、再現可能なビルドが引き続き必要です。
フォローアップ 2: なぜ全員に対して直ちにフェイルクローズにしないのですか？
顧客によってビルド能力、証拠ソース、ネットワーク環境が異なります。一律のブロックは障害を引き起こし、チームがポリシーを無効化する原因になります。監視と段階的ロールアウトにより、実際の失敗データを用いてルールを調整できます。
フォローアップ 3: 誤検知ブロックはどのように測定しますか？
各ブロックについて、理由、サービス、ポリシーバージョン、その後の手動承認を記録します。確認された正当な復旧データと総ブロック数を組み合わせ、顧客ティアごとに分析します。すべての例外を誤検知として分類してはいけません。
フォローアップ 4: オフラインの顧客はどのように検証しますか？
証拠バンドルと必要な信頼ルート（trust root）をダウンロードできるようにし、ローカルでダイジェストと起点を検証させます。隔離された環境向けに、信頼ルートの更新、失効、期限切れの動作を文書化します。
フォローアップ 5: ビルダーが侵害された場合はどうなりますか？
ステートメントは主張された起点を記述するものであり、その起点が侵害されていないことを証明するものではありません。ワークフローの権限を制限し、ビルダーを隔離し、発行者のアイデンティティをローテーションし、異常な起点やポリシー変更を監視します。
フォローアップ 6: 例外が恒久化するのを防ぐにはどうすればよいですか？
各例外をカウントダウンと責任者を持つ期限付きの異常事態として扱います。チームごとに期限切れや繰り返される理由を追跡し、ポリシーを恒久的に弱めるのではなく、移行のギャップを解消します。