Dlaczego ustalenia o niskiej wadze mówią więcej o Twoim audycie niż krytyczne błędy Wiele firm audytorskich koncentruje swoją ofertę na liczbie znalezionych błędów wysokiej wagi, jakby ta liczba nie była tylko szumem bez kontekstu: wcześniejsze audyty, przegląd rówieśniczy, poziomy pokrycia testami, złożoność kodu, liczba linii i wiele innych wskaźników. To najniższa forma sprzedaży, nie różniąca się od porównywania na przykład jakości pamięci USB na podstawie ich długości w milimetrach. Aby pokazać alternatywę, najpierw musimy potwierdzić poprawność kilku wspierających twierdzeń: - Prawdopodobieństwo przypadkowego wprowadzenia błędu nie ma tendencji do wyższych skutków (programiści nie są bardziej lekkomyślni w kodzie o wysokiej stawce, zazwyczaj jest wręcz przeciwnie). - Te same kompleksowe metody stosowane do odkrywania wad o różnych ciężkościach również odkryją problemy o wysokiej wadze (przeciwieństwo nie ma miejsca). - Istnieją znacznie wyższe wymagania, aby losowy błąd kwalifikował się jako błąd wysokiej wagi (często byłby zablokowany za niedostępnymi warunkami lub dotykałby funkcjonalności niekrytycznej). - Z podstawowej statystyki: wyższa częstotliwość próbkowania koreluje z niższą oczekiwaną odchyleniem/wariancją, a zatem dokładniejszym pomiarem. Zdefiniujmy raport audytowy jako wynik próbkowania jakości bazy kodu. Wnioskujemy, że oczekiwana prawdziwa (bez pominięć) liczba błędów wysokiej wagi jest znacznie niższa niż błędów niskiej wagi, a oczekiwane odchylenie wokół niej jest znacznie wyższe (z powodu mniejszej próbki). Innymi słowy, liczba błędów wysokiej wagi mówi nam bardzo niewiele o liczbie pominiętych błędów wysokiej wagi. Zaskakująco, raport 1 błąd wysokiej wagi, 10 błędów niskiej wagi jest bardziej uspokajający niż raport 10 błędów wysokiej wagi, 1 błąd niskiej wagi, przy równych innych warunkach. Chociaż w rzeczywistości zdecydowana większość sprzedawców wolałaby pokazać to drugie jako wskaźnik jakości. Chodzi o to, że wskaźnik o wysokiej częstotliwości jest lepszym narzędziem do pomiaru wyników o niskiej częstotliwości. Budowniczowie Web3, następnym razem, gdy firmy będą machać przed Wami swoimi liczbami Crit/High i X miliardami $ zabezpieczonymi, wiecie, na czym skupić się, aby szukać prawdziwego sygnału. Audytorzy Web3, uznajcie, że nie ma żadnej spójnej tajnej formuły na znalezienie wszystkich błędów wysokiej wagi bez również poszukiwania błędów niskiej wagi - każdy błąd niskiej wagi, który nie został w pełni zbadany, jest potencjalnym błędem wysokiej wagi - i poświęćcie swoją najlepszą uwagę każdej pojedynczej linii. Wasz klient Wam za to podziękuje. Niska waga jest definiowana jako konkretne błędy w kodowaniu, które nie prowadzą do wyższych skutków. Nie obejmuje formatowania, najlepszych praktyk i wyników dodatkowych.

Krytyczna luka w git, która została wydana wczoraj, może być wywołana przez git clone z nieufnego repozytorium. To idealny wektor do przejęcia audytorów i kradzieży ich nagród / pieniędzy z audytów. Zaktualizuj swoje systemy przed przyjęciem jakichkolwiek nowych klientów! I spodziewaj się gości w swojej skrzynce odbiorczej w nadchodzących tygodniach...

