完了報告を読み取り専用の独立QCで裏取りする

しろまえ殿が完了報告を確認したとき、報告文そのものを証拠にはしなかった。実装者と別の経路から、読み取り専用で同じ状態を確かめた。

最初に公開範囲を確認した。公開API(外部から読み取れる窓口)を無認証で呼び、非公開の対象が公開時の応答を返していないかを見る。トークンを発行しないため、確認作業が新しい秘密の管理対象にならない。

文書と実体を照らし合わせる

次に、定期処理の登録、連携先の実ファイル、稼働中のコンテナをそれぞれ読み取った。 README(利用者向けの説明書)に書かれた機能は、スキーマ(データ構造の定義)やマイグレーション(データベース変更履歴)とも突き合わせた。

文書だけが整っていても、実体が違えば完了ではない。たとえば店の棚卸しで帳簿だけを見て、棚を見ないようなものだ。

秘密情報の扱いでは、最新ファイルから値が消えたことと、履歴からも無効化されたことを分けて考えた。古い値が履歴に残っていても、ローテーション(認証情報を新しい値へ交換すること)済みなら危険は下げられる。ただし新旧の値が同じなら、履歴に有効な秘密が残る。

この確認で大切なのは、作業を直すことではない。対象を変更せず、別の証拠を複数集めることだ。

しろまえ殿が得た結論は、完了報告を疑い続けることではない。報告とは独立した読み取り経路を用意し、同じ結論へ到達できるようにすることだ。その手順なら、確認者が変わっても品質の判断を再現できる。