Skany podatności aplikacji – DAST, SAST, SCA, IaC i kontenery: co wykrywa każda metoda i gdzie kończy się skan, a zaczyna pentest

Czym są skany podatności aplikacji? Skany podatności aplikacji to rodzina zautomatyzowanych metod wykrywania luk w oprogramowaniu tworzonym lub wdrażanym przez organizację: DAST bada działającą aplikację z zewnątrz, SAST analizuje kod źródłowy, SCA sprawdza biblioteki zewnętrzne, a skany IaC i kontenerów – definicje infrastruktury i obrazy. Każda metoda widzi inną warstwę i inną klasę błędów, dlatego dojrzały program łączy kilka z nich w potoku CI/CD. Skany infrastruktury (hosty, sieć, ASV) opisaliśmy w osobnym aktywie – Skany podatności infrastruktury; ten artykuł dotyczy wyłącznie warstwy aplikacyjnej.

Definicja kanoniczna: Skanowanie podatności aplikacji to zautomatyzowana analiza oprogramowania – jego kodu, zależności, artefaktów wdrożeniowych lub działającej instancji – w celu wykrycia znanych klas błędów bezpieczeństwa przed ich wykorzystaniem.

Skany podatności aplikacji – w skrócie:

1. DAST testuje działającą aplikację jak atakujący (bez kodu), SAST czyta kod źródłowy, SCA identyfikuje podatne biblioteki – trzy metody, trzy rozłączne zbiory wykrywanych błędów.
2. PCI DSS v4.0.1 wymaga od 31 marca 2025 inwentaryzacji komponentów oprogramowania (6.3.2) oraz automatycznego rozwiązania technicznego chroniącego publiczne aplikacje webowe (6.4.2).
3. DORA (RTS 2024/1774, art. 10) wymaga śledzenia bibliotek zewnętrznych, w tym open source, w usługach wspierających funkcje krytyczne; CRA wymaga od producentów SBOM i procesu obsługi podatności.
4. Żaden skan nie wykryje błędów logiki biznesowej, błędów autoryzacji między obiektami (IDOR/BOLA) ani łańcuchów podatności – to domena testu penetracyjnego.
5. Skany aplikacji powinny działać w potoku CI/CD z progami blokującymi wdrożenie, a nie jako kwartalny raport.
6. Patronusec łączy skany aplikacji z testami penetracyjnymi aplikacji webowych i API według OWASP ASVS, dostarczając raporty akceptowalne dla audytu PCI DSS i DORA.

---

---

Jakie są rodzaje skanów podatności aplikacji i co wykrywa każdy z nich?

Pięć podstawowych rodzajów skanów aplikacji to DAST (dynamiczna analiza działającej aplikacji), SAST (statyczna analiza kodu), SCA (analiza składu oprogramowania, czyli zależności), skany IaC (szablony infrastruktury) oraz skany kontenerów i obrazów. Uzupełniają je IAST (agent w aplikacji testowej) i skany sekretów. Każdy działa na innym etapie cyklu wytwarzania i wykrywa inną klasę błędów.

Metoda	Co analizuje	Kiedy w cyklu	Typowe wykrycia	Czego nie widzi
SAST	kod źródłowy lub bajtkod, bez uruchamiania	commit, pull request	wstrzyknięcia SQL, XSS, niebezpieczne funkcje, zaszyte sekrety, błędy walidacji	błędów konfiguracji środowiska, podatności w bibliotekach, problemów widocznych dopiero w runtime
SCA	manifesty zależności, lockfile, artefakty	build	znane CVE w bibliotekach, licencje, przestarzałe wersje, brak podpisów	błędów we własnym kodzie, tego, czy podatna funkcja jest w ogóle wywoływana
Skan IaC	Terraform, CloudFormation, Helm, Kubernetes YAML, Dockerfile	pull request, plan	otwarte security groups, brak szyfrowania, uprawnienia „*”, kontenery jako root	stanu faktycznego w chmurze (dryf konfiguracji)
Skan kontenerów	obrazy (warstwy, pakiety OS, biblioteki), rejestr	build, push do rejestru, runtime	CVE w pakietach bazowych, sekrety w warstwach, brak użytkownika nieuprzywilejowanego	podatności aplikacji w obrazie, błędów orkiestracji
DAST	działająca aplikacja przez HTTP, bez kodu	staging, produkcja	XSS odbite, błędy nagłówków, ujawnienie informacji, część wstrzyknięć, słabe TLS	logiki biznesowej, błędów autoryzacji, funkcji za złożonym uwierzytelnieniem, API bez specyfikacji
IAST	instrumentacja aplikacji podczas testów	testy integracyjne	jak SAST i DAST, z mniejszą liczbą fałszywych alarmów	ścieżek nieobjętych testami
Skan sekretów	repozytorium i historia gita	commit, okresowo	klucze API, hasła, tokeny w kodzie i historii	sekretów przekazywanych poza repozytorium

