Audyt bezpieczeństwa aplikacji webowej

Kiedy warto rozpocząć od audytu

Przed uruchomieniem ważnej funkcji

Aplikacja ma otrzymać nowe logowanie, płatności, panel klienta, role pracowników, integrację albo API. Chcesz sprawdzić uzgodniony obszar, zanim zacznie obsługiwać rzeczywistych użytkowników i dane.

Po zmianie wykonawcy lub przejęciu systemu

Masz działającą aplikację, ale nie wiesz, które decyzje dotyczące dostępu, konfiguracji i ochrony danych zostały wcześniej sprawdzone. Audyt może pomóc oddzielić pilne problemy od tematów, które można zaplanować później.

Przed większą rozbudową

System ma dostać nowe role, moduły lub integracje. Warto najpierw poznać istniejące ograniczenia, aby dalszy rozwój nie utrwalił problemów w kolejnych częściach aplikacji.

Gdy pojawiają się niepokojące zachowania

Użytkownicy widzą dane, do których nie powinni mieć dostępu, logowanie zachowuje się nierówno, API zwraca zbyt szerokie informacje albo konfiguracja budzi wątpliwości. Najpierw ustalamy, czy potrzebny jest planowy audyt, czy pilna obsługa incydentu.

Gdy potrzebujesz kolejności napraw

Lista ostrzeżeń z automatycznego skanera nie mówi jeszcze, co rzeczywiście działa w danej aplikacji i co ma największe znaczenie dla firmy. Potrzebujesz potwierdzenia, kontekstu i priorytetów.

Audyt, konfiguracja, kod i pentest nie oznaczają tego samego

Nazwy usług bywają używane zamiennie, ale ich rzeczywisty zakres może być bardzo różny. Dlatego przed rozpoczęciem zapisujemy w ofercie, które działania są częścią danego zlecenia.

Określenia „pentest” używamy tylko wtedy, gdy konkretne zlecenie rzeczywiście obejmuje uzgodnione testy penetracyjne. Sam audyt nie jest obietnicą pełnego pentestu.

Zakres ustalamy przed rozpoczęciem

Każda aplikacja ma inny sposób logowania, role, dane, integracje i ryzyka. Przed wyceną ustalamy co najmniej:

• wskazane domeny, aplikacje i środowiska;
• funkcje oraz procesy objęte kontrolą;
• role i konta testowe, z których można korzystać;
• wybrane endpointy API i powiązane integracje;
• dozwolone rodzaje testów oraz ich granice;
• elementy wyłączone z zakresu;
• warunki bezpiecznego działania na środowisku testowym lub produkcyjnym;
• sposób przekazania wyniku i osoby uprawnione do jego odbioru.

Jeżeli część aplikacji, infrastruktury albo kodu nie jest objęta zleceniem, zapisujemy to jako ograniczenie. Dzięki temu wynik nie sugeruje sprawdzenia obszarów, których rzeczywiście nie badaliśmy.

Jak może przebiegać współpraca

1. Krótko kwalifikujemy potrzebę

Bezpłatna rozmowa do 20 minut służy ustaleniu celu, ważnych obszarów i potrzebnych materiałów. Nie jest bezpłatną diagnozą, audytem ani raportem.

2. Ustalamy zakres i zasady bezpieczeństwa

Przed rozpoczęciem przekazujemy indywidualną ofertę. Zapisujemy w niej środowisko, dozwolone działania, wyłączenia, rezultat, termin i cenę.

3. Bezpiecznie przekazujesz potrzebne materiały

Po uzgodnieniu zlecenia ustalamy właściwy kanał przekazania kont testowych, kodu lub dokumentacji. Haseł, kluczy API, kopii bazy ani danych klientów nie należy wysyłać przez zwykły formularz kontaktowy.

4. Wykonujemy uzgodnione sprawdzenia

Łączymy tylko te metody, które odpowiadają zakresowi i warunkom konkretnej aplikacji. Potwierdzamy problemy tam, gdzie jest to możliwe i bezpieczne, zamiast przedstawiać samą listę automatycznych ostrzeżeń.

5. Przekazujemy wynik i omawiamy priorytety

Wynik pokazuje, co zostało sprawdzone, co potwierdziliśmy, jakie są ograniczenia i od czego warto rozpocząć poprawki. Format podsumowania ustalamy przed rozpoczęciem.

