Przejdź do głównej zawartości

Software Supply Chain Failures: Opis podatności i jej wpływ

Aktualizacja 2026-10-03

W edycji 2021 ta kategoria nazywała się A06:2021 – Vulnerable and Outdated Components i dotyczyła głównie znanych podatności w bibliotekach. W OWASP Top 10:2025 obejmuje cały łańcuch dostaw oprogramowania — rozdział został o to rozszerzony.

📦 A03:2025 – Software Supply Chain Failures​

OWASP definiuje błędy łańcucha dostaw jako awarie lub kompromitacje w procesie budowania, dystrybucji albo aktualizacji oprogramowania — najczęściej przez podatności lub złośliwe zmiany w kodzie stron trzecich, narzędziach i zależnościach.

Zakres jest więc szerszy niż „mamy starą bibliotekę":

Odcinek łańcuchaPrzykład awarii
Zależnościznana podatność w bibliotece, także przechodniej; biblioteka porzucona przez opiekunów
Pochodzenie pakietupakiet pobrany z niewłaściwego repozytorium (dependency confusion), podszywanie się pod nazwę
Build i CI/CDpipeline słabiej chroniony niż systemy, które wdraża; złośliwy kod uruchamiany przy budowaniu
Dystrybucja i aktualizacjeskompromitowany dostawca wypuszcza złośliwą aktualizację podpisaną prawdziwym kluczem
Stanowiska deweloperówprzejęte tokeny publikacji, złośliwe rozszerzenia IDE

Skąd ta kategoria na #3?​

  • Została wybrana w ankiecie społeczności: według OWASP dokładnie 50% respondentów umieściło ją na pierwszym miejscu.
  • Według wstępu edycji ma najmniej wystąpień w danych, a strona kategorii podaje tylko 11 CVE z powiązanymi CWE. Autorzy tłumaczą to trudnością testowania, nie rzadkością problemu.
  • Tam, gdzie ją testowano, ma najwyższą średnią częstość wśród kategorii — tekst strony kategorii podaje 5,19%, tabela na tej samej stronie 5,72%.
  • Według wstępu ma też najwyższe średnie oceny exploitowalności i wpływu z CVE.

Źródło: A03:2025 na owasp.org. Uwaga: strona kategorii nie jest w pełni spójna ze wstępem edycji — tabela podaje 6 zmapowanych CWE, wstęp mówi o 5.

Przykłady ataków​

Scenariusze opisane przez OWASP:

  • SolarWinds (2019) — skompromitowany zaufany dostawca; według OWASP ok. 18 000 organizacji przejętych przez aktualizację.
  • Bybit (2025) — kradzież 1,5 mld USD przez złośliwy kod w oprogramowaniu portfela, który uruchamiał się tylko przy użyciu konkretnego portfela.
  • Shai-Hulud (2025) — według OWASP pierwszy samorozprzestrzeniający się robak w npm: skrypt post-install wykradał dane, a znalezione tokeny npm wykorzystywał do publikowania złośliwych wersji kolejnych pakietów. Objął ponad 500 wersji pakietów.
  • Log4Shell (CVE-2021-44228) i Struts 2 (CVE-2017-5638) — klasyczne RCE w komponentach, które działają z uprawnieniami aplikacji.

Spoza listy OWASP warto znać xz-utils (CVE-2024-3094): złośliwy kod był w tarballach wydań od wersji 5.6.0, a proces budowania liblzma wyciągał go z pliku udającego dane testowe. Lockfile i weryfikacja podpisu nic by tu nie dały — złośliwe było oficjalne wydanie.

🧨 Potencjalne skutki​

  • Zdalne wykonanie kodu (RCE) — komponent działa z uprawnieniami aplikacji.
  • Kradzież sekretów z maszyn deweloperów i runnerów CI (tokeny, klucze chmurowe).
  • Trwała obecność napastnika — złośliwy kod w artefakcie trafia na każde środowisko, na które go wdrożysz.
  • Rozprzestrzenianie się na klientów — Twoja aplikacja staje się ogniwem cudzego łańcucha dostaw.

🛑 Dlaczego do tego dochodzi?​

Według OWASP jesteś podatny, jeśli m.in.:

  • nie śledzisz wersji wszystkich komponentów, łącznie z zależnościami przechodnimi,
  • nie skanujesz regularnie podatności i nie subskrybujesz biuletynów bezpieczeństwa,
  • łatki instalujesz raz w miesiącu lub kwartale w ramach change management, co zostawia dni lub miesiące niepotrzebnej ekspozycji,
  • jedna osoba może napisać kod i wypchnąć go aż na produkcję bez przeglądu drugiej osoby,
  • pipeline CI/CD jest słabiej zabezpieczony niż systemy, które buduje i wdraża.

⚖️ Lista CVE to za mało​

Wynik skanera zależności to dopiero początek analizy:

  • Podatność w zależności to jeszcze nie podatność w aplikacji. Alert znaczy coś dopiero wtedy, gdy podatna funkcja jest osiągalna z Twojego kodu. Ślepe podbijanie wersji daje pracę bez zysku i ryzyko regresji (Malcolm McDonald, Grokking Web Application Security, 2024, s. 99, 276). Odłożona łatka pozostaje jednak długiem do spłacenia.
  • Pusty raport skanera opisuje zasięg skanu, a nie stan systemu — SCA nie zobaczy złośliwego, ale „czystego" w bazach CVE pakietu.
  • Integralność ma granice — podpis i lockfile chronią przed podmianą po drodze, nie przed złośliwym wydaniem u źródła (xz-utils).

✅ Dobre praktyki​

  • Utrzymuj SBOM (Software Bill of Materials) całej aplikacji — ASVS 5.0 wymaga tego na poziomie L2 (wymaganie 15.1.2).
  • Określ terminy łatania zależności według ryzyka i ich przestrzegaj (ASVS 15.1.1 i 15.2.1, poziom L1).
  • Pobieraj pakiety tylko z oczekiwanych repozytoriów — bez ryzyka dependency confusion (ASVS 15.2.4, L3).
  • Usuwaj nieużywane zależności, funkcje i pliki — mniejsza powierzchnia ataku.
  • Wdrażaj aktualizacje etapami (canary, staged rollout), żeby ograniczyć skutki skompromitowanego dostawcy.
  • Chroń repozytorium, stacje deweloperów i CI/CD: MFA, najmniejsze uprawnienia, sekrety ograniczone do środowiska, podpisane buildy.

W kolejnym kroku: Metody testowania podatności

Ostatnia aktualizacja dnia