Program testów bezpieczeństwa – 25 lat doświadczenia w pigułce

Kiedy pojedynczy test to za mało?

Program testowania bezpieczeństwa to strategiczny wybór dla organizacji, które: 

• Skalują operacje – budują, utrzymują lub wykonują od kilkunastu do kilkuset aplikacji/testów rocznie. 
• Działają w reżimie compliance – muszą spełniać rygorystyczne wymogi regulacyjne (KNF, NIS2, DORA, TLPT, ISO 27001). 
• Dbają o łańcuch dostaw – są zobligowane do weryfikacji bezpieczeństwa systemów im dostarczanych przez kontrahentów i partnerów biznesowych.
• Wspierają własne zespoły  – posiadają wewnętrzne działy bezpieczeństwa, które potrzebują wsparcia zewnętrznych ekspertów i dostępu do profesjonalnych narzędzi bez budowania pełnej infrastruktury in-house. 

Dla sektora SaaS (Software as a Service) – jeśli budujesz jedną platformę, rekomendujemy model corocznych testów pełnych (co sprzyja spełnianiu wymagań wdrożonego systemu zarządzania bezpieczeństwem – ISO27001) uzupełniony o regularne testy zmian po każdym istotnym wdrożeniu nowej funkcjonalności. 

Skontaktuj się z autorem na LinkedIn!

Jak zamawiać testy bez nadmiernej biurokracji?

Jednym z kluczowych “wąskich gardeł”, z którymi mierzyliśmy się w ciągu ostatnich 25 lat testów, jest biurokracja. Model zakupowy stosowany przez naszych klientów nie zawsze odpowiada dynamice projektów, które wdrażają i które chcą weryfikować pod kątem bezpieczeństwa.  

Zapewnienie zasobów – jak to ugryźć?

W procesie oceny bezpieczeństwa dane stanowią fundament, bez którego nawet najbardziej doświadczony zespół testerów nie jest w stanie dostarczyć rzetelnych wyników. Testy penetracyjne to nie “klikanie w aplikację”. To proces, który wymaga odpowiedniego paliwa w postaci informacji technicznych i danych dostępowych. Przy zarządzaniu portfelem wielu aplikacji, sprawny proces pozyskiwania tych danych staje się krytycznym czynnikiem sukcesu całego programu.

Podstawa: Komplet informacji wejściowych 

Aby testy mogły rozpocząć się bez opóźnień, zespół testowy musi dysponować kompletem zasobów, do których należą: 

• Dane dostępowe – loginy, hasła, dodatkowe metody uwierzytelniania dla różnych ról użytkowników (np. administrator, użytkownik standardowy, menadżer), aby sprawdzić mechanizmy uwierzytelniania i separacji uprawnień.
• Przepusty sieciowe – odblokowanie komunikacji na firewallach lub dostęp do testowanego systemu za pomocą połączeń VPN.
• Ustrukturyzowane dane testowe – bazy danych “załadowane” rekordami, które pozwalają na realne przejście procesów biznesowych (np. aktywne numery kart płatniczych w środowisku testowym, historia wykonanych w aplikacji przez klientów itp.).

Metoda „Na ankietę”: Ankieta jako standard 

Najbardziej efektywnym rozwiązaniem, które wypracowaliśmy przez lata jest ustrukturyzowana ankieta onboardingowa. Pozwala ona na:

• Standaryzację – każda aplikacja opisywana jest według tego samego klucza.
• Oszczędność czasu – twoi pracownicy wypełniają dane w dogodnym momencie, unikając długich spotkań.
• Weryfikację kompletności – nasz Kierownik Projektu (PM) przed rozpoczęciem testów weryfikuje kompletność i poprawność dostarczonych informacji.

W sytuacjach projektów o wysokim stopniu skomplikowania, gdzie ankieta to za mało, nasz PM inicjuje spotkanie techniczne (tzw. Kick-off) minimum na tydzień przed startem. Celem jest “zderzenie” planu z rzeczywistością i wyeliminowanie ryzyk technicznych, zanim zaczną one generować koszty. 

Zarządzanie nieoczekiwanym – procedura awaryjna i “Backlog Management” 

