Analiza kodu źródłowego aplikacji jest realizowana w oparciu o najlepsze praktyki w obszarze bezpiecznego wytwarzania oprogramowania oraz zalecenia organizacji OWASP (standard ASVS oraz MASVS).
Analiza kodu źródłowego może być wspierana przez wyniki przeprowadzonych testów penetracyjnych.
W ramach naszych prac zrealizujemy statyczną analizę kodu źródłowego, która będzie dotyczyła najistotniejszych funkcjonalności z punktu widzenia bezpieczeństwa, m.in.:
- Obsługa wejścia i wyjścia z aplikacji,
- Walidacja danych,
- Uwierzytelnianie i autoryzacja,
- Mechanizmy kryptograficzne,
- Zarządzanie pamięcią,
- Obsługa błędów,
- Odwołania do systemu operacyjnego,
- Logowanie.
- Przeprowadzenie wywiadu z architektami aplikacji lub wiodącymi programistami w celu uzyskania informacji o jej funkcjach biznesowych oraz o jej strukturze wewnętrznej,
- Oczyszczenie kodu źródłowego z kodów testowych oraz nieużywanych fragmentów kodu, a także oznaczenie kodów bibliotek zewnętrznych,
- Przeprowadzenie statycznej analizy kodu z użyciem narzędzi automatycznych w celu zidentyfikowania podatności wykrywanych tymi narzędziami,
- Manualna weryfikacja wyników uzyskanych z narzędzi automatycznych,
- Uzupełnienie analizy za pomocą manualnych kontroli na podstawie list kontrolnych opisujących różne typy podatności adekwatne dla stosowanego języka programowania,
- Przedyskutowanie wyników prac z architektami aplikacji lub wiodącymi programistami w celu określenie poziomu ryzyka podatności i podejścia zespołu programistycznego,
- Przygotowanie raportu zawierającego listę zidentyfikowanych podatności wraz z rekomendacjami ich usunięcia.
Nowoczesny przegląd podatności kodu źródłowego nie kończy się na automatycznym skanowaniu. Najlepsze efekty daje połączenie narzędzi statycznych, dynamicznych oraz ręcznej weryfikacji miejsc, w których logika aplikacji naprawdę decyduje o ryzyku. Dzięki temu można wychwycić nie tylko oczywiste błędy, ale też słabe punkty związane z autoryzacją, obsługą danych wejściowych, błędami konfiguracji czy niebezpiecznymi zależnościami.
Kiedy samo skanowanie nie wystarcza?
Automatyczne narzędzia dobrze wykrywają powtarzalne problemy, ale często generują też wyniki wymagające doprecyzowania. Dlatego statyczna analiza kodu powinna być uzupełniana o ocenę kontekstu biznesowego i technicznego. W praktyce oznacza to sprawdzenie, czy dana podatność rzeczywiście da się wykorzystać, jak wpływa na dane, dostępność systemu i ciągłość działania oraz czy dotyczy elementu krytycznego dla całej aplikacji.
W przeglądzie podatności kodu źródłowego ważne jest też uporządkowanie wyników. Nie każda luka ma taki sam ciężar. Inaczej ocenia się błąd w module administracyjnym, a inaczej pojedynczy problem w mało używanej funkcji. Taka selekcja oszczędza czas zespołu i pozwala szybciej przejść do poprawek, które realnie zmniejszają ryzyko.
Jak łączyć SAST i DAST, żeby zobaczyć pełniejszy obraz?
SAST pomaga znaleźć podatności w samym kodzie, zanim trafi on na środowisko produkcyjne. DAST sprawdza aplikację z zewnątrz, już podczas działania, dzięki czemu pokazuje skutki błędów w praktyce. Razem dają lepszy obraz niż pojedyncza technika, bo ujawniają zarówno przyczyny, jak i sposób wykorzystania problemu.
To połączenie jest szczególnie przydatne przy aplikacjach webowych i usługach API, gdzie liczy się nie tylko jakość implementacji, ale też zachowanie całego systemu pod obciążeniem, przy błędnych danych i w nietypowych scenariuszach dostępu. Jeśli projekt obejmuje także interfejsy publiczne, dobrym uzupełnieniem są testy bezpieczeństwa aplikacji web, które pomagają zweryfikować, czy podatności widoczne w kodzie rzeczywiście przekładają się na możliwość ataku.
Jak ustalić, co naprawiać najpierw?
Priorytetyzacja powinna brać pod uwagę kilka kryteriów jednocześnie. Najważniejsze są: możliwość wykorzystania luki, poziom dostępu potrzebny napastnikowi, wpływ na dane lub procesy biznesowe, zasięg problemu oraz to, czy podatność występuje w kodzie wielokrotnie. Duże znaczenie ma też łatwość wdrożenia poprawki. Czasem niewielka zmiana usuwa całą klasę błędów, a czasem potrzebna jest przebudowa fragmentu logiki.
Warto też rozdzielić podatności na te, które można usunąć od razu, i te, które wymagają zaplanowanego działania. Dzięki temu zespół nie traci czasu na problemy o niskim wpływie, gdy obok znajduje się luka otwierająca drogę do przejęcia konta, wycieku danych lub obejścia mechanizmów kontroli dostępu.
Jak wygląda dobry rezultat takiego przeglądu?
Dobry wynik pracy to nie tylko lista błędów. To również jasna informacja, gdzie problem występuje, jaki ma wpływ, jak można go wykorzystać i jak najlepiej go naprawić. Przydatne są także wskazówki, które pozwalają programistom od razu przejść do wdrożenia zmian bez dodatkowych domysłów.
Jeśli zależy Ci na uporządkowaniu ryzyk w aplikacji, opisz zakres systemu i zamów analizę. Gdy potrzebujesz oceny kilku obszarów naraz, warto połączyć ją z innymi usługami, na przykład z audytem bezpieczeństwa informatycznego albo zewnętrzną weryfikacją infrastruktury. Skontaktuj się z zespołem INVIRE, jeśli chcesz ustalić, które elementy kodu wymagają pilnej uwagi, a które można zaplanować w kolejnym etapie prac.