Co otrzymujesz po audycie

Dokładny rezultat zależy od oferty. Uzgodnione podsumowanie może obejmować:

• opis badanego zakresu, środowiska i ograniczeń;
• listę potwierdzonych problemów wraz z oceną ich ważności;
• dowody i sposób odtworzenia problemu, jeżeli można je bezpiecznie przekazać;
• opis możliwego wpływu technicznego i biznesowego;
• zalecenia dotyczące naprawy albo dalszego sprawdzenia;
• proponowaną kolejność działań;
• techniczne informacje potrzebne zespołowi wdrażającemu poprawki.

Materiał możesz wykorzystać podczas dalszych prac z Domin Software albo przekazać innemu wybranemu wykonawcy, z zachowaniem poufności i zasad ustalonych dla raportu.

OWASP jest punktem odniesienia, a nie automatyczną obietnicą pełnego pokrycia

Przy ustalaniu zakresu możemy korzystać z aktualnych materiałów OWASP dotyczących testowania aplikacji webowych, wymagań bezpieczeństwa i ryzyk API. Pomagają one uporządkować obszary kontroli, ale nie zastępują indywidualnego zakresu zlecenia.

Samo odwołanie do OWASP nie oznacza, że każde zlecenie obejmuje wszystkie testy opisane w Web Security Testing Guide, pełną weryfikację wszystkich wymagań ASVS albo każdy rodzaj ryzyka API. W ofercie wskazujemy, co rzeczywiście zostanie sprawdzone.

Czego podstawowy zakres nie obejmuje

O ile konkretna oferta nie stanowi inaczej, audyt nie obejmuje automatycznie:

• certyfikatu bezpieczeństwa;
• gwarancji wykrycia każdej podatności lub braku przyszłych problemów;
• testów całego kodu, całej infrastruktury, sieci i urządzeń;
• testów socjotechnicznych ani działań skierowanych do pracowników;
• testów przeciążeniowych i zakłócania działania produkcji;
• wdrożenia wszystkich poprawek;
• całodobowego monitoringu i stałej obsługi incydentów;
• ponownej kontroli po dowolnym czasie i po nieuzgodnionych zmianach.

Aktywne testy na produkcji wykonujemy tylko wtedy, gdy zostaną osobno uzgodnione, dopuszczone i zabezpieczone. Jeżeli bezpieczny test wymaga innego środowiska, wskazujemy to przed rozpoczęciem.

Poprawki i ponowna weryfikacja

Wdrożenie poprawek jest osobnym zakresem, chyba że konkretna oferta wyraźnie stanowi inaczej. Po audycie możemy przygotować wycenę prac albo przekazać materiały zespołowi wybranemu przez klienta.

Jeżeli poprawki wykonuje Domin Software, ich ponowna weryfikacja może być bezpłatna w okresie zapisanym w konkretnej ofercie. Po dłuższej przerwie, po zmianach wykonanych przez inną stronę albo poza pierwotnym zakresem potrzebna jest nowa wycena.

Jeżeli audyt prowadzi do większego projektu realizowanego przez Domin Software, zapłacony koszt audytu wliczamy w całkowity koszt tego projektu.

Czas, wycena i rozliczenie

Audyt wyceniamy indywidualnie. Cena zależy między innymi od liczby obszarów, ról, endpointów, środowisk, potrzebnego dostępu i dozwolonych rodzajów testów.

Roboczo zakładamy od 7 do 15 dni roboczych od otrzymania kompletnego zakresu, dostępnego środowiska i uzgodnionych kont testowych. Dokładny termin zapisujemy w ofercie.

Zwykle rozliczenie następuje po zakończeniu uzgodnionego etapu. Przy większym zakresie możemy ustalić zaliczkę.

Najczęstsze pytania

Czym audyt bezpieczeństwa różni się od testu penetracyjnego?

Audyt jest szerszym określeniem płatnego etapu sprawdzającego uzgodnione obszary. Może łączyć kontrolę konfiguracji, analizę wybranych funkcji, przegląd kodu i testy. Test penetracyjny oznacza kontrolowane próby wykorzystania podatności w jawnie ustalonych granicach. Nie każdy audyt automatycznie je obejmuje.

