Jak czytać raport z audytu VPN: zakres ważniejszy niż odznaka

Odznaki są tanie w pokazywaniu i drogie w interpretacji. Opublikowany raport z audytu to ograniczony kawałek pracy inżynierskiej: nazwany oceniający zbadał nazwane komponenty, w nazwanej wersji, z podaną metodą i budżetem czasu. Te cztery fakty decydują, co może uzasadniać wniosek, i zwykle znajdują się na pierwszych stronach, a nie w podsumowaniu marketingowym. Ich przeczytanie zajmuje dziesięć minut i zapobiega częstemu błędowi rozciągnięcia ustalenia o aplikacji klienckiej na całą usługę.

Co faktycznie ogranicza sekcja zakresu

Deklaracja zakresu to płot, a wszystko poza nim pozostaje bez odpowiedzi, a nie zaliczone. Raporty wymieniają zbadane komponenty, zakres commitów lub identyfikator kompilacji, użyte środowisko i dozwolony model interakcji. Klient desktopowy, aplikacja mobilna, kod serwera, backend konta i infrastruktura produkcyjna to pięć różnych tematów, a zlecenie może obejmować dowolny ich podzbiór.

Wyłączenia liczą się tak samo jak włączenia, bo są podawane celowo, a czytane niedbale. System kont opisany jako poza zakresem nie jest domyślnie bezpieczny, a aplikacja mobilna pominięta w zleceniu po prostu nie została zbadana. Oznacz każdy nieprzetestowany komponent we własnych notatkach jako nieznany i oprzyj się pokusie wypełnienia luki reputacją.

Dwa rodzaje testów odpowiadają na różne pytania

Przegląd kodu źródłowego i testy w działaniu szukają różnych awarii. Recenzent czytający kod może prześledzić wyprowadzenie klucza, zauważyć brak sprawdzenia długości i rozumować o całym parserze bez jego uruchamiania. Tester wobec działającej usługi odkrywa, co faktycznie robi wdrożona kompilacja: certyfikat, który aplikacja odrzuca, wciąż włączony protokół zapasowy, punkt końcowy wyciekający banner wersji przez konfigurację, której nikt nie przejrzał.

Żaden nie zastępuje drugiego, a raport zwykle wymienia, który wykonano. Gdy podsumowanie mówi „audytowane” bez tego rozróżnienia, niejednoznaczność jest w podsumowaniu, nie w raporcie.

Ograniczenia dostępu robią to samo. Zlecenie czarnej skrzynki nie widzi konfiguracji serwera, a przegląd architektury, który nigdy nie dotyka wdrożonego punktu końcowego, nie może zauważyć, że produkcja różni się od diagramu. Oba są uzasadnione; mieszanie ich wyników nie jest.

Jak ustalenie staje się poprawioną wersją

Cenna połowa raportu to tabela napraw: każde ustalenie, jego waga według metody oceniającego, odpowiedź operatora i wynik ponownego testu. Liczby wagi pochodzą z wybranej metodologii, a nie z natury, więc porównuj wagi w jednym raporcie, a nie między dwoma o różnych skalach.

Następnie powiąż poprawkę z wydanym oprogramowaniem. Poprawione ustalenie ma znaczenie dla użytkownika dopiero wtedy, gdy zainstalowana jest wersja zawierająca poprawkę, dlatego identyfikator kompilacji z raportu i dziennik zmian wydania trzeba czytać razem. Ponowny test obejmujący poprawkę zamyka pętlę; nieprzetestowana poprawka jest twierdzeniem. Tak samo poprawka wydana tylko w gałęzi, której żadne stabilne wydanie nigdy nie scaliło.

Czego odznaka nie może ci powiedzieć

Brak ustaleń nie jest dowodem braku wad. Krótkie zlecenie ze stałym budżetem coś przeoczy, a uczciwe odczytanie czystego raportu jest takie, że oceniający nie znalazł poszukiwanych klas problemów w dostępnym czasie.

Odznaka nie może też mówić o właściwościach spoza swojego zakresu. Twierdzenia o praktykach logowania, jurysdykcji lub przechowywaniu żyją w dokumencie polityki, a nie w audycie aplikacji klienckiej, i żadna reputacja oceniającego nie przekracza tej granicy.

Zapisywanie dowodów, których możesz bronić

Zapisz cytat w trzech częściach: komponent, wersja i zweryfikowana poprawka. Opublikowane zlecenie, takie jak audyt VPN zamówiony przez Mozillę wspiera dokładnie te twierdzenia, które opisuje jego zakres, i nic szerszego, co wciąż jest sporo warte, gdy cytat jest precyzyjny. Ten sam raport cytowany na coś, czego nigdy nie zbadał, jest wart mniej niż brak cytatu, bo zaprasza zaufanie, na które nikt nie zasłużył.

Gdy twierdzona właściwość wypada poza każdy dostępny raport, pozostaw ją w dokumencie nierozstrzygniętą. Nierozstrzygnięta linia zaprasza do pytania uzupełniającego; odznaka nie. Jedynym wyjątkiem jest właściwość, którą rozstrzyga inny, równie konkretny dokument, i wtedy zmienia się cytat, a nie twierdzenie.

Dwa kolejne nawyki czynią lekturę trwałą: zapisz datę raportu wobec wydania, które naprawdę uruchamiasz, i utrzymuj różnicę między tym, co przetestowano, a tym, co wdrożyłeś. Oba zamieniają decyzję o zaufaniu w coś, co kolega może sprawdzić.