Scope creep – niekontrolowane rozszerzanie zakresu projektu – to jedna z głównych przyczyn niepowodzeń w testach penetracyjnych. Projekt zaplanowany na tydzień przeciąga się na miesiąc. Budżet puchnie. Terminy się przesuwają. A na końcu nikt nie jest zadowolony.
Ten artykuł wyjaśnia, skąd bierze się pełzanie zakresu w pentestach i jak mu przeciwdziałać.
Czym jest scope creep w kontekście pentestów
Scope creep to stopniowe, często niezauważalne rozszerzanie zakresu projektu bez odpowiedniej korekty budżetu, harmonogramu lub zasobów.
Typowe scenariusze:
- “Skoro już testujecie aplikację, sprawdźcie też API…”
- “Znaleźliście podatność na serwerze – przetestujcie całą podsieć”
- “A możecie przy okazji spojrzeć na tę drugą aplikację?”
- “Właśnie wdrożyliśmy nowy moduł – dodajcie go do testów”
Każda z tych próśb osobno wydaje się rozsądna. Razem mogą podwoić zakres projektu.
📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne - rodzaje, metodologie, przebieg
Przyczyny scope creep w pentestach
1. Niejasno zdefiniowany zakres początkowy
Problem: “Pentest aplikacji webowej” bez precyzyjnej definicji co to oznacza.
Skutek: Klient oczekuje testów wszystkich funkcji, wszystkich ról użytkowników, wszystkich integracji. Pentester planował testy OWASP Top 10 na głównych funkcjach.
2. Odkrycia podczas testów
Problem: Pentester znajduje nieudokumentowane API, nieznane subdomeny, powiązane systemy.
Skutek: Naturalna pokusa: “Skoro już tu jestem, sprawdzę co tam jest.” Bez formalnej zmiany zakresu.
3. Zmieniające się środowisko
Problem: W trakcie testów klient wdraża nowe funkcje, zmienia konfigurację, dodaje systemy.
Skutek: Testy tracą aktualność lub wymagają powtórzenia na nowych elementach.
4. Nieporozumienia w komunikacji
Problem: Różne rozumienie terminów. “Aplikacja” dla klienta to cały ekosystem, dla pentestera – jeden frontend.
Skutek: Rozbieżne oczekiwania ujawniają się w połowie projektu.
5. Presja na “wartość dodaną”
Problem: Chęć pokazania więcej niż konkurencja. “My testujemy szerzej za tę samą cenę.”
Skutek: Brak granic prowadzi do powierzchownych testów wszystkiego zamiast głębokich testów czegoś.
Konsekwencje niekontrolowanego scope creep
Dla klienta
- Wyższe koszty – dodatkowe prace wymagają dodatkowych zasobów
- Opóźnienia – raporty przychodzą później niż planowano
- Niższa jakość – rozproszenie uwagi pentesterów
- Problemy compliance – terminy audytów zagrożone
- Konflikty – spory o zakres i płatności
Dla pentestera
- Nieopłacalność – więcej pracy za tę samą stawkę
- Wypalenie zespołu – ciągłe nadgodziny
- Ryzyko prawne – testowanie poza autoryzacją
- Utrata reputacji – niezadowolony klient mimo dodatkowej pracy
- Problemy z planowaniem – inne projekty cierpią
Jak precyzyjnie definiować zakres
Dokument Scope of Work (SOW)
Profesjonalny SOW powinien zawierać:
1. Cele testów
- Co chcemy osiągnąć?
- Jakie pytania mają odpowiedzieć testy?
- Czy to compliance, risk assessment, czy walidacja kontroli?
2. Systemy w zakresie (In-Scope)
- Lista konkretnych IP, domen, aplikacji
- Wersje i środowiska (prod, staging, dev)
- Funkcje do przetestowania
- Role użytkowników do wykorzystania
3. Wyłączenia (Out-of-Scope)
- Systemy, których nie testujemy
- Techniki, których nie stosujemy
- Godziny, w których nie testujemy
- Dane, których nie dotykamy
4. Typ testów
- Black box / grey box / white box
- Testy z credentials czy bez
- Zakres social engineering
- Testy DoS – tak czy nie
5. Deliverables
- Format raportu
- Poziom szczegółowości
- Terminy (draft, final, retest)
- Prezentacje
6. Harmonogram
- Daty rozpoczęcia i zakończenia testów
- Okna testowe (jeśli ograniczone)
- Daty deliverables
Checklist precyzyjnego zakresu
Dla aplikacji webowej:
- Lista URL-i w scope
- Lista funkcji do testowania
- Role użytkowników i poziomy dostępu
- Integracje zewnętrzne (API, SSO, płatności)
- Środowisko (produkcja, staging, dev)
- Dane testowe vs produkcyjne
- Wyłączone funkcje (np. formularz kontaktowy)
Dla infrastruktury:
- Zakres IP (CIDR notation)
- Lista hostów z wyłączeniami
- Typy testów (recon, vuln scan, exploitation)
- Credentialed vs uncredentialed
- Testy wewnętrzne vs zewnętrzne
- Testy wireless – tak/nie
Zarządzanie zmianami zakresu
Formalna procedura Change Request
Każda zmiana zakresu powinna przejść przez:
- Wniosek – pisemna prośba o zmianę
- Ocena – wpływ na czas, koszty, zasoby
- Wycena – dodatkowy koszt i czas
- Akceptacja – pisemna zgoda obu stron
- Dokumentacja – aneks do umowy
- Realizacja – dopiero po formalnej akceptacji
Zasada: “Nic bez pisemnej zgody”
Nawet jeśli zmiana wydaje się drobna, dokumentuj:
- Kto poprosił o zmianę
- Co dokładnie obejmuje
- Jaki jest wpływ na projekt
- Czy jest akceptacja płatności (jeśli dotyczy)
Szablonowy email na żądanie zmiany
Temat: [Projekt X] Żądanie zmiany zakresu - Potwierdzenie
Dzień dobry,
W nawiązaniu do naszej rozmowy, potwierdzam następującą zmianę zakresu:
OPIS ZMIANY:
[Co dokładnie ma być dodane/zmienione]
WPŁYW NA PROJEKT:
- Dodatkowy czas: [X dni]
- Dodatkowy koszt: [X PLN]
- Przesunięcie terminu deliverables: [tak/nie, na kiedy]
Proszę o pisemne potwierdzenie akceptacji powyższego przed rozpoczęciem prac nad rozszerzonym zakresem.
Pozdrawiam,
[Pentester]Czerwone flagi podczas projektu
Sygnały nadchodzącego scope creep
- Klient regularnie pyta “a czy możecie też…”
- Pojawiają się nowe osoby z nowymi wymaganiami
- Odkrywasz nieudokumentowane systemy w środowisku
- Klient zmienia priorytetyzację w trakcie testów
- Pojawiają się prośby o “szybkie spojrzenie” na coś extra
Jak reagować
Natychmiast:
- Zatrzymaj się i wyjaśnij sytuację
- Dokumentuj prośbę
- Oceń wpływ na projekt
Komunikacja:
- “Chętnie przetestujemy ten system. Wymaga to jednak rozszerzenia zakresu. Przygotujemy wycenę.”
- “To wykracza poza ustalony zakres. Możemy to uwzględnić w osobnym zleceniu.”
- “Rozumiem potrzebę. Proponuję zakończyć obecny zakres, a następnie omówić dodatkowe testy.”
Najlepsze praktyki
Dla pentesterów
- Zawsze rozpoczynaj od kick-off – spotkanie wyjaśniające zakres
- Dokumentuj wszystko – maile, notatki ze spotkań, decyzje
- Raportuj odkrycia out-of-scope – ale nie testuj bez autoryzacji
- Regularnie komunikuj postępy – klient wie, gdzie jesteś
- Bądź asertywny – odmowa rozszerzenia bez formalnej procedury
Dla klientów
- Zdefiniuj zakres przed RFP – im precyzyjniej, tym lepiej
- Zamroź środowisko na czas testów – minimalizuj zmiany
- Wyznacz jednego decision makera – unikaj sprzecznych instrukcji
- Budżetuj contingency – 10-20% na nieprzewidziane odkrycia
- Akceptuj, że nie wszystko da się przetestować – priorytetyzuj
Podsumowanie
Scope creep w pentestach to problem obu stron – klienta i dostawcy. Klucz do sukcesu:
- Precyzyjny zakres na starcie – inwestycja w dokumentację się zwraca
- Formalna procedura zmian – nic bez pisemnej akceptacji
- Bieżąca komunikacja – problemy rozwiązuj wcześnie
- Asertywność – ochrona zakresu to profesjonalizm, nie utrudnianie
- Elastyczność w ramach procesu – zmiany są OK, jeśli są zarządzane
Dobrze zarządzany zakres oznacza lepsze testy, zadowolonych klientów i zdrowe relacje biznesowe.
Planujesz testy penetracyjne i chcesz uniknąć problemów z zakresem? Skontaktuj się z nami – pomożemy precyzyjnie zdefiniować projekt.
Zakres jest zabezpieczeniem obu stron, nie formalnością
Pełzanie zakresu zwykle nie zaczyna się od złej woli, tylko od zdania „przy okazji sprawdźcie jeszcze”. Problem w tym, że każde takie rozszerzenie zabiera czas z zakresu opłaconego — więc płaci za nie ten sam klient, tylko płytszym testem tam, gdzie miało być głęboko. Zapisany zakres, liczba dni i tryb zgłaszania zmian chronią przed tym obie strony.
Dlatego zakres, metodykę i zasady zmiany ustalamy przed uruchomieniem pierwszego narzędzia: tak prowadzone są testy penetracyjne.
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- Cyberbezpieczeństwo — Cyberbezpieczeństwo to zbiór technik, procesów i praktyk ochrony systemów IT,…
- Monitorowanie sieci — Monitorowanie sieci to ciągły nadzór ruchu i infrastruktury sieciowej w celu…
- NIS2 — NIS2 (Network and Information Security Directive 2) to dyrektywa UE…
- Testy penetracyjne — Testy penetracyjne (pentesty) to kontrolowany proces symulacji ataku na system…
- API — API (Application Programming Interface) to zestaw reguł i protokołów…
Dowiedz się więcej
Zapoznaj się z powiązanymi artykułami w naszej bazie wiedzy:
- Analiza PEST: Klucz do skutecznego planowania strategii w świecie nowoczesnych technologii
- Audyt bezpieczeństwa a test penetracyjny: Czym się różnią i kiedy je stosować?
- Audyty PCI DSS - Kompleksowa Ochrona Danych Płatniczych
- Bezpieczeństwo API: Jak chronić krwiobieg nowoczesnych aplikacji?
- Jak chronić dane w trakcie przeprowadzania testów penetracyjnych?
Sprawdź nasze usługi
Potrzebujesz wsparcia w zakresie cyberbezpieczeństwa? Sprawdź:
- Testy penetracyjne - identyfikacja podatności w infrastrukturze
- Red Team - zaawansowane symulacje ataków
Tematy powiązane
Zobacz również:
Powiązane usługi i produkty
- Wdrożenia profesjonalnych sieci Wi-Fi
- Zarządzanie Chmurą zgodnie z wytycznymi KNF
- Aruba Mobility Controllers
