Testowanie bezpieczeństwa: rola testowania manualnego i automatycznego

Testowanie bezpieczeństwa to sprawdzanie, czy aplikacja, API i proces jej wytwarzania są odporne na nadużycia: przejęcie konta, dostęp do cudzych danych, wyciek sekretów czy podatną bibliotekę. Automatyczne testy bezpieczeństwa wyłapują znane wzorce przy każdej zmianie w kodzie, a testy manualne łapią to, czego żaden skaner nie rozumie, czyli logikę biznesową i uprawnienia. Dopiero razem dają realną kontrolę ryzyka, i właśnie o tym podziale pracy jest ten tekst.

Zamiast listy ogólników pokazujemy konkret: co tester sprawdza ręcznie, a co oddaje automatom, jak wygląda pipeline z gitleaks, Dependabotem i skanem ZAP, oraz test regresji uprawnień do API, który uruchomiliśmy 10.10.2026 na dwóch wersjach tego samego API, bezpiecznej i podatnej. Opieramy się na aktualnych wydaniach: OWASP Top 10:2025 i OWASP API Security Top 10 2023.

Czym jest testowanie bezpieczeństwa i co w nim robi tester?

Testowanie bezpieczeństwa obejmuje wszystko, co sprawdza odporność systemu na nadużycie: przegląd wymagań pod kątem ryzyka, testy uwierzytelniania i uprawnień, walidacji danych, sesji, konfiguracji, zależności i sekretów, aż po kontrolowaną symulację ataku. Ta ostatnia to test penetracyjny, czyli najbardziej zaawansowana i najwęższa część tej układanki. Rodzaje testów penetracyjnych, etapy i to, jak je zlecić, opisujemy osobno w przewodniku testy bezpieczeństwa i testy penetracyjne.

Tester nie musi być pentesterem, żeby znaleźć poważną lukę. Musi wiedzieć, czego szukać: czy użytkownik bez uprawnień dostaje odmowę, czy po wylogowaniu stary token nadal działa, czy zmiana identyfikatora w adresie nie otwiera cudzych danych. Z naszego doświadczenia to właśnie testerzy manualni, którzy znają proces biznesowy, najczęściej zauważają błędy w modelu uprawnień, bo wiedzą, kto w firmie powinien widzieć jaką fakturę. Ścieżkę rozwoju w tym kierunku pokazujemy w tekście jak tester może wejść do cybersecurity.

Dlaczego test funkcjonalny przepuszcza dziury bezpieczeństwa?

Bo sprawdza, czy uprawniony użytkownik może coś zrobić, a nie czy nieuprawniony nie może. Przykład: klientka loguje się do panelu, otwiera fakturę pod adresem /api/invoices/1001 i dostaje odpowiedź 200 OK. Test funkcjonalny jest zielony. Problem zaczyna się, gdy inny klient wpisze ten sam adres i też dostanie 200 OK z cudzą fakturą. Funkcja działa, a kontrola dostępu nie istnieje.

To nie jest egzotyka. OWASP Top 10:2025, zbudowany na danych z ponad 2,8 mln aplikacji, utrzymał błędy kontroli dostępu (Broken Access Control) na pierwszym miejscu: według OWASP średnio 3,73% testowanych aplikacji miało co najmniej jedną z 40 słabości CWE z tej kategorii, a dane obejmują 1 839 701 wystąpień i 32 654 podatności CVE. Ta sama edycja przesunęła błędną konfigurację z piątego na drugie miejsce, z 3,00% aplikacji z co najmniej jedną słabością z 16 CWE.

Najczęstsze dziury, które QA widzi, a których nikt nie chce słuchać, ciekawie zebrała Strefa QA w tekście o lukach bezpieczeństwa, które QA widzi pierwsze. Wniosek jest wspólny: luka w uprawnieniach rzadko jest problemem technicznym, częściej brakiem wymagania, które mówi, kto czego nie może.

Co sprawdzać ręcznie, a co automatycznie?

Ręcznie to, co wymaga zrozumienia kontekstu. Automatycznie to, co ma znany wzorzec i musi być sprawdzane przy każdej zmianie. Poniższa tabela to podział, od którego zaczynamy rozmowę z zespołami przy wdrażaniu testów bezpieczeństwa w procesie QA.