DAST (Dynamic Application Security Testing) testuje działającą aplikację z perspektywy zewnętrznego użytkownika bez dostępu do kodu, natomiast SAST (Static Application Security Testing) analizuje kod źródłowy bez jego uruchamiania – obie metody wykrywają rozłączne klasy błędów.

Najważniejsza konsekwencja tej tabeli: nie ma jednego skanera aplikacji. Organizacja, która ma „skaner aplikacji webowych” (DAST) i uważa temat za zamknięty, nie widzi podatnych bibliotek (SCA), zaszytych sekretów (SAST, skan sekretów) ani błędnie skonfigurowanych kontenerów. Przegląd wszystkich metod testów w kontekście programu bezpieczeństwa znajdziesz w artykule o metodach testowania bezpieczeństwa IT.

W praktyce oznacza to minimum trzy skany dla każdej aplikacji tworzonej wewnętrznie: SAST i SCA na etapie budowania oraz DAST na środowisku testowym – plus skan kontenerów, jeśli aplikacja działa w Kubernetes.

Dlaczego SCA i SBOM stały się wymogiem regulacyjnym, a nie tylko dobrą praktyką?

SCA i SBOM stały się wymogiem, bo podatności w komponentach zewnętrznych – jak Log4Shell (CVE-2021-44228) czy seria incydentów w pakietach npm i NuGet – pokazały, że organizacja nie wie, co ma w produkcji. PCI DSS 6.3.2, DORA RTS art. 10 ust. 2 lit. d oraz CRA (załącznik I część II) wymagają dziś inwentaryzacji komponentów i śledzenia ich podatności.

Trzy wymogi, które przenoszą SCA z kategorii „dobra praktyka” do „obowiązek”:

• PCI DSS v4.0.1, wymóg 6.3.2 (obowiązkowy od 31 mar 2025): utrzymywanie inwentarza oprogramowania własnego i dostosowanego, w tym komponentów zewnętrznych, aby ułatwić zarządzanie podatnościami i poprawkami. W praktyce – SBOM dla każdej aplikacji w zakresie CDE.
• DORA, RTS 2024/1774, art. 10 ust. 2 lit. d: śledzenie użycia bibliotek zewnętrznych, w tym open source, w usługach ICT wspierających funkcje krytyczne lub istotne oraz monitorowanie ich wersji i aktualizacji, w razie potrzeby wspólnie z dostawcą ICT.
• Cyber Resilience Act, załącznik I część II: producenci produktów z elementami cyfrowymi identyfikują i dokumentują komponenty, w tym sporządzają SBOM w powszechnie używanym formacie maszynowym obejmujący co najmniej zależności najwyższego poziomu, oraz bez zbędnej zwłoki usuwają podatności. Obowiązek zgłaszania aktywnie wykorzystywanych podatności stosuje się od 11 wrz 2026 – szczegóły w artykule o obowiązkach CRA od 11 września 2026.

SBOM (Software Bill of Materials) to maszynowo przetwarzalny wykaz komponentów oprogramowania wraz z ich wersjami i zależnościami, wymagany przez Cyber Resilience Act od producentów produktów z elementami cyfrowymi oraz pośrednio przez PCI DSS 6.3.2 i RTS DORA art. 10.

Dwa formaty SBOM dominują w praktyce: CycloneDX (OWASP) i SPDX (Linux Foundation, norma ISO/IEC 5962:2021). Narzędzia SCA generują je automatycznie na etapie budowania; wyzwaniem nie jest wygenerowanie SBOM, lecz jego utrzymanie dla każdej wersji wdrożonej na produkcji i powiązanie z procesem reagowania na nowe CVE.