Czy testy można wykonywać na środowisku produkcyjnym?

Nie przyjmujemy tego automatycznie. Najpierw oceniamy ryzyko i ustalamy, czy wystarczy środowisko testowe. Każde działanie na produkcji wymaga osobnej zgody, ograniczenia zakresu i warunków chroniących dane oraz dostępność systemu.

Czy do audytu potrzebny jest dostęp do kodu?

Nie zawsze. Zależy to od celu i zakresu. Część problemów można sprawdzić od strony działającej aplikacji, a inne wymagają konfiguracji, dokumentacji albo wybranych fragmentów kodu. Potrzebny dostęp ustalamy przed wyceną.

Co znajduje się w podsumowaniu po audycie?

Opisujemy sprawdzony zakres i jego ograniczenia, potwierdzone problemy, ich ważność, dostępne dowody, sposób odtworzenia, ryzyko oraz zalecenia. Dokładny format i poziom szczegółowości ustalamy w ofercie.

Czy audyt obejmuje wdrożenie poprawek?

Nie w podstawowym zakresie. Wdrożenie możemy wycenić osobno. Materiał z audytu możesz także przekazać innemu wykonawcy.

Czy ponowna weryfikacja jest wliczona w cenę?

Jeżeli poprawki wykonuje Domin Software, bezpłatna weryfikacja może obowiązywać w okresie wskazanym w ofercie. Po dłuższej przerwie, po innych zmianach albo poza uzgodnionym zakresem przygotowujemy nową wycenę.

Czy audyt gwarantuje, że aplikacja nie ma podatności?

Nie. Audyt opisuje wynik dla określonego zakresu, czasu, środowiska i dostępnych informacji. Nie jest gwarancją wykrycia każdego problemu ani braku przyszłych podatności.

Jak przekazać dostęp i konta testowe?

W formularzu opisz tylko sytuację i potrzebny zakres. Po uzgodnieniu zlecenia wskażemy bezpieczny sposób przekazania materiałów. Nie wpisuj w formularzu haseł, kluczy API, danych klientów ani kopii bazy.

Co przesłać na początek

W formularzu możesz podać:

• rodzaj aplikacji i jej znaczenie dla firmy;
• cel audytu, na przykład planowane wdrożenie, zmianę wykonawcy albo większą rozbudowę;
• informację, czy dostępne jest środowisko testowe;
• liczbę najważniejszych ról użytkowników;
• informację, czy aplikacja ma API lub ważne integracje;
• oczekiwany termin i powód, dla którego kontrola jest potrzebna;
• znane ograniczenia dostępu, bez przesyłania sekretów.

Nie przesyłaj w formularzu haseł, kluczy API, tokenów, kopii bazy, kodu źródłowego ani danych klientów. Bezpieczny sposób przekazania potrzebnych materiałów ustalimy osobno.

CTA: Ustalmy zakres audytu

Jeżeli przejmujesz istniejący system od poprzedniego wykonawcy, możesz wcześniej skorzystać z checklisty przejęcia aplikacji.

Po audycie możemy osobno uzgodnić modernizację aplikacji albo stałą opiekę nad systemem. Dla aplikacji tworzonej z pomocą AI dostępny jest także audyt aplikacji AI, a problemy z czasem odpowiedzi i obciążeniem obejmuje audyt wydajności.

Źródła techniczne

• OWASP Web Security Testing Guide - punkt odniesienia dla obszarów testowania aplikacji webowych i usług webowych; przewodnik wymaga dopasowania do rzeczywistego zakresu.
• OWASP Application Security Verification Standard - katalog wymagań technicznych, który może pomagać w ustalaniu wymagań i zakresu weryfikacji.
• OWASP API Security Top 10 - punkt odniesienia dla ryzyk charakterystycznych dla interfejsów API.

Publiczny tekst nie deklaruje pełnej zgodności z całością tych materiałów. W dniu przygotowania szkicu aktualną stabilną wersją ASVS jest 5.0.0, a stabilnym wydaniem WSTG jest 4.2. Wersji nie wpisujemy do głównej treści strony, aby nie tworzyć szybko starzejącej się obietnicy. Jeśli później pojawią się w wymaganiach konkretnego zlecenia, trzeba podać dokładną wersję.