Ogólne porównanie obu podejść, poza bezpieczeństwem, znajdziecie w artykule testowanie manualne a testowanie automatyczne. W bezpieczeństwie różnica jest ostrzejsza: automat bez człowieka przepuszcza błędy logiki, a człowiek bez automatu nie upilnuje regresji przy codziennych wdrożeniach.

Automatyczne testy bezpieczeństwa: gdzie dają największą wartość?

Tam, gdzie ten sam błąd może wrócić przy każdej zmianie i ma rozpoznawalny wzorzec. Automatyczne testy bezpieczeństwa dzielą się na cztery rodziny: analizę zależności (SCA), wykrywanie sekretów, analizę statyczną kodu (SAST) i dynamiczne skanowanie działającej aplikacji (DAST). Do tego dochodzą Wasze własne testy regresji, pisane po każdej znalezionej luce. Poniżej trzy darmowe narzędzia, od których zaczynamy w projektach, z uczciwym opisem tego, czego nie robią.

Ostatnia kolumna jest ważniejsza niż środkowa. Dokumentacja ZAP mówi wprost, że skan baseline przez domyślnie minutę przeszukuje aplikację pająkiem, a potem tylko pasywnie analizuje odpowiedzi i nie wykonuje żadnych faktycznych ataków; dlatego nadaje się do CI/CD, nawet na produkcji. Zielony wynik baseline nie oznacza więc, że aplikacja jest bezpieczna, tylko że nie ma oczywistych zaniedbań konfiguracji. Pełne, aktywne skanowanie DAST w potoku ćwiczycie na szkoleniu automatyczne testy bezpieczeństwa z OWASP ZAP.

Jak wygląda pipeline bezpieczeństwa w CI/CD?

Jak zestaw szybkich bramek na każdym pull requeście. Poniżej minimalny przykład dla GitHub Actions: sekrety sprawdza gitleaks, uprawnienia API Wasze testy regresji, a konfigurację środowiska testowego pasywny skan ZAP. Całość trwa kilka minut, więc nie spowalnia zespołu, a każda bramka blokuje scalenie zmiany, gdy coś znajdzie.