W działających aktywnie środowiskach IT naszych klientów świat rzadko bywa idealny. Zdarza się, że środowiska testowe potrafią przestać działać na dzień przed testem, a krytyczne błędy we wdrożeniu mogą uniemożliwić stabilną pracę aplikacji. W tradycyjnym modelu oznacza to marnowanie opłaconych roboczodni zespołu ekspertów, którzy pozostają w gotowości, ale nie mają czego testować.

Aby wyeliminować to ryzyko, stosujemy procedurę awaryjnej zmiany: 

• Zasada “bloków startowych” – rekomendujemy naszym klientom, dla których realizujemy program testów, utrzymywanie “Backlogu testów” – listy aplikacji o niższym priorytecie, które wymagają testowania.
• Zmiana testowanej aplikacji – jeśli aplikacja “A” nie jest gotowa, zespół testowy natychmiastowo przełącza się na aplikację “B” z “backlogu”. Dzięki temu wykupiony czas naszych specjalistów może zostać wykorzystany w 100%, a harmonogram całego programu pozostaje nienaruszony.
• Optymalizacja kosztów – takie podejście zmienia postrzeganie testów z “projektów o podwyższonym ryzyku opóźnień” w płynną linię produkcyjną bezpieczeństwa.

Dzięki tak zaprojektowanemu procesowi, faza przygotowawcza przestaje być wąskim gardłem, a staje się sprawnym mechanizmem, który pozwala testerom skupić się na tym, co potrafią najlepiej – szukaniu luk w zabezpieczeniach, a nie czekaniu na dostęp do aplikacji czy systemu poddawanemu ocenie.

Realizacja – standardy i “Low-Touch”

Fundamentem każdego profesjonalnego badania jest metodyka. W naszym programie opieramy się na uznanych światowych standardach, takich jak OWASP Top 10, OWASP ASVS (Application Security Verification Standard) czy OSSTMM (Open Source Security Testing Methodology Manual) przy jednoczesnym dopasowaniu tych standardów, jak również naszych autorskich checklist dla procesów do konkretnego klienta.

Jednak sama teoria to nie wszystko. Kluczem do sukcesu w dużych organizacjach jest realizacja typu „Low-Touch” – model współpracy, który dostarcza maksymalną wartość przy minimalnym angażowaniu Twoich pracowników w trakcie trwania testów. 

Metodyka, która nie wyklucza zwinności 

Oparcie się na metodyce OWASP ASVS oraz naszych wewnętrznych wytycznych pozwala nam na precyzyjne określenie szczegółów testów, co daje Ci pewność, że każda funkcja aplikacji została sprawdzona pod kątem konkretnych wymagań bezpieczeństwa. Dzięki temu proces jest powtarzalny, a wyniki porównywalne pomiędzy różnymi Twoimi systemami.

Krytyczne podatności: „Szybka ścieżka” 

W tradycyjnym modelu testów klient często dowiaduje się o zidentyfikowanych błędach dopiero po zakończeniu prac. W naszej propozycji, czas działa na Twoją korzyść: 

• Brak opóźnień – jeśli nasz zespół zidentyfikuje lukę o krytycznym wpływie na ryzyko według skali CVSS (Common Vulnerability Scoring System) – np. umożliwiającą kradzież danych lub zdalne wykonanie kodu – nie czekamy na finalny raport. Informację o krytycznej podatności przekazujemy Ci niezwłocznie.
• Natychmiastowe powiadomienie – informacja o krytycznym zagrożeniu trafia do Twojego zespołu bezpieczeństwa wybranym kanałem komunikacji (np. dedykowany kanał Slack/Teams, ticket w systemie Jira lub bezpośredni telefon).
• Wsparcie w mitygacji – razem z informacją o błędzie dostarczamy wstępne rekomendacje naprawcze, aby Twój zespół mógł rozpocząć usuwanie podatności, podczas gdy my kontynuujemy testy w innych obszarach.

Skontaktuj się z autorem na LinkedIn!

Wyniki – od raportu w PDF do automatyzacji

