Lab 4 - Michał Łezka

[gzub04]

Zadanie 1 (Opcjonalne):
Skan przy pomocy Trivy:

Zadanie 3 (Obowiązkowe):
Przygotowany został proces CI/CD, który realizuje testy z wykorzystaniem Trivy i Semgrep.
Link do pomyślnego wykonania procesu CI/CD: https://github.com/gzub04/TBO-task4/actions/runs/13059944234

Zadanie 4 (Obowiązkowe):
Wynik skanu OWASP ZAP:

Podatności wykryte przez DAST, a niewykryte przez SAST/SCA:

• Content Security Policy (CSP) Header Not Set (poziom ryzyka: średni)
• Missing Anti-clickjacking Header (poziom ryzyka: średni)
• Session ID in URL Rewrite (poziom ryzyka: średni)
• Cookie without SameSite Attribute (poziom ryzyka: niski)
• Insufficient Site Isolation Against Spectre Vulnerability (poziom ryzyka: niski)
• Permissions Policy Header Not Set (poziom ryzyka: niski)
• X-Content-Type-Options Header Missing (poziom ryzyka: niski)

Różnice w wynikach pomiędzy DAST (Dynamic Application Security Testing), a SAST (Static Application Security Testing) i SCA (Software Composition Analysis) wynikają głównie z odmiennych metod testowania.

DAST przeprowadza dynamiczne testy aplikacji w trakcie jej działania, symulując środowisko produkcyjne. Dzięki temu może wykryć błędy wynikające z konfiguracji środowiska oraz nieprawidłowej logiki biznesowej, pokazując rzeczywiste zachowanie aplikacji.

SAST analizuje kod źródłowy statycznie, identyfikując potencjalnie niebezpieczne błędy, choć nie zawsze są one faktycznie wykorzystywalne w atakach.

SCA koncentruje się na analizie zależności, sprawdzając podatności w używanych bibliotekach i frameworkach, ale bez informacji, czy daną podatność można rzeczywiście wykorzystać.

Zarówno SAST, jak i SCA nie uwzględniają konfiguracji środowiska, dlatego nie mogą oznaczyć niektórych podatności jako rzeczywiste luki bezpieczeństwa, ponieważ te mogą wynikać z konfiguracji serwera dostosowanej do logiki biznesowej aplikacji.