OWASP, czyli Open Worldwide Application Security Project, zaproponowało nowe wydanie swojej klasycznej listy Top 10 ryzyk aplikacyjnych. Wersja z 2025 roku wprowadza kluczowe rozszerzenia dotyczące bezpieczeństwa łańcucha dostaw oprogramowania (SSCS, Software Supply Chain Security). Najbardziej znaczące zmiany to dodanie kategorii „Supply Chain Failures” na trzecim miejscu i „Mishandling of Exceptional Conditions” na miejscu dziesiątym.

Autor: 5 min czytania

Dlaczego supply chain stało się tak ważne

Aktualizacja listy OWASP odzwierciedla rosnącą świadomość faktu, że zagrożenia nie wynikają już tylko z błędów w kodzie, ale z architektury, procesów i zależności między komponentami. Eksperci komentują, że granica między zagrożeniami „wewnętrznymi” a „zewnętrznymi” staje się coraz bardziej płynna – ataki mogą pochodzić zarówno ze środowiska deweloperskiego (np. build pipeline), jak i ze stron trzecich (biblioteki, rejestry kontenerów, narzędzia CI/CD).

Jagadeesh Kunda, współzałożyciel firmy zajmującej się IAM (identity and access management), podkreśla, że ryzyka te nie są już odrębnymi problemami, lecz „toksycznymi kombinacjami” – błąd w konfiguracji, komponent zewnętrzny i niewłaściwe zarządzanie wyjątkami mogą w połączeniu stworzyć idealną sytuację do ataku.

Jakie są nowe priorytety dla AppSec

Nowa edycja OWASP Top 10 sygnalizuje zmianę paradygmatu w AppSec: mniej skupiamy się na typowych błędach kodu (np. SQL injection), a więcej na strukturze systemu, procesach i zarządzaniu zależnościami. Rosario Mastrogiacomo, strateg ds. bezpieczeństwa, zauważa, że zespoły deweloperskie i zabezpieczające muszą zacząć myśleć holistycznie: nie tylko o pojedynczym fragmencie kodu, ale o całym ekosystemie aplikacji.

Takie podejście promuje bardziej proaktywny model bezpieczeństwa – zamiast reagować na wykryte błędy, warto projektować systemy w taki sposób, żeby minimalizować ryzyko architektoniczne już na etapie tworzenia.

Granice zaufania

Jeden z kluczowych wniosków jest taki, że dotychczasowe granice bezpieczeństwa (np. „to jest nasze, to jest zewnętrzne”) już nie działają jak dawniej. W środowiskach, które korzystają z wielu narzędzi CI/CD, rejestrów kontenerów, artefaktów, bibliotek open source i prywatnych zależności – każde ogniwo łańcucha dostaw może zostać wykorzystane jako wektor ataku.

Do tego dochodzi fakt, że tradycyjne podejście, w którym testowano tylko kod aplikacji, coraz słabiej odpowiada na realne zagrożenia. Systemowe ryzyka, wynikające ze złej konfiguracji, braku aktualizacji czy manipulacji artefaktami, zyskują na znaczeniu.

Opinie ekspertów – co mówią liderzy branży

  • Shane Barney, CISO Keeper Security, podkreśla, że nowa lista OWASP to znak, jak bardzo ewoluowało podejście do ryzyka: „Nie chodzi już tylko o łatanie bugów – chodzi o zarządzanie warunkami, które pozwalają tym bugom się pojawiać”.
  • Z drugiej strony Martin Jartelius z Outpost24 zwraca uwagę na to, że próba zebrania tak wielu zagadnień w Top 10 może być niesłuszna  – obawia się, że lista staje się zbyt ogólna.
  • Z kolei Jagadeesh Kunda mówi o „ocenie zadłużenia architektonicznego” – jego zdaniem nowa edycja OWASP traktuje zagrożenia łańcucha jako symptom głębszych problemów w projektowaniu i operowaniu systemem.

Wyzwania przyszłości – AI, LLM i supply chain

Wraz ze wzrostem adoptowania AI i modeli językowych (LLM) ryzyko łańcuchowe staje się coraz bardziej złożone. W kontekście AI mówimy już nie tylko o bibliotekach i kodzie, ale też o modelach pochodzących z zewnętrznych repozytoriów, danych treningowych i narzędziach MLOps – to wszystko tworzy nową płaszczyznę ataku.

Eksperci mówią, że w przyszłości zabezpieczenie łańcucha dostaw będzie wymagało bardzo rygorystycznych mechanizmów: ścisłej kontroli wersji, weryfikacji pochodzenia (provenance), podpisywania artefaktów i stałego monitoringu.

Wnioski i rekomendacje dla zespołów bezpieczeństwa

Z perspektywy cyberbezpieczeństwa i DevSecOps kluczowe kroki, które warto rozważyć po lekturze nowej listy OWASP Top 10 to:

  1. Przegląd i inwentaryzacja zależności – sprawdź, jakie komponenty i narzędzia zewnętrzne wykorzystujesz w swoim łańcuchu dostaw, włączając w to build pipeline, CI/CD, rejestry artefaktów.
  2. Tworzenie SBOM (Software Bill of Materials) – dokumentuj wszystkie zależności w projekcie, nawet te transitive, aby mieć pełny obraz „łańcucha”.
  3. Weryfikacja artefaktów – stosuj podpisy cyfrowe, podpisywanie buildów, weryfikację tożsamości dostawców i artefaktów.
  4. Minimalizacja uprawnień – ogranicz dostęp w pipeline: możliwość wprowadzania zmian w buildach lub dostarczania artefaktów powinny mieć tylko te konta lub usługi, które absolutnie muszą.
  5. Monitorowanie i testowanie runtime – nie wystarczy testować kodu statycznie. Twój pipeline powinien uwzględniać testy integracyjne, skanowanie containerów, analizy binarne i kontrole po wdrożeniu.
  6. Szkolenie zespołów – deweloperzy, inżynierowie DevOps i architekci muszą rozumieć, że supply chain to teraz fundamentalny obszar ryzyka, a nie tylko dodatek do bezpieczeństwa aplikacji.