# .github/workflows/bezpieczenstwo.yml
name: Testy bezpieczenstwa
on: [pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0   # pełna historia, żeby gitleaks przejrzał wszystkie commity

      - name: Sekrety w repozytorium (gitleaks)
        run: docker run --rm -v "${{ github.workspace }}:/repo" ghcr.io/gitleaks/gitleaks:latest git /repo --no-banner

      - name: Regresja uprawnien API (pytest)
        run: pip install pytest requests && pytest -q tests/security
        env:
          API_URL: ${{ vars.STAGING_API_URL }}
          TOKEN_ANNA: ${{ secrets.TOKEN_ANNA }}
          TOKEN_JAN: ${{ secrets.TOKEN_JAN }}

      - name: Skan pasywny ZAP baseline
        uses: zaproxy/action-baseline@v0.15.0
        with:
          target: ${{ vars.STAGING_URL }}

Tak wygląda zatrzymanie przez gitleaks. Sprawdziliśmy to 10.10.2026 na repozytorium testowym z przykładowym kluczem dostępowym w pliku konfiguracyjnym: narzędzie znalazło dwa sekrety i zakończyło się kodem 1, który w CI oznacza czerwony build.

$ gitleaks git repo --no-banner
Finding:     aws_secret_access_key = "rT7g...(ukryte)"
RuleID:      generic-api-key
File:        config.ini
Line:        2
...
WRN leaks found: 2
$ echo $?
1

Zależności pilnuje Dependabot. Aktualizacje bezpieczeństwa (security updates) włączacie w ustawieniach repozytorium: według dokumentacji GitHub Dependabot otwiera wtedy automatyczny pull request z poprawką dla zależności ze znaną podatnością. Plik konfiguracyjny dodaje regularne aktualizacje wersji, żeby zespół nie skakał co pół roku o pięć wersji naraz.

# .github/dependabot.yml: cotygodniowe aktualizacje zależności npm
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Jeśli wolicie, żeby taki potok zbudował i utrzymał ktoś z zewnątrz, robimy to w ramach usługi budowa procesów CI/CD, razem z testami API i raportowaniem wyników. Automatyczne testy bezpieczeństwa w CI/CD razem z ręcznymi testami uprawnień i raportem z priorytetami poprawek możecie też zlecić nam w całości.

Jak testować API według OWASP API Security Top 10 2023?

Traktując listę OWASP jako mapę przypadków testowych, a nie jako lekturę. Aktualna edycja OWASP API Security Top 10 pochodzi z 2023 roku i zastąpiła wersję z 2019; w nowej liście pojawiły się między innymi SSRF, nieograniczony dostęp do wrażliwych procesów biznesowych i niebezpieczne korzystanie z cudzych API. Przy każdej pozycji macie pytanie, które tester może zadać od jutra.

Narzędziowo do odkrywania tych luk wystarczy na start Postman i dwa konta testowe o różnych rolach. Jeśli dopiero zaczynacie z testami API, przejdźcie najpierw nasz kurs testów API w Postmanie w 6 lekcjach, a zakres usług w tym obszarze pokazuje strona testy bezpieczeństwa API i aplikacji.

Jak napisać test regresji uprawnień do API?

Tak, żeby sprawdzał to, czego test funkcjonalny nie sprawdza: że obcy użytkownik nie dostaje cudzych danych. Poniższy test w Pythonie z pytest i requests pokrywa ryzyko API1:2023 dla prostego zasobu faktur: właścicielka widzi swoją fakturę, inny klient dostaje 403 albo 404 bez treści faktury, a żądanie bez tokenu kończy się 401. Tokeny przychodzą ze zmiennych środowiska, nigdy z repozytorium.

# Python 3.12+, pytest 9, requests 2: regresja kontroli dostępu (OWASP API1:2023, BOLA)
import os

import pytest
import requests

BASE_URL = os.environ.get("API_URL", "http://localhost:8000")
TOKEN_ANNA = os.environ["TOKEN_ANNA"]  # klientka, właścicielka faktur 1001 i 1002
TOKEN_JAN = os.environ["TOKEN_JAN"]    # inny klient tego samego systemu


def get_invoice(invoice_id, token=None):
    headers = {"Authorization": f"Bearer {token}"} if token else {}
    return requests.get(f"{BASE_URL}/api/invoices/{invoice_id}", headers=headers, timeout=10)


def test_wlascicielka_widzi_swoja_fakture():
    r = get_invoice(1001, TOKEN_ANNA)
    assert r.status_code == 200
    assert r.json()["owner"] == "anna"


@pytest.mark.parametrize("invoice_id", [1001, 1002])
def test_inny_klient_nie_widzi_cudzej_faktury(invoice_id):
    r = get_invoice(invoice_id, TOKEN_JAN)
    assert r.status_code in (403, 404)
    assert "owner" not in r.text


def test_bez_tokenu_brak_dostepu():
    r = get_invoice(1001)
    assert r.status_code == 401

Uruchomiliśmy ten test 10.10.2026 na dwóch wersjach tego samego małego API: z kontrolą właściciela i bez niej. Wynik pokazuje dokładnie to, po co ten test istnieje. Wersja podatna przechodzi testy „szczęśliwej ścieżki”, a pada tylko na dwóch przypadkach dostępu do cudzej faktury.

$ pytest -q test_uprawnienia_faktur.py        # API z kontrolą właściciela
....                                                                     [100%]
4 passed in 0.08s

$ pytest -q test_uprawnienia_faktur.py        # ta sama wersja bez kontroli właściciela
FAILED test_uprawnienia_faktur.py::test_inny_klient_nie_widzi_cudzej_faktury[1001]
FAILED test_uprawnienia_faktur.py::test_inny_klient_nie_widzi_cudzej_faktury[1002]
2 failed, 2 passed in 0.07s

Dwie uwagi z praktyki. Po pierwsze, akceptujcie 403 albo 404, ale ustalcie w zespole jedną odpowiedź: 404 nie zdradza, że zasób istnieje, 403 jest czytelniejszy w logach. Po drugie, każda luka w uprawnieniach znaleziona ręcznie powinna w ciągu sprintu stać się takim testem, bo luka naprawiona bez testu regresji ma zwyczaj wracać jak bumerang, tylko zwykle w piątek po południu.

Jak wpisać bezpieczeństwo w wymagania i proces QA?

Zaczynając od wymagań, a nie od skanera. Zdanie „system powinien być bezpieczny” jest nietestowalne. Kryterium akceptacji „użytkownik z rolą klient pobiera wyłącznie dokumenty przypisane do własnego konta, próba pobrania cudzego dokumentu kończy się odmową i wpisem w logu” daje gotowy przypadek testowy, ręczny i automatyczny. Gotową listę takich wymagań daje OWASP ASVS, standard weryfikacji bezpieczeństwa aplikacji, którego aktualna stabilna wersja to 5.0.0.

1. Ocena ryzyka na starcie. Jakie dane przetwarza system, jakie role istnieją, które funkcje mają skutki finansowe albo prawne. Od tego zależy głębokość testów.
2. Wymagania i przypadki nadużyć. Do każdej historyjki z danymi albo uprawnieniami dopiszcie, czego użytkownik nie może zrobić. Źródłem pomysłów jest OWASP Web Security Testing Guide v4.2.
3. Automaty w potoku. Sekrety, zależności, skan pasywny i Wasze testy regresji uprawnień na każdym pull requeście.
4. Testy ręczne przed wydaniem. Przegląd nowych ról, nowych punktów końcowych API i zmian w logowaniu.
5. Właściciel ryzyka. Ktoś musi decydować, które znaleziska blokują wydanie. Bez tego raport z testów bezpieczeństwa jest listą bez skutków.

Taki układ odpowiada podejściu NIST Secure Software Development Framework (SP 800-218, wersja 1.1 z lutego 2022 roku), który zaleca wbudowanie praktyk bezpiecznego wytwarzania w istniejący cykl życia oprogramowania, zamiast dokładać je na końcu. Szerzej o testowaniu podatności w kontekście nowych obowiązków producentów piszemy w artykule o Cyber Resilience Act i testowaniu podatności; przy tematach regulacyjnych opisujemy wymogi, nie udzielamy porady prawnej.

Kiedy zlecić testy bezpieczeństwa na zewnątrz?

Gdy ryzyko jest wyższe niż kompetencje i czas zespołu, a także gdy wymaga tego klient, partner albo przepis. Najczęstsze sytuacje z naszych rozmów z klientami:

• aplikacja przetwarza dane osobowe, finansowe albo medyczne,
• wchodzicie z produktem do klientów korporacyjnych, którzy wymagają raportu z testów,
• zmieniacie mechanizm logowania, autoryzacji albo dodajecie publiczne API,
• jesteście dostawcą dla firmy objętej NIS2 i klient pyta o testy bezpieczeństwa dostawców,
• od dawna nikt nie patrzył na system pod kątem bezpieczeństwa albo pojawił się incydent.

Dla dostawców z obowiązkami wynikającymi z NIS2 prowadzimy testy bezpieczeństwa dostawców pod NIS2. Zespołom, które chcą budować kompetencje u siebie, polecamy szkolenia Cybersecurity: testy bezpieczeństwa (2 dni, OWASP ZAP i Burp Suite w praktyce) oraz testy penetracyjne aplikacji webowej. Szkolenie z testów bezpieczeństwa prowadziliśmy w formie zamkniętej między innymi dla 14 osób z AgroApp w czerwcu 2026. Programistom, którzy chcą zapobiegać lukom już przy pisaniu kodu, dedykujemy bezpieczne tworzenie aplikacji według OWASP, a o bezpieczeństwie w testowaniu rozmawiamy też na scenie Testing Ground Conference.

Powiązane na blogu Quality Island

• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje, etapy i jak je zlecić
• Jak tester może wejść do cybersecurity
• Cyber Resilience Act a testowanie podatności
• Testy API: kurs Postman w 6 lekcjach
• Testowanie manualne a testowanie automatyczne

Pełna lista źródeł

• OWASP, OWASP Top 10:2025, 2025, w tym Introduction z danymi o ponad 2,8 mln aplikacji, odsetkami 3,73% i 3,00% oraz opisem A03:2025.
• OWASP, OWASP Top 10 API Security Risks 2023, 2023.
• OWASP, Application Security Verification Standard 5.0.0, stan na 10.10.2026.
• OWASP, Web Security Testing Guide v4.2, stan na 10.10.2026.
• NIST, SP 800-218 Secure Software Development Framework 1.1, 2022.
• ZAP, Baseline Scan i GitHub Action action-baseline v0.15.0, stan na 10.10.2026.
• gitleaks, wersja 8.30.1, uruchomiona 10.10.2026.
• GitHub Docs, About Dependabot security updates, stan na 10.10.2026.
• Quality Island, test regresji uprawnień uruchomiony 10.10.2026 (pytest 9.1.1, requests 2.34.2) oraz dane własne o szkoleniu zamkniętym dla AgroApp, 2026.