W praktyce oznacza to, że gdy pojawia się kolejny „Log4Shell”, organizacja z aktualnym SBOM odpowiada na pytanie „czy to nas dotyczy” w minuty, a organizacja bez SBOM – w dni, przeszukując repozytoria i serwery.

Jak działa DAST i dlaczego nie zastępuje testu penetracyjnego aplikacji?

DAST wysyła do działającej aplikacji spreparowane żądania HTTP i analizuje odpowiedzi w poszukiwaniu sygnatur błędów: odbitego XSS, komunikatów bazy danych, brakujących nagłówków, ujawnionych plików. Nie rozumie logiki aplikacji, nie wie, kto powinien mieć dostęp do jakiego zasobu, i zwykle nie przejdzie przez wieloetapowe uwierzytelnienie – dlatego wykrywa ułamek tego, co znajdzie pentester.

Klasy błędów, których DAST nie wykryje lub wykryje sporadycznie:

1. Błędy autoryzacji (IDOR, BOLA w API) – skaner nie wie, że użytkownik A nie powinien widzieć zamówienia użytkownika B.
2. Logika biznesowa – rabat naliczony dwa razy, pominięty krok weryfikacji, ujemna ilość w koszyku.
3. Łańcuchy podatności – ujawnienie informacji + słaby reset hasła + brak limitu prób = przejęcie konta; każdy element osobno ma niski priorytet.
4. Funkcje za złożonym uwierzytelnieniem – MFA, SSO, tokeny sesyjne z krótkim życiem zatrzymują skaner na stronie logowania.
5. API bez specyfikacji – bez OpenAPI/Swagger skaner nie zna punktów końcowych i parametrów.
6. Ataki na tożsamość i sesję – manipulacja JWT, race conditions, błędy w OAuth.

Test penetracyjny aplikacji różni się od skanu DAST tym, że tester rozumie model uprawnień i logikę biznesową aplikacji, weryfikuje każde ustalenie ręcznie i łączy pojedyncze słabości w realną ścieżkę ataku.

Punktem odniesienia dla zakresu testu manualnego jest OWASP ASVS (Application Security Verification Standard) w wersji 5.0 z 2025 r. – lista wymagań weryfikacyjnych w trzech poziomach, z których skanery automatyczne pokrywają wiarygodnie tylko część poziomu 1. Kategorie z OWASP Top 10 dotyczące kontroli dostępu i błędów projektowych wymagają weryfikacji manualnej.

Rola DAST jest inna niż pentestu: to codzienny lub cotygodniowy strażnik regresji (czy nowe wdrożenie nie otworzyło znanej klasy błędu), a nie roczna ocena odporności. Wymóg 11.4 PCI DSS (pentest aplikacji co najmniej raz w roku i po istotnej zmianie) oraz art. 25 DORA rozróżniają te dwa narzędzia. Patronusec realizuje testy penetracyjne aplikacji webowych i API według ASVS, traktując wyniki DAST i SAST klienta jako punkt wyjścia, a nie substytut testu.

W praktyce oznacza to: DAST co tydzień na staging i po każdym wdrożeniu, pentest raz w roku i po istotnej zmianie funkcjonalnej – obie pozycje w harmonogramie, żadna nie zastępuje drugiej.

Jak skanować kontenery, obrazy i infrastrukturę jako kod?

Kontenery skanujesz na trzech etapach: obraz bazowy i Dockerfile w pull requeście, zbudowany obraz przy publikacji do rejestru (blokada obrazów z krytycznymi CVE) oraz uruchomione kontenery w klastrze (dryf, nowe CVE w starych obrazach). Infrastrukturę jako kod skanujesz przed zastosowaniem planu – Terraform, Helm i manifesty Kubernetes – porównując je z benchmarkami CIS i politykami organizacji.

Warstwy skanu kontenera i typowe ustalenia:

Warstwa	Co skanujesz	Typowe ustalenia	Wymóg
Dockerfile	instrukcje budowania	obraz bazowy latest, brak USER, kopiowanie sekretów, zbędne pakiety	CIS Docker Benchmark
Obraz	pakiety systemu operacyjnego i biblioteki w warstwach	CVE w pakietach bazowych (glibc, openssl), przestarzały obraz bazowy	PCI DSS 6.3.1, DORA RTS art. 10
Rejestr	polityka dopuszczania obrazów	obrazy niepodpisane, brak skanu, obrazy starsze niż X dni	zasada „tylko zeskanowane i podpisane obrazy na produkcję”
Runtime (klaster)	uruchomione kontenery i konfiguracja podów	kontener jako root, brak limitów, hostPath, uprzywilejowany tryb, nowe CVE w działających obrazach	CIS Kubernetes Benchmark, PCI DSS 2.2

Skan IaC ma jedną cechę odróżniającą go od pozostałych: wykrywa błąd, zanim zasób powstanie. Otwarta na świat grupa bezpieczeństwa lub bucket bez szyfrowania zatrzymane na etapie terraform plan nigdy nie stają się incydentem. Ograniczeniem jest dryf: to, co zdefiniowano w kodzie, nie musi być tym, co działa w chmurze po ręcznych zmianach – dlatego skan IaC uzupełnia się skanem stanu faktycznego (CSPM).

Skan kontenerów obejmuje trzy momenty – definicję obrazu w kodzie, zbudowany artefakt w rejestrze i uruchomioną instancję w klastrze – ponieważ podatność może pojawić się na każdym z tych etapów, także w obrazie, który był czysty w chwili publikacji.

Wymóg PCI DSS w środowiskach kontenerowych ma dodatkową specyfikę – zakres CDE, segmentacja między podami i dowody dla audytora – którą opisaliśmy w artykule PCI DSS w środowiskach kontenerowych.

W praktyce oznacza to, że polityka „żaden obraz z krytyczną CVE nie trafi do rejestru produkcyjnego” wdrożona w potoku CI/CD zastępuje setki stron procedur – i jest dowodem, który audytor sprawdzi w konfiguracji potoku, nie w dokumencie.

Jak wpiąć skany aplikacji w potok CI/CD, żeby blokowały, a nie tylko raportowały?

Skany aplikacji wpinasz w potok jako bramki jakości: SAST i skan sekretów w pull requeście, SCA i skan obrazu na etapie budowania, skan IaC przed zastosowaniem planu, DAST po wdrożeniu na środowisko testowe. Każda bramka ma próg blokujący (np. brak nowych podatności krytycznych i wysokich z dostępną poprawką) oraz proces wyjątków z właścicielem i datą wygaśnięcia.

Schemat potoku z bramkami:

1. Pre-commit / pull request: skan sekretów (blokada bezwarunkowa), SAST z regułami dla języka (blokada dla krytycznych), przegląd kodu.
2. Build: SCA – blokada dla CVE krytycznych i wysokich z dostępną poprawką; generowanie SBOM i zapis jako artefakt wersji.
3. Artefakt: skan obrazu kontenera – blokada dla krytycznych; podpis obrazu.
4. Infrastruktura: skan IaC na plan – blokada dla naruszeń polityk (publiczny dostęp, brak szyfrowania, nadmierne uprawnienia).
5. Deploy na test: DAST z uwierzytelnieniem – raport, blokada dla wybranych klas (np. wstrzyknięcia).
6. Produkcja: skan runtime kontenerów i CSPM w trybie ciągłym; powtórny SCA wobec SBOM przy każdej nowej CVE.

Trzy zasady, bez których bramki są ignorowane:

• Próg „nowe vs istniejące” – bramka blokuje tylko nowe podatności wprowadzone w danej zmianie; dług historyczny obsługuje osobny plan, inaczej pierwsze uruchomienie zablokuje wszystko na miesiące.
• Wyjątki z datą wygaśnięcia – każde „akceptujemy” ma właściciela, uzasadnienie i termin ponownej oceny; wyjątki bezterminowe to dziura w procesie.
• Czas skanu – SAST powyżej 10 minut w pull requeście zostanie wyłączony przez deweloperów; skany pełne uruchamiaj nocą, w PR – przyrostowe.

Bramka jakości bezpieczeństwa w potoku CI/CD to zautomatyzowany próg, który wstrzymuje wdrożenie, gdy skan wykryje podatność przekraczającą ustalony poziom – w odróżnieniu od skanu raportującego, którego wyniki nie wpływają na przebieg wdrożenia.

