Audyt kodu aplikacji: co sprawdzam i jak wygląda raport
Kupujesz firmę razem z jej systemem, planujesz dużą rozbudowę albo dostałeś kod od wykonawcy i nie wiesz, w jakim jest stanie. Niezależny przegląd pokazuje to, zanim podpiszesz umowę lub zlecisz kolejny etap.
Autor: Szymon Łakomy. Aktualizacja:
Kiedy zamawia się audyt kodu
| Sytuacja | Pytanie, na które odpowiada audyt |
|---|---|
| Zakup firmy lub produktu z aplikacją | czy system da się utrzymać i rozwijać bez jego autora |
| Planowana rozbudowa | czy dopisać moduł do obecnego kodu, czy najpierw coś przebudować |
| Odbiór od wykonawcy | czy kod odpowiada umowie i uruchamia się bez pomocy wykonawcy |
| Aplikacja zwalnia lub często się psuje | gdzie leży przyczyna i co poprawić najpierw |
| Kontrola po stronie klienta korporacyjnego | które luki zamknąć, zanim wskaże je ktoś inny |
Gdy poprzedni programista już nie odpowiada i trzeba przede wszystkim odzyskać dostępy, zaczynam od kroków opisanych przy przejęciu projektu po innym programiście. Kod wygenerowany w narzędziach AI ma swoje typowe luki, o których piszę na stronie naprawa aplikacji napisanej przez AI.
Zakres przeglądu: sześć obszarów
Bezpieczeństwo
Hasła i klucze w repozytorium, uprawnienia w API, walidacja danych od użytkownika, sesje, pliki wgrywane przez użytkowników.
Zależności
Biblioteki bez wsparcia, znane podatności w używanych wersjach, pakiety porzucone przez autorów.
Testy
Czy istnieją, co obejmują i czy uruchamiają się przy każdej zmianie. Brak testów przy obliczeniach finansowych oznaczam jako ryzyko.
Architektura i baza
Podział na moduły, powielony kod, struktura tabel, migracje, zapytania, które zwolnią przy większej ilości danych.
Wdrażanie
Jak kod trafia na serwer, czy jest środowisko testowe, czy kopie bazy ktoś kiedykolwiek odtworzył.
Dokumentacja
Instrukcja uruchomienia, opis konfiguracji i wiedza, która istnieje tylko w głowie autora.
Jak przebiega audyt
- Dostęp do repozytorium tylko do odczytu i rozmowa o tym, do czego aplikacja służy i co Cię niepokoi.
- Uruchomienie projektu na moim komputerze. Już ten krok pokazuje, czy instrukcja i konfiguracja są kompletne.
- Przegląd ręczny oraz narzędzia, które wyszukują podatności w zależnościach i typowe błędy w kodzie.
- Raport i spotkanie, na którym przechodzimy przez najważniejsze punkty.
Nie potrzebuję produkcyjnej bazy z danymi klientów. Wystarczy struktura bazy albo kopia z danymi zanonimizowanymi. Przed dostępem do kodu podpisuję umowę o poufności.
Co jest w raporcie
Raport ma dwóch odbiorców: osobę, która podejmuje decyzję, i programistę, który będzie poprawiał. Zawiera:
- podsumowanie na jedną stronę ze stanem aplikacji i najważniejszymi ryzykami,
- listę problemów w trzech grupach: krytyczne, do poprawy przed rozbudową, do uporządkowania przy okazji,
- dla każdego problemu miejsce w kodzie, skutek i propozycję poprawki,
- szacunek pracy dla punktów krytycznych, żeby było jasne, czy chodzi o dni, czy o przebudowę.
Po raporcie: poprawki, rozbudowa albo nowy system
Raport nie zobowiązuje do zlecenia mi poprawek. Możesz przekazać go obecnemu wykonawcy albo własnemu zespołowi. Gdy wynik pokazuje, że kodu nie da się rozsądnie rozwijać, kolejnym krokiem jest plan wymiany etapami, który opisuję przy modernizacji starego systemu firmowego. Aplikacja w dobrym stanie może przejść pod stałe utrzymanie aplikacji webowej.
Najczęstsze pytania
Jakie technologie obejmuje audyt?
Najgłębiej sprawdzam projekty w Pythonie (Django, FastAPI) oraz w React i TypeScript, bo w nich pracuję na co dzień. Przy innym stosie mówię na początku, które obszary ocenię rzetelnie, a które lepiej powierzyć komuś innemu.
Czy audyt kodu zastępuje test penetracyjny?
Nie. Przegląd kodu wykrywa wiele luk od środka, a test penetracyjny sprawdza działającą aplikację z zewnątrz, tak jak robiłby to atakujący. Przy aplikacjach z danymi wrażliwymi przydają się oba.
Ile trwa audyt?
Zależy od wielkości kodu i liczby integracji. Termin podaję po pierwszym spojrzeniu na repozytorium, a przy zakupie firmy dopasowuję go do harmonogramu transakcji.
Czy wykonawca kodu dowie się o audycie?
To Twoja decyzja. Często dobrze go uprzedzić, bo odpowie na pytania o konfigurację szybciej, niż sam ją odtworzę. Raport opisuje kod, a nie ocenia ludzi.
Powiązane strony
Chcesz wiedzieć, w jakim stanie jest kod?
Napisz, czego dotyczy decyzja i w jakiej technologii powstała aplikacja. Odpowiem z zakresem przeglądu i terminem.