質問とシナリオ
ソフトウェアサプライチェーンのエビデンス向けの透明性サービスを設計します。ビルダーはビルド環境とアーティファクトのダイジェストを証明でき、パブリッシャーはリリースとそのソースを証明でき、インテグレーターはテストやコンプライアンスの結果を追加できます。コンシューマーは、誰がステートメントに署名したか、登録ポリシーに合格したか、検証可能な履歴レシートが存在するかを検証できる必要があります。
重要な境界は、検証可能なレコードとビジネスデータベースの間にあります。このサービスは、ステートメントがある時点で登録されチェックされたことを証明します。オブジェクトストレージ、パッケージレジストリ、または完全な依存関係リゾルバーを置き換えるものではありません。
面接官がテストしていること
信頼の境界
優れた回答では、発行者、透明性サービス、監査人、依存当事者（relying parties）を分離し、各当事者が何を証明でき、何を証明できないかを明示します。
暗号資材と履歴
署名付きステートメント、ポリシー結果、追記専用ログ（append-only log）、レシートがどのように関連しているかを説明します。データベースに1行書き込むだけでは、改ざん防止のエビデンスにはなりません。
運用可能なガバナンス
書き込みパスを描くだけでなく、鍵ローテーション、失効、重複送信、ポリシーバージョン、テナント分離、プライバシー、ディザスタリカバリを取り上げます。
信頼性とスケーラビリティ
高い発行量と急激なコンシューマーのアクセスに対応するための、冪等な登録、バッチ検証、証明の読み取り、クロスリージョンレプリケーション、監査リプレイについて説明します。
回答前の確認質問
- ステートメントはソフトウェアアーティファクトに限定されますか、それともハードウェア、モデル、デプロイ環境も含まれますか？
- サービスは1つの組織によって運営されていますか、それとも相互に検証が必要な複数テナントで共有されていますか？
- コンシューマーは強一貫性のある読み取りを必要としますか、それとも「登録済みだが証明が未レプリケーション」の状態を許容できますか？
- どのフィールドが機密情報であり、公開ビューにはダイジェスト、時刻、発行者識別子のみを公開できますか？
- 失効の対象は、鍵、ステートメント、それともポリシー決定のみですか？
- 目標スループット、エビデンス保持期間、クロスリージョンの復旧ポイント（RPO）はどのようになっていますか？
30秒の回答フレームワーク
「システムをステートメント登録API、ポリシーチェッカー、透明性ログ、レシートサービス、検証SDKに分割します。発行者はCOSE署名付きステートメントを提出し、サービスはバージョン管理されたポリシーをチェックして、追記専用ログに冪等性キーのもとで登録します。ログは包含証明（inclusion proof）を含むレシートを返します。コンシューマーは、ステートメント、レシート、監査パスを使用して、署名、ログ包含、ポリシーバージョン、時刻をオフラインで検証します。機密フィールドはダイジェストまたは暗号化された参照のまま保持されます。鍵ローテーションと失効にはトラストルートとステータスレコードを使用し、クロスリージョンレプリケーションはログとポリシー結果の一貫性が取れた後にのみ公開します。」
ステップバイステップの詳細な回答
ステップ 1: ステートメントとロールの定義
ステートメントには、サブジェクト識別子、発行者、タイプ、有効期間、ポリシーバージョン、コンテンツダイジェストが含まれ、発行者はCOSE_Sign1で署名します。透明性サービスは認証された発行者のみを受け入れ、各ステートメントをテナント、名前空間、ソースにリンクします。コンシューマー、監査人、ポリシー管理者には個別の権限が設定されます。
ステップ 2: 登録の設計
クライアントは、署名付きステートメント、冪等性キー、ポリシーヒントを指定して POST /statements を呼び出します。サービスは署名、時間枠、スキーマ、発行者ステータスを検証し、ポリシーを評価します。合格したステートメントは透明性ログに追加されます。同一のコンテンツとキーに対しては元のレシートを返し、競合がある場合は暗黙的に上書きするのではなく現在の登録を返します。
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }ステップ 3: 検証可能なレシートの発行
サービスは、ログツリーのバージョン、リーフダイジェスト、証明パス、サービスの署名を含むレシートを作成します。リーダーはサービスの公開鍵でレシートを検証し、ステートメントダイジェストを再計算して、包含を確認します。レシートは、サービスがある時点でレコードを登録しコミットしたことを証明しますが、アーティファクトが安全であることを証明するものではありません。
ステップ 4: ポリシー、失効、時刻の処理
ポリシーはバージョン管理され、各登録レコードに固定されます。後のポリシーが過去の結果を書き換えることはなく、新しい評価ステートメントを作成します。鍵ローテーションでは、過去の公開鍵を有効化時刻とともに保持します。ステータスレコードによって、発行者、鍵、またはステートメントを失効させることができます。検証者は、ステートメント時刻、レシート時刻、トラストルートの有効期間を確認します。
ステップ 5: プライバシーとテナントの分離
公開ログには、ダイジェスト、タイプ、発行者識別子、必要なタイムスタンプのみを保持します。ソースコード、内部ドメイン、脆弱性の詳細は暗号化されたオブジェクトストレージに保存され、コンテンツアドレスで参照されます。テナントポリシー、クォータ、読み取り認可はAPIで強制され、証明フォーマットの相互運用性を維持しながら、ログインデックスをテナントごとにパーティショニングできます。
ステップ 6: スケール、復旧、運用
書き込みパスではログのシャーディングとバッチコミットを行い、読み取りパスでは公開鍵、スキーマ、レシートをキャッシュします。順序付けられたログとチェックポイントをリージョン間でレプリケーションします。ターゲットリージョンは、ログの状態、ポリシー結果、鍵ステータスが収束するまで読み取り専用のままにします。登録成功数、ポリシー拒否、レシートレイテンシ、レプリケーション遅延、検証失敗、失効の伝播時間を監視します。
質の高い模範解答
「ステートメント登録APIとオフライン検証SDKを公開します。ビルドシステムは、アーティファクトダイジェスト、発行者、タイプ、時刻、ポリシーバージョンを含むCOSE_Sign1ステートメントを提出します。サービスは署名とスキーマを検証し、テナントポリシーを評価し、追記専用の透明性ログにダイジェストを追加して、包含証明レシートを返します。登録は冪等であるため、リトライしても同じレシートが返されます。
コンシューマーはステートメント、レシート、トラストルートをダウンロードし、署名、ログ包含、発行者ステータス、ポリシーバージョンをローカルで検証します。検証結果は別の署名付きステートメントにすることができ、追跡可能なチェーンを形成します。機密コンテンツは暗号化された参照の背後に保持されます。過去のトラストルートは鍵ローテーション後も利用可能であり、失効はステータスステートメントを通じて伝播します。クロスリージョンレプリケーションは、強力な検証読み取りを開始する前に、順序付けられたログデータ、チェックポイント、ポリシー結果をコピーします。このシステムは登録と追跡可能性を証明するものであり、マルウェアスキャンやランタイムセキュリティを置き換えるものではありません。」
よくある落とし穴
- ステートメントを編集可能なテーブルに保存する → 管理者が履歴を書き換えることができる → 追記専用ログ、署名付きレシート、独立した検証ツールを使用する。
- 透明性レシートをセキュリティ判定結果として扱う → 登録されていることはアーティファクトに脆弱性がないことを意味しない → 出所（provenance）、ポリシー結果、ランタイムリスクを分離する。
- ポリシー変更時に古いレコードを上書きする → 監査で過去の決定を再現できない → ポリシーバージョンを固定し、新しい評価を追加する。
- 現在の鍵のみをローテーションする → 過去のステートメントが検証できなくなる → 過去の鍵とトラストルートを有効化時刻とともに保持する。
- ステートメントのすべてのフィールドを公開する → ソースや脆弱性のメタデータが漏洩する → ダイジェストのみを公開し、機密参照を暗号化する。
- リトライによって重複登録が作成されるのを許容する → 不安定な履歴とストレージの浪費 → 冪等性キーをテナントおよび署名されたコンテンツにバインドする。
- 証明が収束する前にレプリカを開放する → 包含パスが不完全になる → 読み取りを提供する前にログ、チェックポイント、鍵ステータスをレプリケーションする。
- すべての検証で中央APIを必須にする → オフライン監査が失敗する → ステートメント、レシート、トラストルート、オフライン検証ツールを提供する。
追加の質問と回答
質問 1: ログが中間のレコードを削除していないことをどのように証明しますか？
監査人は定期的に署名付きチェックポイントを取得して比較します。検証者は単調増加するツリーサイズ、一貫した過去のルート、有効な包含証明を要求します。フォークが発生した場合、ログは信頼されなくなります。
質問 2: 2つの透明性サービスからのレシートは相互に検証できますか？
ステートメントダイジェストと標準化されたレシートフォーマットを共有することは可能ですが、各サービスは依然として独自のトラストルートで署名します。サービス間の同等性には追加のクロスステートメントが必要であり、あるサービスの公開鍵が自動的にもう一方の信頼になるわけではありません。
質問 3: すでに登録されたステートメントをどのように失効させますか？
元のステートメントとレシートを保持したまま、失効またはリスクステータスのステートメントを追加します。検証者は時刻とポリシーを適用して現在の受け入れ可否を判断し、監査人は元の登録事実を保持します。
質問 4: リリース中に登録が利用できない場合はどうなりますか？
クライアントは署名付きステートメントとダイジェストをローカルに保存し、リリースに「透明性レシート未取得」とラベル付けします。復旧後、同じ冪等性キーで登録します。証明の欠如が検証済みとして提示されることは決してありません。
質問 5: ログからのプライバシー漏洩をどのように防ぎますか？
最小限の公開フィールドのみを登録し、テナントレベルのアクセスポリシーを適用し、暗号化された参照を使用します。監査用の検証可能なダイジェストを保持しながら、時刻、発行者、アーティファクトタイプは必要に応じてのみ集約します。
出典 1: RFC 9943 SCITT アーキテクチャ
RFC 9943は、署名付きステートメント、透明性サービス、レシート、および検証可能なデータ構造の証明を定義しています。また、登録エビデンスをアーティファクトストレージや依存関係解決から区別しています。これらの境界が、ここでのロール、登録フロー、レシート設計の基盤となっています。
出典 2: SCITT プロジェクト概要
SCITTプロジェクトは、サプライチェーンステートメントに対する監査可能で追跡可能、かつ検証可能な履歴について説明しています。この回答におけるテナント検証、ポリシーガバナンス、リージョン運用は、その目標を明確な設計トレードオフに変換したものです。
出典 3: ソフトウェアエンジニアリング面接の研究
ソフトウェアエンジニアリングの技術面接の準備に関する研究では、コミュニケーション、制約の明確化、技術的推論のバランスをとることの重要性が強調されています。確認の質問、簡潔なフレームワーク、障害時のフォローアップは、用語の暗記を評価するのではなく、それらのスキルを引き出すように設計されています。