Wymóg 6.4.2 PCI DSS v4.0.1 (obowiązkowy od 31 mar 2025) wymaga dla publicznych aplikacji webowych automatycznego rozwiązania technicznego wykrywającego i zapobiegającego atakom (np. WAF) – to warstwa ochronna w runtime, niezależna od skanów, ale zasilana ich wynikami (wirtualne łatanie do czasu poprawki).

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że audytorzy – QSA i audytorzy ISO 27001 – coraz częściej proszą o dowód w postaci konfiguracji potoku i historii uruchomień bramek, a nie procedury w Wordzie. Trzy elementy, które warto mieć gotowe: politykę progów blokujących (co blokuje, co tylko raportuje), rejestr wyjątków z datami oraz SBOM powiązany z konkretną wersją wdrożoną na produkcji. Patronusec w ramach testów penetracyjnych aplikacji przegląda również konfigurację potoku klienta i wskazuje, które klasy podatności z raportu pentestu powinny stać się regułą w SAST lub DAST, aby nie wracały w kolejnym teście.

Ile kosztują skany aplikacji i jak wybrać między narzędziami open source a komercyjnymi?

Koszt skanów aplikacji rozkłada się na trzy składniki: licencje lub subskrypcje narzędzi, czas zespołu na konfigurację i triage wyników oraz opcjonalnie usługę zewnętrzną. Narzędzia open source pokrywają wszystkie pięć kategorii skanów bez kosztu licencji, ale wymagają więcej pracy własnej; platformy komercyjne integrują wyniki i redukują fałszywe alarmy za cenę subskrypcji.

Kategoria	Przykłady open source	Model komercyjny	Orientacyjny koszt roczny (zespół 20-50 dev.)
SAST	Semgrep (reguły open source), CodeQL (bezpłatny dla open source), Bandit, SpotBugs	subskrypcja per deweloper lub per repozytorium	0 zł (OSS) do 60 tys. zł
SCA / SBOM	OWASP Dependency-Check, Trivy, Grype, Syft (SBOM), Dependency-Track	per deweloper lub per projekt	0 zł do 20 tys. zł
Skan IaC	Checkov, tfsec, KICS, Kubescape	zwykle w pakiecie z platformą	0 zł do 30 tys. zł
Skan kontenerów	Trivy, Grype, Clair	per węzeł lub per obraz	0 zł do 20 tys. zł
DAST	OWASP ZAP, Nuclei (szablony)	per aplikacja lub per skan	0 zł do 30 tys. zł
Usługa zewnętrzna (konfiguracja + triage + raport)	–	miesięczny retainer lub projekt	30-150 tys. zł rocznie

Kryteria wyboru, które ważą więcej niż cena licencji:

• Fałszywe alarmy – narzędzie, które generuje 80 % szumu, zostanie wyłączone; koszt triage’u przekracza koszt licencji.
• Wsparcie języków i frameworków – SAST dla Javy nie pomoże w projekcie w Go; sprawdź pokrycie własnego stosu.
• Integracja z potokiem i systemem zgłoszeń – wynik, który nie staje się ticketem, nie zostanie usunięty.
• Deduplikacja między narzędziami – ta sama CVE zgłoszona przez SCA, skan obrazu i DAST to trzy tickety lub jeden, zależnie od platformy.

Koszt programu skanów aplikacji w większym stopniu zależy od czasu zespołu poświęcanego na triage fałszywych alarmów i utrzymanie reguł niż od ceny licencji narzędzi – dlatego jakość sygnału jest ważniejszym kryterium wyboru niż liczba obsługiwanych kontroli.

W praktyce oznacza to, że zespół 20 deweloperów może uruchomić kompletny zestaw skanów na narzędziach open source w 2-4 tygodnie pracy jednej osoby, ale bez kogoś, kto co tydzień przegląda wyniki i utrzymuje reguły, program umrze po kwartale.

Jakie błędy popełniają praktycy przy skanach aplikacji?

Najczęstsze błędy dotyczą mylenia metod, trybu „tylko raport”, braku obsługi długu historycznego i traktowania skanu jako dowodu bezpieczeństwa aplikacji.

