Przejdź do głównej zawartości

Software Supply Chain Failures: Metody testowania

Metody testowania podatności: Software Supply Chain Failures​

Punkty 1–5 sprawdzają znane podatności w komponentach (zakres dawnego A06:2021). Punkty 6–9 dotyczą reszty łańcucha dostaw, dodanej w edycji 2025.

1. 📦 Analiza plików zależności​

  • Przeskanuj:
    • package.json, yarn.lock (JavaScript)
    • pom.xml, build.gradle (Java)
    • requirements.txt, Pipfile.lock (Python)
    • composer.json, composer.lock (PHP)
    • packages.config, .csproj (C#/.NET)
  • Sprawdź wersje bibliotek i frameworków – ręcznie lub automatycznie.

2. Wykorzystanie narzędzi SCA (Software Composition Analysis)​

Narzędzia te identyfikują znane podatności CVE w zależnościach aplikacji.

  • Przykładowe narzędzia:
    • OWASP Dependency-Check
    • Syft + Grype
    • Snyk
    • GitHub Dependabot
    • Trivy
    • npm audit / yarn audit
    • pnpm audit

3. 🔗 Testowanie zależności transitive​

  • Sprawdź, czy aplikacja używa zależności, które same w sobie mają zależności (tzw. transitive dependencies).
  • Przykład: express ➝ body-parser ➝ qs ➝ podatna wersja qs.

4. Weryfikacja obrazów kontenerowych​

  • Testuj bazowe obrazy Docker:
    • FROM node:12 (EOL)
    • FROM ubuntu:18.04 (brak wsparcia)
  • Używaj trivy, dockle, grype do audytu kontenerów.

5. Ręczna inspekcja bibliotek frontendowych​

  • Otwórz devtools → sources/scripts i sprawdź wersje bibliotek np. jQuery, Bootstrap, Angular.
  • Sprawdź publicznie dostępne paczki CDN i ich wersje.

6. 🎯 Ocena osiągalności podatności​

Dla każdego zgłoszenia ze skanera odpowiedz w raporcie:

  • Czy podatna funkcja jest wywoływana przez aplikację? Narzędzia z analizą osiągalności (np. govulncheck dla Go) na podstawie statycznego grafu wywołań oddzielają podatności w funkcjach osiągalnych z Twojego kodu od tych, których kod nie wywołuje.
  • Czy podatna biblioteka trafia na produkcję, czy jest tylko zależnością deweloperską?
  • Czy dane od użytkownika mogą dotrzeć do podatnego miejsca?

Nieosiągalna podatność nadal jest długiem do spłacenia, ale nie powinna mieć w raporcie tego samego priorytetu co osiągalne RCE.

7. 📥 Pochodzenie pakietów i dependency confusion​

  • Sprawdź konfigurację menedżerów pakietów: .npmrc, pip.conf, PIP_EXTRA_INDEX_URL, nuget.config, ustawienia repozytoriów w Maven/Gradle.
  • Szukaj mieszania indeksów prywatnych i publicznych. Dokumentacja pip wprost ostrzega: --extra-index-url nie ustala priorytetu źródeł — pip wybiera najlepiej pasującą wersję z dowolnego indeksu. Jeśli nazwa prywatnego pakietu jest wolna w publicznym indeksie, napastnik może tam opublikować pakiet o tej nazwie z wyższym numerem wersji.
  • Sprawdź, czy nazwy wewnętrznych pakietów są zarezerwowane w publicznych rejestrach (np. przez scope @firma/ w npm).
  • Zweryfikuj, czy lockfile zawiera skróty integralności (integrity w package-lock.json, --require-hashes w pip) i czy CI instaluje zależności z lockfile (npm ci zamiast npm install).

8. 🏗️ Przegląd pipeline CI/CD​

Pipeline łączy prawo zapisu do repozytorium z dostępem do produkcji, więc każde jego wejście jest potencjalną ścieżką na produkcję. Sprawdź:

  • kto może zmienić definicję pipeline'u i czy taka zmiana wymaga przeglądu,
  • czy jedna osoba może wypchnąć kod na produkcję bez akceptacji drugiej (OWASP: brak separation of duty),
  • czy sekrety są ograniczone do środowiska i niedostępne dla buildów z forków lub gałęzi bez przeglądu,
  • czy akcje i obrazy zewnętrzne są przypięte do konkretnej wersji (najlepiej skrótu), a nie do zmiennego tagu,
  • czy artefakty są podpisane, mają udokumentowane pochodzenie (provenance) i są promowane między środowiskami zamiast budowania od nowa,
  • czy w logach pipeline'u da się wykryć modyfikację (tamper-evident).

9. 🧑‍💻 Zasoby poza aplikacją​

OWASP zalicza do łańcucha dostaw także: rozszerzenia IDE, repozytoria obrazów i artefaktów, rejestry kontenerów, integracje SaaS i infrastrukturę jako kod. W teście aplikacji zwykle nie masz do nich dostępu — jeśli tak, zapisz to w raporcie jako ograniczenie zakresu, a nie jako brak problemów.

✅ Tipy testerskie​

  • Skorzystaj z narzędzi CI/CD (np. GitHub Actions, GitLab CI) do zautomatyzowanego skanowania zależności.
  • Sprawdzaj daty publikacji ostatnich wersji – jeśli brak update’ów >12 miesięcy, rozważ zmianę komponentu.
  • Zgłaszaj błędy do zespołu dev i proponuj update z changelogiem.

W kolejnym podrozdziale: Weryfikacja konfiguracji aplikacji i serwera

Ostatnia aktualizacja dnia