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.