#checkmarx

Zadaniem Checkmarxa jest rozstrzygnięcie jednej rzeczy: czy w napisanym kodzie istnieje trasa, którą tekst wprowadzony przez obcą osobę dochodzi do miejsca robiącego coś poważnego, i czy ktokolwiek ten tekst po drodze sprawdza. Program nie zostaje przy tym włączony. Materiałem są pliki źródłowe, więc badanie da się przeprowadzić na kodzie, który nie nadaje się jeszcze do uruchomienia.

Porządkuje to obraz planu instalacji wodnej rozłożonego na stole. Przyłącze z ulicy jest miejscem, w którym do budynku wchodzi woda o nieznanej jakości. Kran w kuchni jest miejscem, gdzie ktoś ją wypije. Pomiędzy biegną rury przez piwnicę, pion i trzy mieszkania, a gdzieś na tej trasie powinien stać filtr. Osoba czytająca plan nie odkręca ani jednego kurka. Prowadzi palcem po liniach i szuka takiego przebiegu od przyłącza do kranu, na którym filtra nie ma.

Źródło, ujście i kontrola pomiędzy nimi

Trzy pojęcia wystarczą do zrozumienia całej reszty. Źródłem jest każde miejsce, przez które do programu wchodzi wartość spoza niego: pole formularza, nagłówek żądania, nazwa wgranego pliku, fragment adresu, odpowiedź obcego systemu. Ujściem jest miejsce, w którym wartość przestaje być tekstem i zaczyna coś robić: trafia do zapytania o dane, do polecenia systemu, do ścieżki pliku, do strony odsyłanej przeglądarce. Kontrolą jest wszystko, co po drodze tę wartość obrabia tak, żeby przestała być groźna.

Znaleziskiem nie jest pojedyncza linia, tylko cała trasa wypisana po kolei: wejście w pliku pierwszym, przekazanie przez metodę w drugim, zapis do pola obiektu, odczyt w trzecim i użycie w czwartym. Wartość takiego wyniku siedzi właśnie w tej liście, bo pokazuje, w którym z pięciu miejsc naprawa ma sens.

Kod zamieniony w graf zależności

Silnik czyta pliki i buduje z nich strukturę opisującą składnię, a potem łączy struktury z różnych plików ze sobą: która funkcja woła którą, skąd zmienna bierze wartość, co dziedziczy po czym. Powstaje graf obejmujący całe repozytorium, także przejścia między językami, na przykład z szablonu strony do funkcji po stronie serwera.

Osobną cechą jest to, że taka analiza nie wymaga zbudowania aplikacji. Wystarczy sam kod, więc da się zbadać gałąź, która się nie kompiluje, albo projekt, którego środowiska nikt już nie potrafi odtworzyć. Cena jest po stronie silnika: konwencje każdego frameworka musi rozpoznawać sam, a framework nieznany producentowi daje zarówno nadmiar trafień, jak i ciszę tam, gdzie trasa naprawdę istnieje.

Zapytania zamiast zamkniętej listy reguł

Reguły nie są w tym produkcie stałą listą, tylko zapytaniami zadawanymi grafowi we własnym języku. Zapytanie nazywa źródła, ujścia i funkcje uznawane za kontrolę, a silnik szuka połączeń. Konsekwencja jest praktyczna: firmową funkcję czyszczącą dane można dopisać jako kontrolę i wygasić w ten sposób całą klasę fałszywych trafień, a wewnętrzną bibliotekę pobierającą pliki od kontrahenta oznaczyć jako źródło, którego producent nie mógł przewidzieć. Wymaga to kogoś, kto zna i język zapytań, i tę konkretną aplikację.

Badanie kodu a badanie działającej aplikacji

Skaner pracujący od zewnątrz ogląda wyłącznie to, do czego da się dojść przez interfejs, i tylko tam, gdzie zdołał się zalogować. Lektura kodu obejmuje również gałęzie nieosiągalne z przeglądarki: zadania uruchamiane nocą, obsługę zdarzeń z kolejki, panel dostępny po włączeniu ustawienia, kod martwy od dwóch lat i wciąż wdrażany.

Odwrotność też obowiązuje. Z plików źródłowych nie widać wersji serwera, uprawnień do katalogów ani tego, że przed aplikacją stoi warstwa odcinająca część żądań. Pierwsze badanie mówi, że błąd jest zapisany w programie. Drugie mówi, że da się go wykorzystać dzisiaj, pod tym adresem. To są dwa różne zdania i żadne nie zastępuje drugiego.

Marka, właściciel i skład dzisiejszego produktu

Producentem jest Checkmarx Ltd. Od 2020 roku spółkę kontroluje fundusz Hellman & Friedman, który kupił ją od poprzedniego inwestora za około 1,15 miliarda dolarów, przy mniejszościowym udziale funduszu TPG. Sprzedaż idzie dziś jako platforma obudowana wokół analizy kodu, w której obok niej stoją badanie zależności otwartoźródłowych, kontrola plików opisujących infrastrukturę i wyszukiwanie sekretów wpisanych do repozytorium. Nazwa w wymaganiach przetargu oznacza więc zwykle całą tę platformę, a nie sam silnik, i przy czytaniu takiego zapisu warto ustalić, o który składnik naprawdę chodzi.

Skąd bierze się nadmiar trafień

Analiza jest ostrożna z założenia: skoro trasa istnieje w grafie, zostanie zgłoszona, nawet jeśli w rzeczywistym przebiegu nigdy się nie zrealizuje, bo wcześniej wartość jest ograniczana warunkiem, którego silnik nie umie policzyć. Pierwsze uruchomienie na dojrzałym repozytorium potrafi wypisać tysiące pozycji i sama ta liczba blokuje pracę.

Wyjściem jest ustalenie stanu wyjściowego jako punktu odniesienia i zatrzymywanie wyłącznie tego, co dochodzi w nowym kodzie, a obok tego cierpliwe strojenie zapytań. Koszt ukryty nie leży zatem w licencji, tylko w godzinach kogoś, kto rozumie te trasy na tyle, żeby odrzucić połowę z nich bez otwierania drzwi.

Czego lektura kodu nie pokaże

Sklep kupiony jako gotowy produkt bez praw do źródeł nie daje materiału do badania, a jego ryzyko siedzi w aktualnościach i hasłach do panelu. Poza zasięgiem zostają też błędy sensu: rabat naliczony dwa razy, faktura wystawiona na złą firmę, brakująca kontrola uprawnień, której nie widać, bo w kodzie nie ma nic, co dałoby się wskazać palcem. Wreszcie sama nieobecność trasy nie jest świadectwem zdrowia aplikacji, tylko świadectwem tego, że w tym kodzie tej konkretnej trasy nie znaleziono.