#fortify

Na markę Fortify składa się dziś kilka osobnych produktów, a nazwa w wymaganiach przetargu prawie nigdy nie oznacza jednego programu. Trzon stanowi analizator kodu źródłowego, obok niego stoją badanie działającej aplikacji od zewnątrz, sprawdzanie użytych bibliotek zewnętrznych, serwer gromadzący wyniki oraz wersja sprzedawana jako usługa, w której skanowanie odbywa się po stronie producenta. Historia marki jest równie złożona: spółka powstała w 2003 roku, w 2010 kupił ją Hewlett-Packard, w 2017 przeszła do Micro Focus, a od 2023 roku należy do OpenText, który firmuje dziś jej dokumentację własną nazwą.

Jeden język urzędowy dla dwudziestu języków programowania

Do urzędu wpływają pisma po polsku, po węgiersku i po japońsku. Zatrudnianie osobnego zespołu kontrolerów do każdego języka byłoby absurdem, więc urząd robi co innego: każde pismo przechodzi najpierw przez tłumaczy przysięgłych i dalej wędruje wyłącznie w jednej, urzędowej postaci. Kontrolerzy nie znają ani jednego z języków źródłowych. Znają tylko formularz i listę pytań, które mają do niego zadać.

Ten podział opisuje całą konstrukcję narzędzia. Znajomość języka programowania siedzi w tłumaczu, a wiedza o tym, co jest niebezpieczne, siedzi zupełnie gdzie indziej i nie wie, czy patrzy na Javę, czy na kod pisany w językach rodziny C.

Dwa etapy jednego badania

Praca dzieli się dosłownie na dwie komendy i ten podział trzeba zrozumieć przed pierwszym wdrożeniem. Etap pierwszy to tłumaczenie: pliki źródłowe razem z zależnościami i ustawieniami budowania zamieniane są na wspólną postać pośrednią. Etap drugi to analiza tej postaci, zakończona plikiem wyników, który otwiera się w osobnym programie do przeglądania albo wysyła na serwer.

Rozdzielenie ma praktyczny sens. Tłumaczenie musi odbyć się tam, gdzie kod daje się zbudować, czyli w tym samym środowisku co kompilacja. Analiza jest już zwykłym liczeniem na gotowym materiale, więc da się ją zepchnąć na osobne maszyny i wyjąć z komputera programisty, który nie powinien czekać godziny na wynik.

Kilku kontrolerów z różnymi listami pytań

Nad postacią pośrednią pracuje nie jeden mechanizm, tylko kilka, i każdy odpowiada na inne pytanie. Jeden śledzi drogę wartości od miejsca, w którym wchodzi z zewnątrz, aż do punktu, w którym zaczyna ona coś wykonywać. Drugi pilnuje kolejności operacji, na przykład użycia zasobu po jego zamknięciu. Trzeci ocenia samą strukturę kodu, czyli konstrukcje uznane za niebezpieczne niezależnie od danych. Czwarty czyta pliki ustawień aplikacji, gdzie nie ma ani jednej linii kodu, a bywa hasło i wyłączone szyfrowanie. Piąty zajmuje się operacjami na pamięci, co ma znaczenie głównie w językach, które pozwalają nią zarządzać ręcznie.

Wynik nie jest listą podejrzanych linii. Jest listą znalezisk, z których każde ma kategorię, wagę i, przy śledzeniu danych, całą trasę wypisaną plik po pliku.

Reguły przychodzą z zewnątrz i mają datę ważności

Analizatory same z siebie nie wiedzą, że dana funkcja jest groźna. Wiedzę tę niosą pakiety reguł wydawane przez zespół badawczy producenta i aktualizowane w rytmie kilku wydań rocznie. To one opisują, co jest źródłem danych, co ujściem, a co uznaną kontrolą.

Wniosek jest niewygodny, ale trzeba go znać: instalacja z regułami sprzed trzech lat nie zna bibliotek, które w tym czasie weszły do użycia, i nie zgłosi błędu z ich powodu. Wynik wygląda wtedy identycznie jak wynik czysty. Ważność subskrypcji reguł jest tu więc pozycją techniczną, nie tylko handlową.

Z czego składa się rodzina

Linia wydań idzie dziś według roku i kwartału, a dokumentacja publiczna sięga wydań z 2018 roku, co daje obraz tempa: kilka wydań rocznie, każde z własnym kompletem podręczników.

Etap, który zawodzi po cichu

Najgroźniejszy błąd we wdrożeniu nie polega na fałszywym trafieniu, tylko na tym, że tłumaczenie objęło mniej plików, niż się wydaje. Nierozpoznany szkielet aplikacji, brakująca zależność, kod generowany podczas budowania albo język, dla którego nie ma obsługi, nie zatrzymują przebiegu. Powodują, że część projektu nie trafia do postaci pośredniej, a skoro kontroler dostał cieńszą teczkę, to i uwag ma mniej.

Dlatego pierwszą liczbą, którą warto czytać w podsumowaniu, nie jest liczba znalezisk, tylko liczba i rodzaj plików faktycznie przetłumaczonych. Raport bez ostrzeżeń przy projekcie, którego połowa nie została objęta, jest gorszy od braku raportu, bo daje spokój.

Kiedy taki aparat stoi bezczynnie

Firma, która oprogramowania nie wytwarza, tylko kupuje gotowe i konfiguruje, nie ma tu czego zbadać, a jej ryzyko siedzi w wersjach, uprawnieniach i ustawieniach serwerów. Fortify nie rozstrzyga również tego, czy znaleziony błąd da się wykorzystać w konkretnym wdrożeniu, bo o warstwie stojącej przed aplikacją i o prawach do katalogów nie wie nic. Wreszcie kilkaset linii skryptów łączących systemy wewnętrzne nie uzasadnia ani takiej instalacji, ani godzin potrzebnych na przejrzenie wyników.