Okazuje się, że można zdobyć nagrody pięcio-znakowe w konkursach, nie odkrywając żadnych problemów, wystarczy mieć półfunkcjonalny mózg. W konkursie OP Fault Proofs w marcu 2024 roku, deweloperzy naprawili krytyczny problem dzień przed jego rozpoczęciem, ale nie wprowadzili go do kodu. 🔗 Patrząc tylko na publiczny dziennik commitów, zdobywasz wysoką nagrodę 🔗 🔗 Ostatecznie była to nagroda w wysokości 16680 dolarów: To tylko jeden z wielu trików, aby znaleźć błędy w zakresie, nie szukając ich faktycznie. Zawsze staraj się pracować mądrze, a nie ciężko.

Postanowiłem spróbować Cantiny w zeszłym październiku, 8 miesięcy później wyniki w końcu są dostępne... Kilka solowych odkryć w pierwszym audycie Java i przewyższanie najlepszych braci z leaderboardu Cantiny o 3-7x czuje się całkiem dobrze, nie będę kłamać. Szkoda, że doświadczenie po audycie było tak straszne, że przysiągłem nigdy nie wrócić na tę platformę. *ostrzeżenie o uzasadnionym narzekaniu* - Czas rozwiązania 8 miesięcy, w momencie pisania - nagroda wciąż nie została wysłana. - Dziesiątki godzin spędzonych na eskalacji i obronie zgłoszeń przed błędnymi werdyktami. - Policzono ~ 104 błędy w ocenie (błędne duplikaty, wyraźne nieważne, błędna powaga), które zostały skorygowane. Więcej, które nie zostały. - Utrata wartości wynosząca ~$110,000 z powodu tego, że rozwiązanie zajęło 7 miesięcy dłużej niż powinno, a token OP spadł do ~50 centów. Pewnie, gdy rywalizujesz w konkursach z nagrodami w walutach innych niż USD, wahania są akceptowanym ryzykiem. Ale 8 miesięcy niekompetentnych sędziów i brak możliwości zakończenia konkursu nie było częścią mojego modelu zagrożeń. W czasach oceniania C4 przetwarzałem w pełni 1000 odkryć w mniej niż tydzień (solo), OP-Java miało 360 i wielu sędziów. Nie jest zaskoczeniem, że Cantina nigdy nie ogłosiła wyników w mediach społecznościowych, w przeciwieństwie do 5 innych konkursów, które zakończyły się w tym tygodniu, z pewnością nie mogło być tak, że chcieli uniknąć złej prasy lub podkreślenia dominacji TrustSec, prawda? Szkoda, że musimy nadal dyskutować o nadużyciach platform nagród zamiast o krytycznych błędach, ale nie ma innego wyjścia, jak tylko trzymać wszystkich odpowiedzialnych. Post bez narzekania z technicznym podsumowaniem dla solowych odkryć pojawi się wkrótce.

Wyobraź sobie świat, w którym stwierdzenie, że badacze nie powinni być wykorzystywani, jest kontrowersyjnym poglądem.. To właśnie się dzieje, gdy firma z nieograniczonymi funduszami pojawia się i kupuje sobie dominację na rynku. Zrzucanie na badaczy polityki eksploatacyjne staje się po prostu nową równowagą Nasha.