❌ Jeden skaner jako „bezpieczeństwo aplikacji” – DAST nie widzi bibliotek, SCA nie widzi własnego kodu, SAST nie widzi konfiguracji; wymóg PCI DSS 6.3.2 (inwentarz komponentów) i 6.2.4 (kod) dotyczą różnych warstw.

❌ Skany w trybie raportującym bez bramek – wyniki trafiają do dashboardu, którego nikt nie czyta; audytor zapyta, co się stało z podatnością krytyczną z marca.

❌ Pierwsza bramka blokująca cały dług historyczny – potok stoi, zespół wyłącza skaner; próg powinien dotyczyć nowych podatności, a dług – osobnego planu.

❌ DAST bez uwierzytelnienia – skaner testuje stronę logowania i stopkę; 90 % funkcjonalności pozostaje niezbadane.

❌ SBOM wygenerowany raz, nigdy nieaktualizowany – SBOM musi odpowiadać wersji na produkcji; inaczej odpowiedź na pytanie „czy dotyczy nas nowa CVE” jest zgadywaniem.

❌ Skan jako zamiennik pentestu – czysty raport DAST i SAST nie oznacza braku IDOR, błędów logiki ani łańcuchów podatności; PCI DSS 11.4 i DORA art. 25 wymagają pentestu niezależnie od skanów.

Checklist audytora – co sprawdzi QSA lub audytor w obszarze skanów aplikacji?

1. Czy istnieje inwentarz oprogramowania własnego i dostosowanego z listą komponentów zewnętrznych (PCI DSS 6.3.2, DORA RTS art. 10 ust. 2 lit. d)?
2. Czy SBOM jest generowany automatycznie dla każdej wersji i powiązany z wdrożeniem na produkcji?
3. Czy w potoku CI/CD działają bramki SAST, SCA i skanu obrazów z udokumentowanymi progami?
4. Czy istnieje rejestr wyjątków od bramek z właścicielem, uzasadnieniem i datą wygaśnięcia?
5. Czy DAST działa z uwierzytelnieniem i obejmuje API (na podstawie specyfikacji OpenAPI)?
6. Czy podatności z komponentów są usuwane w terminach zgodnych z procedurą (PCI DSS 6.3.3: krytyczne i wysokie w ciągu miesiąca od wydania poprawki)?
7. Czy publiczne aplikacje webowe są chronione automatycznym rozwiązaniem technicznym (PCI DSS 6.4.2)?
8. Czy wyniki pentestu aplikacji są przekładane na reguły skanerów, aby zapobiec regresji?
9. Czy obrazy kontenerów na produkcji pochodzą wyłącznie z rejestru z polityką skanowania i podpisów?
10. Czy zespół deweloperski przeszedł szkolenie z bezpiecznego kodowania (PCI DSS 6.2.2)?

---

FAQ – jak skanować podatności aplikacji

---

Warto przeczytać

1. Skany podatności infrastruktury – hub definicji skanu podatności; hosty, sieć, ASV, priorytetyzacja CVSS/EPSS/KEV.
2. Skany podatności a wymogi compliance – mapowanie DORA, NIS2, CRA, PCI DSS, ISO 27001, SOC 2.
3. Metody testowania bezpieczeństwa IT – jak skany aplikacji łączą się z pentestami i red teamingiem.
4. PCI DSS w środowiskach kontenerowych – zakres CDE, segmentacja i dowody audytowe dla Kubernetes.
5. CRA dla software house’u – obowiązki producenta oprogramowania, w tym SBOM i obsługa podatności.
6. Złośliwy pakiet NuGet – atak typosquattingowy – przykład ryzyka w łańcuchu dostaw, które wykrywa SCA.

---

Skany podatności aplikacji – konsultacja

Patronusec realizuje testy penetracyjne aplikacji webowych i API według OWASP ASVS oraz doradza przy konfiguracji bramek SAST, SCA i DAST w potoku CI/CD, tak aby wyniki spełniały wymogi PCI DSS 6.x i DORA. Jeśli chcesz sprawdzić, czy Twój program skanów aplikacji przejdzie audyt, umów bezpłatną rozmowę.

Testy penetracyjne | Skany podatności | Certyfikacja PCI DSS