SBOM i VEX: komponenty i wpływ podatności
Sytance · Zaktualizowano
SBOM identyfikuje komponenty oprogramowania w produkcie. Vulnerability Exploitability eXchange (VEX) przekazuje informację, czy dana podatność wpływa na ten produkt. Ocena zależy od wersji produktu, jego konfiguracji i sposobu wykorzystania komponentu.
Wykaz komponentów, dopasowanie i wpływ
Wykaz odnotowuje, czy komponent jest obecny. Dopasowanie podatności wskazuje, że komunikat o podatności wymienia dany komponent lub jego wersję. Analiza wpływu sprawdza następnie, czy podatny kod występuje i może zostać wykorzystany w rzeczywistej kompilacji i podczas użytkowania produktu.
CycloneDX wykorzystuje VEX do przekazywania oceny dotyczącej konkretnego produktu. Na przykład komponent może być obecny, mimo że opcjonalna podatna funkcja została wykluczona podczas kompilacji. Uzasadnienie takiego rozróżnienia wymaga informacji i analizy dotyczących kompilacji.
Cztery statusy OpenVEX
OpenVEX definiuje cztery statusy. Każdy status dotyczy wersji produktu i podatności wskazanych w oświadczeniu.
| Status OpenVEX | Znaczenie |
|---|---|
| under_investigation | Wpływ jest nadal oceniany |
| affected | Wskazany produkt jest podatny |
| fixed | Wskazana wersja zawiera poprawkę |
| not_affected | Wskazany produkt nie jest podatny |
Opcjonalny dekoder w bramie
Rozważmy fikcyjną bramę zawierającą bibliotekę parsera z opcjonalnym dekoderem. Załóżmy, że podatność dotyczy tego dekodera. Ocena rozpoczyna się od ustalenia, która kompilacja biblioteki znajduje się w dostarczonym obrazie oraz czy dekoder został w niej skompilowany.
Jeśli ustawienia kompilacji i analiza pliku binarnego potwierdzają brak podatnego dekodera, mogą uzasadnić oświadczenie not_affected z przyczyną vulnerable_code_not_present. Oświadczenie dotyczy tej kompilacji.
Jeśli kod jest obecny, ale jego wykonanie pozostaje niejasne, ocenę należy utrzymać w statusie under_investigation i sprawdzić punkty wejścia oraz ścieżki wykonania. Jeśli produkt jest podatny, a późniejsze wydanie zawiera poprawkę, wcześniejsze wydanie nadal pozostaje podatne; dla późniejszego wydania należy sporządzić osobne oświadczenie.
Przyczyny statusu not-affected
OpenVEX wymaga, aby oświadczenie not_affected zawierało uzasadnienie lub oświadczenie o wpływie. Uzasadnienia w formacie maszynowym rozróżniają brak komponentów, brak podatnego kodu, kod poza ścieżką wykonania, ograniczenia kontroli napastnika i wbudowane środki zaradcze.
Każda przyczyna wiąże się z innymi warunkami. Ograniczenie sieci nie usuwa podatnego kodu. W przypadku wbudowanego środka zaradczego OpenVEX określa zabezpieczenie, które zapobiega wykorzystaniu podatności i którego użytkownik nie może wyłączyć ani ponownie skonfigurować.
W przypadku wniosku dotyczącego ścieżki kodu należy wskazać podatną funkcję, sprawdzone ścieżki i ograniczenia konfiguracji. Ocenę należy zweryfikować ponownie, gdy te warunki się zmienią. Jeśli wniosek zależy od ustawienia kontrolowanego przez klienta, trzeba jasno poinformować o tej zależności.
Korzystanie z oświadczenia VEX dostawcy
Oświadczenie VEX dostawcy może pomóc filtrować alerty lub zmienić ich priorytet. Przed jego użyciem należy potwierdzić, że źródło jest zaufane, a wersja produktu się zgadza. Sprawdzić czas publikacji, rewizje, objętą konfigurację i zalecane działania.
Jeśli oświadczenie zaufanego dostawcy jest sprzeczne z własną analizą, należy zachować oba zapisy i wyjaśnić rozbieżność. Ogólne oświadczenie dotyczące rodziny produktów może nie obejmować niestandardowej kompilacji z innymi komponentami lub opcjami.
SBOM pozostaje przydatny po opublikowaniu oświadczenia VEX. Nowe komunikaty o podatnościach mogą zmienić zakres wymaganych badań, a zmieniony produkt może unieważnić wcześniejszy wniosek. Należy powiązać aktualizacje wykazu i oceny wpływu, zachowując odrębną historię każdego z nich.