Wprowadzenie do problemu / definicja zmian
OWASP opublikował wersję Release Candidate listy Top 10:2025, która porządkuje najpoważniejsze ryzyka bezpieczeństwa aplikacji webowych. Nowa edycja przynosi dwie nowe kategorie oraz konsolidację (SSRF wchodzi do Broken Access Control). Zestawienie pozostaje „data-informed”, ale nie „data-driven”—autorzy łączą analizę danych z ankietą społeczności, aby wychwycić ryzyka słabo mierzalne narzędziami.
W skrócie
- Nowe kategorie:
- A03: Software Supply Chain Failures – rozwinięcie dawnego „Vulnerable and Outdated Components” o pełny łańcuch dostaw: zależności, buildy, dystrybucja.
- A10: Mishandling of Exceptional Conditions – błędne obchodzenie się ze stanami wyjątkowymi (np. „fail open”, ujawnianie szczegółów błędów, brak rollbacków transakcji).
- Konsolidacja: SSRF wchodzi do A01: Broken Access Control.
- Awans: Security Misconfiguration rośnie z #5 (2021) na #2 (2025 RC1).
Kontekst / historia / powiązania
Lista Top 10 to punkt odniesienia dla zespołów AppSec od lat. W 2021 r. największym trzęsieniem ziemi było wyniesienie „Broken Access Control” na #1 oraz wydzielenie „Insecure Design”. W 2025 RC1 zespół OWASP:
- zwiększa liczbę analizowanych CWE do 589 (vs ~400 w 2021),
- kładzie nacisk na przyczynę, nie symptom (root cause),
- korzysta z danych o CVEs/CVSS oraz z ankiety społeczności dla kategorii słabo testowalnych na skalę.
Analiza techniczna / szczegóły
A03: Software Supply Chain Failures (nowa/rozszerzona)
To rozszerzenie dawnego „Vulnerable and Outdated Components” (A06:2021), ale obejmujące cały ekosystem: zależności bezpośrednie i transytywne, narzędzia buildowe, rejestry artefaktów, łańcuch dystrybucji i podpisywanie. Mimo że kategoria ma niewiele CVE (problem z testowalnością), w ankiecie społeczności była najwyżej oceniana; OWASP podkreśla też wysokie średnie wyniki exploit/impact w CVE. Przykłady: SolarWinds czy kampanie uderzające w marketplace’y rozszerzeń.
Ryzyka techniczne (przykłady CWE):
- CWE-1104: użycie nieutrzymywanych komponentów,
- CWE-1395: zależność od podatnego komponentu,
- CWE-1329: komponent nieaktualizowalny.
A10: Mishandling of Exceptional Conditions (nowa)
Nowa kategoria obejmuje 24 CWE związane z obsługą wyjątków, błędami logiki, „fail open”, wyciekami informacji z komunikatów błędów, brakiem reakcji na stany nadzwyczajne czy niejednolitą obsługą wyjątków. To obszar wcześniej traktowany czasem jako „code quality”, ale jego wpływ bezpieczeństwa jest realny: od DoS i eskalacji uprawnień po naruszenia integralności i poufności.
Ryzyka techniczne (przykłady CWE):
- CWE-209/CWE-550: komunikaty błędów ujawniające dane wrażliwe,
- CWE-636: brak „failing closed”,
- CWE-703/754/755: niewłaściwe sprawdzanie/obsługa warunków wyjątkowych.
Inne przetasowania
- A01 Broken Access Control pozostaje #1 i wchłania SSRF.
- A02 Security Misconfiguration rośnie do #2 (coraz więcej zachowań aplikacji konfiguruje się, a nie koduje).
- A04 Cryptographic Failures oraz A05 Injection spadają o dwa miejsca (na #4 i #5).
- Nazwy doprecyzowano: np. A09 Logging & Alerting Failures (wcześniej „Security Logging and Monitoring Failures”).
Praktyczne konsekwencje / ryzyko
- Łańcuch dostaw: atak na „narzędzia i metry” (IDE, pluginy, pipeline, rejestry, dependency resolvery) często omija klasyczne testy DAST/SAST. Potrzebna jest ciągła widoczność SBOM, kontrola źródeł i podpisy kryptograficzne artefaktów.
- Stany wyjątkowe: błahe z pozoru wyjątki (np. brak parametru) mogą stać się prymitywem eksploitacyjnym (leaki w komunikatach, race condition, brak rollbacku transakcji → fraud). W mikrousługach kaskadowe wyjątki kończą się często DoS lub rozjechanym stanem.
Rekomendacje operacyjne / co zrobić teraz
1) Supply chain security w praktyce
Inwentaryzacja i SBOM:
# SBOM (CycloneDX) – syft
syft dir:./ -o cyclonedx-json > sbom.json
# SCA – grype (mapowanie do CVE)
grype sbom:sbom.json --fail-on highWeryfikacja artefaktów (Sigstore cosign):
# Podpisanie obrazu
cosign sign --key cosign.key registry.example.com/app:1.2.3
# Weryfikacja podpisu
cosign verify --key cosign.pub registry.example.com/app:1.2.3Kontrola źródeł i wersji:
- Zezwalaj tylko na oficjalne rejestry i podpisane paczki (npm, PyPI, Maven, NuGet).
- W CI/CD wymuś pinning wersji i bloker „latest”.
- Regularnie aktualizuj IDE/plug-iny, runner’y, builder’y; traktuj je jak element produkcji.
Narzędzia OWASP, które warto włączyć:
- Dependency-Check / Dependency-Track, CycloneDX, ASVS. (Wprost rekomendowane na stronie A03).
2) Obsługa wyjątków „fail closed” + minimalizacja wycieków
Zasady:
- Zawsze rollback transakcji przy błędach (nie próbuj „naprawiać w locie”).
- Globalny handler wyjątków + spójna polityka komunikatów (przyjaźnie dla użytkownika, bez danych technicznych).
- Logowanie + alerting (SRE/SEC) – powtarzalne błędy mogą sygnalizować atak (brute force, fuzzing).
Przykład (Java/Spring) – bezpieczny handler i rollback:
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(Exception.class)
public ResponseEntity<ApiError> handleAny(Exception ex, WebRequest req) {
// Log szczegółowy trafia do SIEM, nie do użytkownika
MDC.put("correlationId", UUID.randomUUID().toString());
log.error("Unhandled exception", ex);
// Użytkownik dostaje neutralny komunikat
ApiError safe = new ApiError("Wystąpił błąd. Spróbuj ponownie później.");
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(safe);
}
}
@Service
public class TransferService {
@Transactional
public void transferMoney(...) {
// jeśli cokolwiek rzuci wyjątek -> @Transactional zapewni rollback (fail closed)
// ...
}
}Przykład (Node.js/Express) – brak wycieków w błędach:
app.use((err, req, res, next) => {
req.log?.error({ err }, "Unhandled error"); // szczegóły do logów
res.status(500).json({ message: "Wystąpił błąd. Spróbuj ponownie." }); // bez stacktrace
});Twarde limity i back-pressure (zapobieganie stanom wyjątkowym):
- Rate limiting (np. NGINX, Envoy) i limity zasobów (CPU, RAM, otwarte pliki).
- Circuit breaker/time-out/retry-with-jitter między usługami.
3) Misconfiguration hygiene
- Kontrola konfiguracji jako kodu (GitOps, PR-y + review).
- Skany konfiguracji (kube-bench, kube-lint, tfsec).
- Separacja obowiązków w CI/CD; nikt nie powinien samodzielnie przepchnąć kodu do produkcji.
Różnice / porównania z innymi przypadkami
- Względem 2021: z kategorii „komponenty podatne/przestarzałe” wyrósł pełny łańcuch dostaw (A03), co odzwierciedla ataki na ekosystem deweloperski i narzędzia (marketplace’y, rejestry, buildy). SSRF przestało być samotną wyspą—logicznie trafiło do Broken Access Control (#1). Security Misconfiguration rośnie, co dobrze koresponduje z IaC/K8s i „konfiguracją-jako-logiką”.
Podsumowanie / kluczowe wnioski
- Myśl łańcuchowo: widoczność SBOM, podpisy, polityka źródeł, hardening pipeline’ów są równie ważne jak testy kodu.
- Przewiduj wyjątkowe: ujednolicone, bezpieczne wzorce obsługi błędów, zasada „fail closed”, realny alerting i rollback.
- Konfiguracja to kod: traktuj ją tak samo rygorystycznie (review, testy, skany).
- Aktualizuj program szkoleniowy AppSec o nowe kategorie i mapowanie CWE/ATT&CK; przestaw wymagania na root cause zamiast pojedynczych symptomów.
Źródła / bibliografia
- SecurityWeek: „Two New Web Application Risk Categories Added to OWASP Top 10”, 10 listopada 2025. (SecurityWeek)
- OWASP Top 10:2025 RC1 – Introduction / What’s changed / Methodology. (OWASP)
- OWASP Top 10:2025 RC1 – A03 Software Supply Chain Failures (opis, CWE, narzędzia). (OWASP)
- OWASP Top 10:2025 RC1 – A10 Mishandling of Exceptional Conditions (opis, CWE, zalecenia). (OWASP)