Każdego dnia staje się coraz bardziej oczywiste, że @cantinaxyz jest podmiotem wyzyskującym i ma negatywny wpływ na przestrzeń. Tydzień po znakomitym artykule @jack__sanforda na temat licznych niedociągnięć konkursu Cork i brak jakiejkolwiek reakcji wkrótce. Przy ilości uwagi, jaką ten artykuł otrzymał, gdyby mogli się bronić, z pewnością by to zrobili, czyli milczenie to przyznanie się do winy. W tym tygodniu nasza propozycja nagrody Cantina, którą zgodzili się pokazać jako ograniczoną stratę funduszy dla operatora blockchaina o wysokim prawdopodobieństwie, zakończyła się mediacją na niskim poziomie powagi. Po przeczytaniu dziesiątek raportów Spearbit/Cantina i setek opisów nagród, strata finansowa jakiejkolwiek kwoty nigdy nie jest poniżej średniego wpływu, więc wyraźnie przekazują perspektywę sponsora w klasycznym podejściu "klient ma zawsze rację", jak to zawsze robią. W rzeczywistości nawet tego nie ukrywają. Z ich własnych dokumentów wynika, że domyślnie przyjmują perspektywę klienta. Chyba tylko w najbardziej rażących przypadkach odrzucają zdanie klienta. A co jeśli klient po prostu zignoruje ich mediację? Na każdej innej platformie (np. @immunefi), z którą współpracowaliśmy, brak poszanowania mediacji jest podstawą do natychmiastowego usunięcia klienta. Na Cantina klient ma przyzwolenie na 5 oszustw nagród rocznie. Tak, dobrze przeczytałeś. Ostatnio odkryliśmy również, że ich program Fellowship ma bardzo agresywną klauzulę o wyłączności. Fellows nie mogą składać niczego na innych platformach nagród ani bezpośrednio informować projektów, nawet jeśli ryzykują miliony dolarów. Zamiast tego ta wysoce wrażliwa i krytyczna wiedza musi być dzielona z Cantina, która decyduje, jak postępować. Oni są szefami, oni podejmują decyzje, mentalność "ukłon się lub odejdź". Mamy więcej przykładów skandalicznego traktowania na Cantina, ale zostawimy je na inny dzień. Na razie chcemy zwiększyć świadomość, jak inni czołowi członkowie społeczności, że audytorzy powinni głosować swoimi nogami, jeśli chodzi o to, gdzie spędzają swój cenny czas na polowaniu. Platforma bezpieczeństwa, która traci równowagę i faworyzuje projekty kosztem łowców nagród, podważa cały proces białego kapelusza i zachęca badaczy do zarabiania na swoje życie w mniej etyczny sposób! Pracujmy jako społeczność, aby wzmocnić organizacje o wysokiej integralności, przejrzystości i pozytywnym wpływie nad branżowymi tyranami. Powyższe oświadczenie jest osobistą opinią członków zarządu TrustSec i powinno być interpretowane jako takie.

- Utrzymuj zmieniające stan LoC poniżej 500 - używaj wzorca ++counter do mapowania kluczy - nie wspieraj tokenów natywnych - trzymaj maszynę stanów w otwartym widoku za pomocą enumów stanu - stosunek testów do LoC 1:1 - formatuj każdą linię kodu za pomocą linijki Widzisz, wygranie gry nie jest takie trudne.

Jako weteran branży konkursów audytorskich opowiem Ci, jak zawierane są takie transakcje. > Bądź protokołem z pieniędzmi i wykonuj 3+ wspólnych audytów > Wiedz, że baza kodu prawdopodobnie nie zawiera znaczących błędów > Chcesz zasygnalizować społeczności, inwestorom i innym interesariuszom, że zależy Ci na bezpieczeństwie > Nie masz zamiaru wydawać więcej pieniędzy na bezpieczeństwo > Platforma "Konkurs" ma rozwiązanie > Zorganizuj konkurs na dywan, gwarantując, że pule High/Crit nie zostaną odblokowane > Spraw, aby doniczka Med była bardzo mała > Jeśli znaleziono High, zbagatelizuj sumission, w przeciwnym razie klient będzie niezadowolony (pamiętasz Eulera?) > Zarówno platformę "Konkurs", jak i otrzymujesz darmowy marketing > SR wytrzymały, ale nie obchodzi cię to > Powtórz, ale spraw, aby ogłoszenie o następnym konkursie dywanów było jeszcze bardziej optymistyczne.