W tradycyjnym podejściu raport z testów penetracyjnych to gruby dokument PDF, który bardzo często po analizie ląduje w szufladzie i wyciągany jest tylko w przypadku kontroli działu zgodności. W profesjonalnym programie testów chcemy odejść od tej koncepcji. Wynik naszej pracy to nie tylko lista błędów, ale przede wszystkim wsparcie dla Twojego procesu naprawczego, poprzez regularne spotkania z twórcami oprogramowania lub dostarczenie usługi vCISO podnoszącej ogólny poziom Twojego bezpieczeństwa. Stawiamy na wielopoziomowe raportowanie dostosowane do różnych grup odbiorców w Twojej organizacji.

Tradycyjny raport PDF: Standard dla Zarządu i Compliance 

Mimo postępującej cyfryzacji, formalny dokument PDF pozostaje niezbędny. Jest on dowodem należytej staranności i kluczowym elementem w procesach audytowych. 

Integracja z systemami Vulnerability Management: Bezpośrednie wsparcie działów bezpieczeństwa i deweloperów 

Aby bezpieczeństwo było realne, musi być “blisko kodu”. Dlatego zamiast przekonywać Twoich programistów do czytania raportu, możemy bezpośrednio wprowadzić wyniki naszych prac, do narzędzi, których używają na co dzień: 

• Ekosystem Jira – każda znaleziona podatność może trafić do Twojej Jiry jako osobne zadanie z przypisanym priorytetem, opisem technicznym i co najważniejsze, zalecanym przez nas i jasno opisywanym sposobem usunięciu błędu z Twojej aplikacji.
• Platformy Vulnerability Management (VM) – wspieramy integrację z narzędziami takimi jak ServiceNow, DefectDojo, Archer czy Kenna Security. Pozwala to na centralne zarządzanie podatnościami z wielu źródeł w jednym miejscu.
• Automatyzacja statusów – gdy Twój zespół oznaczy błąd jako naprawiony, informacja ta trafia do nas automatycznie, co pozwala na błyskawiczne zaplanowanie czasu na weryfikacje usunięcia podatności.

Proof of Coverage – co właściwie sprawdziliśmy? 

Częstym problemem raportów jest to, że skupiają się tylko na tym, co “nie działa”. My idziemy o krok dalej, dostarczając informacje o pełnym zakresie prac.

• Jasne granice – precyzyjnie dokumentujemy, które moduły aplikacji, metody API oraz konkretne role użytkowników zostały podane testom.
• Uzasadnienie ryzyka – jeśli pewne elementy pozostały poza zakresem (np. na prośbę klienta, czy ze względu na stabilność środowiska), wyraźnie to zaznaczamy jako wyłączenia (obszar ryzyka resztkowego)
• Transparentność – dzięki temu w raporcie widzisz nie tylko podatności i błędy bezpieczeństwa w systemach, ale również całość pracy wykonanej podczas naszych testów.

Zamknięcie projektu i kolejne kroki

Ostatni etap programu testów to moment, w którym organizacja przechodzi od reaktywnego “łatania dziur” do proaktywnej nauki na błędach. W profesjonalnym podejściu spotkanie podsumowujące (tzw. Lessons Learned) nie służy jedynie odczytaniu listy znalezionych błędów – to strategiczny warsztat, którego celem jest wyeliminowanie przyczyn źródłowych problemów.

Analiza Root Cause – dlaczego ten błąd powraca? 

Zamiast skupiać się na pojedynczym incydencie, analizujemy trendy w całym portfelu aplikacji. Zadajemy trudne pytania, które pozwalają organizacji rosnąć: 

• Analiza systemowa – czy dany typ podatności (np. Cross-Site Scripting) pojawia się cyklicznie, bo używamy przestarzałych bibliotek, czy może brakuje standardu bezpiecznego programowania wewnątrz firmy?
• Luki kompetencyjne – czy deweloperzy wiedzą, jak unikać tych konkretnych zagrożeń? Jeśli te same błędy powracają, jest to jasny sygnał, że standardowe procedury wymagają wsparcia w postaci dedykowanych szkoleń z bezpiecznego wytwarzania oprogramowania (tzw. Security Awareness for Developers). 

Informacja zwrotna 

Program testów to żywy organizm. Informacja zwrotna od Ciebie jako klienta jest dla nas kluczowa, abyśmy mogli dopasować nasze działania do Twojej zmieniającej się infrastruktury:

• Optymalizacja procesu – jeśli faza uzyskiwania dostępów trwała zbyt długo, wspólnie staramy się znaleźć sposób i tak zmodyfikować procedurę, z której podczas tej fazy korzystamy, aby przy kolejnych testach zadziałała ona skuteczniej.
• Dostrajanie narzędzi – feedback pozwala nam precyzyjniej konfigurować narzędzia techniczne, takie jak skanery, skrypty manualne czy listy kontrolne, ale także aktualizować procesy, z których wspólnie korzystamy – tak aby skupiać się na tym, co faktycznie zagraża Twojemu biznesowi. 
• Aktualizacja Threat Model – na podstawie wyników aktualizujemy model zagrożeń dla Twojej branży – to, co było bezpieczne rok temu, dziś może wymagać nowej metodologii testowej. 

Współczesny program testów to przejście z modelu rzemieślniczego (pojedyncze zlecenia) na model linii produkcyjnej bezpieczeństwa, która jest: 

• Przewidywalna – dzięki jasnym modelom zakupowym (subskrypcja, katalog usług). 
• Odporna na przestoje – dzięki zarządzaniu backlogiem i procedurom awaryjnym. 
• Zintegrowana – dane o błędach bezpieczeństwa są w pełni zintegrowane z Twoim ekosystemem wytwarzania oprogramowania i trafiają bezpośrednio do narzędzi takich jak Jira czy ServiceNow. 

Kluczowe take-aways dla zamawiających testy 

Nie pozwól, aby biurokracja blokowała publikacje kolejnych wersji Twoich aplikacji. 

• Jeśli prowadzisz dynamiczne projekty, unikaj pojedynczych zleceń. Wybierz umowę ramową lub subskrypcję, by móc startować z testami w kilka dni, a nie tygodni.
• Dla powtarzalnych systemów (np. aplikacje mobilne o podobnej skali) stosuj katalog usług – znacząco uprości to budżetowanie. 

Najdroższy tester to taki, który czeka na hasło do systemu. 

• Wprowadź standard ankiety onboardingowej. Każdy “Product Owner” powinien umieć wypełnić ją przed zgłoszeniem chęci testów. 
• Zapewnij środowiska testowe z danymi odzwierciedlającymi realne procesy. Testy na “pustej” aplikacji rzadko wykazują błędy w logice biznesowej. Ponadto, zużywasz czas zespołu testowego na pozyskiwania tych danych, podczas gdy w tym czasie mogliby weryfikować bezpieczeństwo Twojej aplikacji.  

Uniknij przestojów. 

• Zawsze miej przygotowane jedną lub dwie mniejsze aplikacje “w kolejce”. W przypadku awarii środowiska głównego projektu, testerzy natychmiast zajmą się tymi aplikacjami, optymalizując Twój budżet. 

Raport na koniec projektu to za późno na poinformowanie o krytycznych błędach typu.

• Ustal z dostawcą kanał natychmiastowego powiadomienia (Slack, Teams, bezpośredni telefon). Deweloperzy powinni wiedzieć o krytycznej luce niezwłocznie po jej znalezieniu, nie czekając na końcowy raport.

Raport PDF jest dla Zarządu lub Działu Compliance, a błąd w systemie dla działu bezpieczeństwa i dewelopera. 

• Wymagaj od Nas eksportu do Jiry lub innego systemu VM (np. DefectDojo). 
• Zadbaj o Proof of Coverage. Musisz wiedzieć nie tylko co jest dziurawe, ale też co zostało uznane za bezpieczne (to kluczowe dla Twojej oceny ryzyka resztkowego). 

Jeśli ten sam błąd pojawia się kolejny raz w różnych projektach, źródłem problemu nie jest sam kod, lecz brak wiedzy u osób go tworzących. 

• Wykorzystaj spotkania Lessons Learned do identyfikacji luk kompetencyjnych w Twoim zespole. 
• Zamiast przeprowadzać kolejne testy podatności z tej samy klasy błędów, rozważ szkolenie Security Awareness dla deweloperów oparte na realnych wynikach z Twoich raportów. 

Adam Zachara Managing Partner