Definicja CWE
Common Weakness Enumeration (CWE) to utrzymywana przez MITRE, ogólnodostępna lista nazwanych klas błędów konstrukcyjnych w oprogramowaniu i sprzęcie - katalog typowych sposobów, w jakie kod bywa napisany niebezpiecznie, a nie lista konkretnych, wykrytych podatności. Każdy rekord CWE opisuje wzorzec błędu w oderwaniu od jednego produktu: sposób, w jaki dane wejściowe trafiają do zapytania SQL bez separacji, w jaki bufor jest zapisywany poza przydzieloną pamięcią, w jaki sesja jest przekazywana bez walidacji. Gdy taki wzorzec faktycznie wystąpi w wydanym produkcie i jest osiągalny przez atakującego, dostaje własny identyfikator CVE - dopiero wtedy słabość staje się podatnością w konkretnym systemie.
CWE powstało w 2006 roku jako projekt MITRE finansowany przez amerykański Departament Bezpieczeństwa Wewnętrznego (DHS), z myślą o wspólnym języku dla narzędzi SAST/DAST, programów bug bounty i zespołów bezpiecznego kodowania. Zamiast opisywać incydenty, CWE opisuje przyczyny - dzięki temu jeden rekord, na przykład SQL Injection, obejmuje tysiące różnych podatności CVE w setkach produktów, bo wszystkie mają tę samą korzeniową przyczynę.
Jak to działa
Słabość opisana w CWE nie jest jeszcze zagrożeniem - staje się nim dopiero na konkretnej ścieżce od kodu do produkcji. Deweloper popełnia błąd konstrukcyjny (na przykład buduje zapytanie SQL przez konkatenację stringów zamiast parametryzacji), który pasuje do znanej klasy CWE. Jeśli ten fragment kodu trafia do wydanego produktu i jest osiągalny z zewnątrz - a nie tylko teoretycznie istnieje w repozytorium - słabość dostaje numer CVE jako konkretne, zidentyfikowane wystąpienie. Zespół reagowania na incydenty albo dostawca ocenia następnie, jak poważne jest to konkretne wystąpienie, korzystając z CVSS, i na tej podstawie priorytetyzuje łatkę.
Ten łańcuch tłumaczy, dlaczego audytorzy kodu i narzędzia SAST raportują wyniki jako "CWE-89 wykryte w linii 42", a nie jako CVE - narzędzie analizujące kod źródłowy widzi wzorzec, a nie wdrożenie. Dopiero zespół bezpieczeństwa decyduje, czy dany wzorzec jest w danym kontekście osiągalny i wart naprawy przed wydaniem, czy pozostanie wewnętrznym long z backlogu.
Struktura i klasyfikacja
CWE nie jest płaską listą - rekordy są ułożone w hierarchię czterech poziomów abstrakcji, od najbardziej ogólnego do najbardziej szczegółowego:
- Pillar - najwyższy poziom, bardzo szeroka kategoria mechanizmu błędu (np. niewłaściwa neutralizacja danych wejściowych).
- Class - węższa kategoria pojęciowa grupująca pokrewne mechanizmy (np. wstrzyknięcie kodu).
- Base - konkretny, dający się zaimplementować mechanizm błędu, najczęściej używany poziom w praktycznym raportowaniu.
- Variant - najwęższy poziom, opisujący specyficzny wariant błędu w konkretnym kontekście technologicznym.
Przykładowa ścieżka abstrakcji wygląda tak: CWE-707 (Improper Neutralization, poziom Pillar) zawiera w sobie CWE-74 (Injection, poziom Class), które z kolei zawiera CWE-89 (SQL Injection, poziom Base). Ta sama słabość może być zatem opisana szeroko albo precyzyjnie, zależnie od odbiorcy raportu.
Ponad hierarchią leżą jeszcze widoki (views) - alternatywne sposoby grupowania tych samych rekordów pod kątem konkretnego celu. Najczęściej używane to CWE-1000 (Research Concepts), zorientowany na analizę akademicką i relacje przyczynowe między słabościami, oraz CWE-699 (Software Development), zorientowany na praktyczne potrzeby zespołów wytwarzających oprogramowanie. Każdego roku MITRE publikuje też CWE Top 25 - listę najczęściej wykorzystywanych klas słabości w realnych atakach, budowaną na podstawie danych z bazy CVE.
Przykładowe klasy CWE, z którymi najczęściej stykają się zespoły bezpieczeństwa i deweloperskie:
| ID | Nazwa słabości | Poziom | Opis |
|---|---|---|---|
| CWE-79 | Cross-site Scripting (XSS) | Base | Niewłaściwa neutralizacja danych wejściowych w aplikacjach webowych. |
| CWE-89 | SQL Injection | Base | Dynamiczne składanie zapytań SQL bez separacji danych i kodu. |
| CWE-352 | CSRF | Base | Wymuszenie akcji w imieniu uwierzytelnionego użytkownika. |
| CWE-787 | Out-of-bounds Write | Base | Nadpisanie pamięci poza przydzielonym buforem. |
| CWE-22 | Path Traversal | Base | Dostęp do plików spoza zamierzonej ścieżki katalogów. |
| CWE-74 | Injection | Class | Nadrzędna kategoria dla wszystkich form wstrzyknięcia kodu lub danych. |
W szerszym kontekście
Najczęściej mylona trójka pojęć w tej dziedzinie ma jednoznaczne rozgraniczenie: CWE to klasa słabości, CVE to konkretne wystąpienie tej słabości w konkretnym produkcie, a CVSS to ocena krytyczności tego wystąpienia. Te trzy byty nie konkurują ze sobą - opisują tę samą sytuację z trzech różnych perspektyw i razem tworzą pełny obraz ryzyka.
Weźmy przykład. Formularz logowania konkretnej aplikacji w wersji 3.2 składa zapytanie SQL przez konkatenację niesprawdzonego wejścia użytkownika - to jest błąd pasujący do klasy CWE-89 (SQL Injection). Gdy ktoś znajduje ten błąd w wydanej wersji produktu i zgłasza go, słabość dostaje własny numer, na przykład CVE-2024-XXXXX - to jest konkretne wystąpienie, przypięte do jednego produktu i jednej wersji. Zespół reagujący na zgłoszenie ocenia następnie ten konkretny przypadek w skali CVSS, na przykład na 9,8 na 10 - bo błąd jest zdalnie wykorzystywalny bez uwierzytelnienia. Wynik CVSS decyduje o priorytecie łatki, natomiast klasyfikacja CWE-89 mówi zespołowi programistów, gdzie w kodzie szukać podobnych błędów w innych miejscach.
Ten sam mechanizm CWE łączy CVE z szerszym ekosystemem zarządzania ryzykiem: mapowanie do CAPEC (Common Attack Pattern Enumeration and Classification) opisuje, jak atakujący faktycznie wykorzystuje daną klasę słabości w praktyce, a mapowanie do MITRE ATT&CK łączy techniki wykorzystania z konkretnymi taktykami widocznymi w analizach powłamaniowych. Zespoły GRC i audytorzy wykorzystują te powiązania do mapowania słabości na wymagania norm takich jak ISO/IEC 5055 czy NIST SSDF, bez konieczności opisywania każdego incydentu od zera.
Zastosowanie w praktyce
CWE działa jako wspólny słownik na styku kilku ról w organizacji:
- Narzędzia SAST/DAST raportują znalezione podatności z przypisanym identyfikatorem CWE, co pozwala porównywać wyniki różnych skanerów bez ręcznego mapowania kategorii.
- Pentesterzy klasyfikują znaleziska w raportach z audytu według CWE, dzięki czemu klient może śledzić powtarzalność tego samego typu błędu w kolejnych testach.
- Programy bug bounty wymagają od zgłaszających przypisania CWE do zgłoszenia, co ułatwia triage i wycenę nagrody.
- Zarządzanie łańcuchem dostaw - SBOM (Software Bill of Materials) i raporty o komponentach open source odwołują się do CWE przy opisie znanych klas ryzyka w bibliotekach.
- Programy certyfikacyjne takie jak CSSLP czy OSWE budują część materiału egzaminacyjnego wokół znajomości CWE Top 25.
- Bezpieczne wytwarzanie oprogramowania (SDLC) - zespoły DevSecOps wykorzystują CWE jako punkt odniesienia przy szkoleniu programistów z typowych błędów w danym języku czy frameworku.
Dla organizacji dojrzewającej w podejściu do bezpieczeństwa aplikacji CWE jest tańszym punktem wejścia niż śledzenie pojedynczych CVE - jedna naprawiona klasa błędu (na przykład konsekwentne przejście na zapytania parametryzowane) eliminuje całą rodzinę przyszłych podatności, zamiast łatać je pojedynczo po każdym zgłoszeniu.
Najczęstsze nieporozumienia
Nieprawda - to dwa różne poziomy tej samej rzeczywistości. CWE opisuje klasę błędu w oderwaniu od produktu, CVE identyfikuje jedno konkretne wystąpienie tej klasy w jednym produkcie i jednej wersji. Jeden rekord CWE, na przykład CWE-89, odpowiada tysiącom różnych CVE w różnych systemach.
Nieprawda - słabość staje się podatnością dopiero wtedy, gdy jest osiągalna z zewnątrz i faktycznie wykorzystywalna w wydanym produkcie. Kod z błędem konstrukcyjnym leżący w nieużywanej gałęzi funkcji albo za dodatkową warstwą walidacji może formalnie pasować do klasy CWE, a mimo to nigdy nie zostać zgłoszony jako CVE, bo nie da się go dosięgnąć.
Nieprawda - CWE samo w sobie nie zawiera żadnego scoringu ani rankingu ważności dla pojedynczego rekordu. Od oceny krytyczności konkretnego wystąpienia jest CVSS; CWE Top 25 jest rankingiem częstości występowania klas w realnych atakach, a nie oceną ryzyka pojedynczej słabości.
Nieprawda - poziom Pillar jest zbyt ogólny do wskazania konkretnej linii kodu, a poziom Variant bywa zbyt wąski do raportowania trendów. Zespoły audytu i programiści z reguły potrzebują różnych poziomów jednocześnie: kierownictwo śledzi trendy na poziomie Class, programista naprawia błąd na poziomie Base albo Variant.
FAQ
Czym różni się CWE od CVE?
CWE to nazwana klasa błędu konstrukcyjnego, niezależna od konkretnego produktu - opisuje ogólny wzorzec, taki jak SQL Injection czy Path Traversal. CVE to identyfikator jednego konkretnego wystąpienia takiej słabości w jednym, konkretnym produkcie i wersji, nadawany dopiero wtedy, gdy słabość jest osiągalna w wydanym oprogramowaniu. Jeden rekord CWE może odpowiadać tysiącom różnych CVE.
Kto tworzy i utrzymuje CWE?
CWE jest tworzone i utrzymywane przez MITRE Corporation, organizację non-profit finansowaną przez amerykański Departament Bezpieczeństwa Wewnętrznego (DHS). MITRE zarządza też bazą CVE i koordynuje CWE Top 25 - coroczną listę najczęściej wykorzystywanych klas słabości w realnych atakach.
Czy CWE zawiera ocenę krytyczności podatności?
Nie. CWE opisuje wyłącznie rodzaj i mechanizm błędu, bez żadnego scoringu ważności. Oceną krytyczności konkretnego wystąpienia zajmuje się CVSS, a decyzję o priorytecie łatki podejmuje zespół bezpieczeństwa na podstawie tej oceny, nie samej klasyfikacji CWE.
Do czego służą poziomy Pillar, Class, Base i Variant?
To cztery poziomy abstrakcji w hierarchii CWE, od najbardziej ogólnego (Pillar) po najbardziej szczegółowy (Variant). Pozwalają opisać ten sam błąd na różnym poziomie szczegółowości - Pillar i Class ułatwiają analizę trendów i raportowanie zarządcze, Base i Variant wskazują konkretny, dający się naprawić mechanizm w kodzie.
Jak CWE łączy się z testami penetracyjnymi?
Zespoły prowadzące testy penetracyjne klasyfikują znalezione błędy według identyfikatorów CWE w raporcie z audytu. Dzięki wspólnemu słownikowi klient może porównywać wyniki kolejnych testów w czasie i śledzić, czy te same klasy błędów wracają w nowych wersjach aplikacji, zamiast czytać opisowe, niespójne nazwy podatności za każdym razem.
Powiązane pojęcia
- CVE - identyfikator konkretnego wystąpienia słabości CWE w wydanym produkcie.
- CVSS - system oceny krytyczności konkretnego wystąpienia opisanego przez CVE.
- SQL Injection - jedna z najczęstszych klas CWE, przykład Base w hierarchii abstrakcji.
- XSS - klasa CWE związana z niewłaściwą neutralizacją danych wejściowych w aplikacjach webowych.
- CSRF - klasa CWE dotycząca wymuszania akcji w imieniu uwierzytelnionego użytkownika.
- Pentest - proces, w którym klasyfikacja CWE służy do raportowania i porównywania znalezisk.
Testy penetracyjne i audyty
Znajdziesz tu dostawców, którzy raportują znaleziska w klasyfikacji CWE.