Ostrzeżenie ⚠️ : Nie jest to nowy zapis o nagrodzie My, audytorzy, lubimy skupiać się na soczystych trafieniach krytycznych i ograniczać do minimum prace niezwiązane z technologią. Kto by się przejmował papierkową robotą i spotkaniami, skoro właśnie znalazłeś nowatorski sposób na opróżnienie kontraktu DeFi? Ale wszystko powinno być robione z umiarem i zbyt często widzimy, jak niezależni badacze całkowicie oszczędzają na podpisaniu nawet podstawowej umowy z klientem. To było coś, co robiliśmy również w pierwszych miesiącach TrustSec - połączyliśmy się z klientem na TG / discordzie, omówiliśmy zespół, cenę i harmonogram i po prostu zaczęliśmy. Czułem się płynnie i bez tarcia, więc w czym problem? Podobnie jak w przypadku wielu rzeczy, działa dobrze, dopóki nie przestanie. Kiedy zarządzasz 50+ audytami rocznie, zaczynasz napotykać skrajne przypadki. A kiedy to zrobisz, wyjaśnienie spraw z wyprzedzeniem pozwoli uniknąć mnóstwa tarć w potencjalnie wrażliwych punktach na osi czasu audytu. Widzisz, sens umowy o świadczenie usług nie polega na tym, że można ją zaskarżyć w sądzie oddalonym o tysiące kilometrów od Twojej obecnej lokalizacji. Oczywiście, w najgorszym przypadku może tak być. Ale przede wszystkim robi się to po to, aby wyrównać oczekiwania obu stron, sposób na zmuszenie dwóch stron do rozmowy o szczegółach, których w przeciwnym razie by nie omówiły. Oto tylko kilka scenariuszy, które pojawiły się i powinny być jawnie obsługiwane: - Klient nie jest gotowy z ostatecznym zatwierdzeniem przed datą rozpoczęcia. - Z nieprzewidzianych przyczyn co najmniej jeden audytor nie jest dostępny w części lub w całym okresie audytu. - Ostateczny zakres wymaga dłuższego czasu weryfikacji, co zwiększa koszty. - Dyskusja na temat tego, które narzędzie i formatowanie jest używane do liczenia końcowego SLOC. - Klient wprowadza nową funkcjonalność do sprawdzenia w audycie poprawek. - Prośba o wysłanie płatności dopiero po dostarczeniu raportu. - Klient chce anulować audyt z zaledwie 24-godzinnym wyprzedzeniem. - Klient chce wysłać płatność na preferowanym przez siebie blockchainie. - Zastrzeżenia co do publikacji raportu po akceptowalnym okresie oczekiwania. Oprócz jasnego określenia, jak postępować w takich sytuacjach, umowa zapewnia również audytorom krytyczną ochronę: - Zrzeka się wszelkiej odpowiedzialności za pominięte błędy i exploity. - Utrzymuje prawa własności intelektualnej do narzędzi, koncepcji ataków opracowanych w trakcie audytu (w zakresie, w jakim pozwalają na to przepisy prawa). - Ustala zaliczki, opłaty za anulowanie i tak dalej. - Spełnia wymogi należytej staranności, KYB i ramy prawne. Jest to istotne z punktu widzenia wymogów dotyczących opodatkowania, zgodności i źródła finansowania. Z tych powodów szybko stwierdziliśmy, że warto poświęcić trochę dodatkowego czasu przed dokonaniem rezerwacji i zachęcamy każdego audytora prowadzącego legalną działalność do zrobienia tego samego.

Pod koniec 2024 roku TrustSec wykrył błąd konsensusu w @OPLabsPBC kliencie Optimism. W najgorszym przypadku op-node miałby błędny widok stanu L2, powodując rozdzielenie łańcucha od innych klientów. Za nasze badania OP Labs hojnie przyznało nam nagrodę w wysokości 7,5 tys. USD. Sprawdź wszystkie szczegóły w poniższym artykule technicznym!