VEX: co mówi dokument Vulnerability Exploitability eXchange

Czym jest VEX?

VEX, skrót od Vulnerability Exploitability eXchange, to czytelne maszynowo oświadczenie o tym, czy produkt jest dotknięty określoną znaną podatnością. Dostawca publikuje je, aby użytkownicy produktu wiedzieli, które podatności wymagają działania, a które nie. W większości organizacji ta praca dostawcy należy do zespołu reagowania na incydenty bezpieczeństwa produktów (PSIRT).

Minimum Requirements for VEX agencji CISA (kwiecień 2023) definiują VEX niezależnie od formatu pliku: dokument VEX to kontener na jedno lub więcej oświadczeń VEX, a każde oświadczenie podaje jeden status dla jednej podatności w jednym lub kilku produktach. VEX zaprojektowano do współpracy z SBOM-ami, bazami podatności i biuletynami bezpieczeństwa, ale nie wymaga żadnego z nich.

Dlaczego istnieje VEX: szum SBOM

SBOM wymienia każdy komponent produktu, łącznie z zależnościami przechodnimi. Skaner dopasowuje te komponenty do biuletynów i zgłasza każdą CVE w każdej znalezionej wersji. Wiele z tych znalezisk nie ma zastosowania: podatna funkcja nigdy nie jest wywoływana, opcja buildu wyłącza ją z kompilacji lub konfiguracja produktu blokuje atak. Bez VEX każdy klient musi ustalić to samodzielnie lub zgłosić się do pomocy technicznej dostawcy.

VEX przenosi tę analizę do strony, która może wykonać ją raz, dla wszystkich: do dostawcy. Skaner klienta odczytuje dokument VEX i wycisza znaleziska, które dostawca oznaczył jako niedotyczące produktu.

Cztery statusy VEX

Każde oświadczenie VEX ma dokładnie jeden z czterech statusów:

Status	Znaczenie	Dodatkowo wymagane
not_affected	Nie jest wymagana naprawa ani środek łagodzący. Podatność nie dotyczy wymienionych produktów.	Uzasadnienie lub oświadczenie o wpływie wyjaśniające dlaczego
affected	Podatność dotyczy wymienionych produktów, a autor zaleca działanie.	Oświadczenie o działaniu: co powinni zrobić użytkownicy
fixed	Wymienione wersje produktu zawierają poprawkę.	Nic więcej
under_investigation	Autor bada sprawę i jeszcze nie podjął decyzji.	Nic więcej; status powinien się zmienić

Uzasadnienia VEX dla not_affected

Oświadczenie not_affected musi podawać powód. Wymagania CISA stanowią, że POWINNO używać jednego z pięciu uzasadnień, a jeśli tego nie robi, MUSI zawierać swobodne oświadczenie o wpływie. OpenVEX i CSAF używają tych samych pięciu:

• component_not_present: podatny komponent nie wchodzi w skład produktu.
• vulnerable_code_not_present: komponent wchodzi w skład produktu, ale podatny kod nie, zwykle ze względu na sposób konfiguracji lub buildu.
• vulnerable_code_not_in_execute_path: podatny kod jest obecny, ale produkt nigdy go nie wywołuje.
• vulnerable_code_cannot_be_controlled_by_adversary: kod jest obecny i używany, ale napastnik nie może nim sterować, aby wykorzystać podatność.
• inline_mitigations_already_exist: wbudowane zabezpieczenia, których użytkownicy nie mogą wyłączyć, uniemożliwiają wykorzystanie.

Uzasadnienia różnią się potrzebnymi dowodami. component_not_present wymaga dokładnego zapisu tego, co zawiera produkt. Trzy środkowe wymagają analizy kodu, takiej jak analiza osiągalności lub przegląd ręczny, i to one są najczęściej kwestionowane przez klientów.

Co zawiera oświadczenie VEX

Minimalne wymagania CISA wymieniają następujące elementy:

• Metadane dokumentu: identyfikator dokumentu, wersja rosnąca przy każdej zmianie, autor (osoba lub organizacja, a nie narzędzie) oraz data pierwszego wydania i ostatniej aktualizacji.
• Dane produktu: jeden lub więcej identyfikatorów produktu, najlepiej tych samych, których używa SBOM produktu, na przykład package URL (purl). Oświadczenie może też wskazywać podkomponent zawierający podatność.
• Dane podatności: jeden identyfikator podatności w oświadczeniu, zwykle CVE, oraz opis lub odnośnik do niego.
• Status, wraz z wymaganym uzasadnieniem, oświadczeniem o wpływie lub oświadczeniem o działaniu.
• Metadane oświadczenia: identyfikator, wersja i znaczniki czasu samego oświadczenia.

Przykładowy dokument VEX

Ten dokument OpenVEX mówi, że produkt example-api 3.2.0 zawiera podatną wersję log4j-core, ale nie jest dotknięty przez Log4Shell, ponieważ podatna klasa jest usuwana podczas buildu:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

Produkt i jego podkomponent są identyfikowane przez package URL, więc skaner może dopasować je do komponentów w SBOM produktu. To samo oświadczenie w CycloneDX lub CSAF zawiera te same fakty w innej strukturze.

Formaty VEX: OpenVEX, CycloneDX VEX i CSAF VEX

VEX to zestaw wymagań, a nie format pliku. CISA wymienia trzy formaty, które mogą go przenosić, i nie są one wymienne:

	OpenVEX	CycloneDX VEX	CSAF VEX
Czym jest	Mały format JSON stworzony wyłącznie dla VEX	Sekcja vulnerabilities dokumentu CycloneDX	Profil csaf_vex standardu biuletynów CSAF
Standard	Otwarta specyfikacja, v0.2.0	ECMA-424 (CycloneDX 1.6 i nowsze)	OASIS Standard (CSAF 2.0, 2022)
Statusy	Cztery statusy VEX	Własne stany analizy: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Listy statusów produktów: known_not_affected, known_affected, fixed, under_investigation
Uzasadnienia	Pięć uzasadnień CISA	Dziewięć własnych, takich jak code_not_reachable i requires_configuration	Pięć uzasadnień CISA, jako flagi
Pasuje do zespołów, które	Chcą jak najmniejszego pliku VEX	Już dostarczają SBOM-y CycloneDX	Już publikują biuletyny bezpieczeństwa CSAF
Odczyt w Trivy	Tak	Tak, przy skanach SBOM	Tak
Odczyt w Grype	Tak	Nie wymieniono	Tak

OpenVEX jest najlżejszy: dokument z autorem, znacznikiem czasu, wersją i listą oświadczeń. Jego specyfikacja traktuje VEX jako sekwencję oświadczeń, z których każde nadpisuje poprzednie lub je uzupełnia.

CycloneDX VEX używa tej samej struktury vulnerabilities, której CycloneDX używa do wszystkiego innego, z obiektem analysis zawierającym stan, uzasadnienie, wartości odpowiedzi, takie jak update lub will_not_fix, oraz swobodny opis. Dane VEX mogą znajdować się wewnątrz SBOM lub w osobnym dokumencie CycloneDX, który wskazuje na SBOM za pomocą BOM-Link. Trzeba pamiętać, że jego słownik uzasadnień nie jest słownikiem CISA, więc konwersja do OpenVEX lub CSAF albo z nich wymaga mapowania. Kwestie po stronie SBOM opisuje strona CycloneDX czy SPDX.

CSAF VEX to pełny dokument CSAF z kategorią csaf_vex. Wymaga drzewa produktów, identyfikatora CVE lub innego, uwag oraz dla każdego produktu oświadczenia o wpływie (jeśli nie jest dotknięty) lub naprawy (jeśli jest). Jest cięższy niż OpenVEX, ale pasuje do organizacji, które już dystrybuują biuletyny CSAF przez dostawcę CSAF.

VEX a VDR

Vulnerability Disclosure Report (VDR) wymienia podatności, które dotyczą produktu, wraz z ich analizą i naprawą. NIST SP 800-161 zaleca VDR jako praktykę łańcucha dostaw, a CycloneDX obsługuje oba. Różnicę, jak ujmują to przykłady CycloneDX, można opisać tak:

• VDR mówi, które podatności dotyczą produktu. Może obejmować podatności znalezione w Państwa własnym kodzie, które nigdy nie zostały nigdzie opublikowane.
• VEX to głównie stwierdzenie negatywne: które znane podatności nie dotyczą produktu i dlaczego. Obejmuje tylko znane podatności.

Wielu dostawców publikuje oba: VDR odpowiada na pytanie „co muszę naprawić”, a VEX na pytanie „co mogę zignorować”.

Jak skanery korzystają z VEX

Dokument VEX oszczędza pracę tylko wtedy, gdy czytają go narzędzia klienta. Robią to dwa szeroko stosowane skanery open source:

• Trivy przyjmuje VEX przez swoją opcję --vex (oznaczoną jako eksperymentalna) z lokalnego pliku, repozytorium VEX, poświadczenia OCI lub odwołania w SBOM. Odczytuje OpenVEX, CycloneDX VEX przy skanach SBOM oraz CSAF VEX i przestaje zgłaszać podatności oznaczone jako not_affected.
• Grype przyjmuje OpenVEX i CSAF VEX przez --vex. Przenosi dopasowania not_affected i fixed na listę ignorowanych, wyświetlaną przez --show-suppressed, i opcjonalnie może dodawać do wyników oświadczenia affected i under_investigation.

Dopasowanie zależy od identyfikatorów. Jeśli VEX nazywa produkt innym identyfikatorem niż SBOM, skaner nie może ich połączyć i znalezisko pozostaje.

Kto publikuje VEX

VEX pochodzi zwykle od dostawcy: producenta oprogramowania, dystrybucji open source lub producenta urządzenia, który dostarcza produkt. U dostawcy jest to zadanie PSIRT, część tego samego cyklu życia zarządzania podatnościami, który daje biuletyny i poprawki. Red Hat na przykład publikuje dokumenty CSAF VEX w osobnym katalogu swojego kanału CSAF, obok biuletynów. Czym na co dzień zajmują się inżynierowie PSIRT, opisuje strona rola PSIRT.

Klienci także piszą VEX na własny użytek, zapisując decyzje z triage dotyczące produktu dostawcy, aby ich skaner przestał zgłaszać te znaleziska. Regulacje, takie jak unijny Cyber Resilience Act, wymagają od producentów obsługi podatności w dostarczanych komponentach, a VEX to jeden ze sposobów poinformowania użytkowników, które z nich mają zastosowanie.

Utrzymywanie aktualności VEX

• Statusy się zmieniają. Oświadczenie zwykle zaczyna od under_investigation i kończy jako not_affected albo jako affected, a potem fixed. Należy publikować każdą zmianę; CISA wymaga, aby wersja rosła za każdym razem.
• Nowe wydania wymagają nowych oświadczeń. Werdykt not_affected dla 3.2.0 nic nie mówi o 3.3.0. Należy sprawdzić go ponownie przy każdej zmianie komponentu, jego wersji lub konfiguracji buildu.
• Trzymać VEX osobno od SBOM. SBOM opisuje wydanie i pozostaje niezmienny. VEX zmienia się dalej po wydaniu, więc opublikowanie go jako osobnego dokumentu pozwala uniknąć ponownego wydawania SBOM-ów.
• Publikować tam, gdzie szukają narzędzia. Obok SBOM, jako poświadczenie na obrazie kontenera lub w kanale biuletynów, i wskazać to miejsce w polityce ujawniania. Zob. skoordynowane ujawnianie podatności.

Ograniczenia VEX

• To twierdzenie, a nie dowód. Oświadczenie not_affected to ocena autora. CISA zaleca kryptograficzne powiązanie tożsamości autora z dokumentem, ale większość odbiorców nadal ufa VEX, ponieważ ufa dostawcy.
• Brak oświadczenia nic nie znaczy. VEX nie zakłada żadnego statusu domyślnego. Podatność bez oświadczenia jest nieznana, a nie niedotycząca produktu.
• Formaty nie odpowiadają sobie jeden do jednego. CycloneDX używa innych stanów i uzasadnień niż OpenVEX i CSAF, więc przy konwersji giną szczegóły.
• Jest tak dobry jak inwentarz. Stwierdzenie, że komponentu nie ma, wymaga dokładnej wiedzy o tym, co zawiera produkt, łącznie z zależnościami przechodnimi i wszystkim, co build pobrał poza menedżerem pakietów.

VEX zaczyna się od dokładnego SBOM

Każde oświadczenie VEX wskazuje na komponenty, a najłatwiejsze do obrony uzasadnienie, component_not_present, jest prawdziwe tylko wtedy, gdy inwentarz jest kompletny. SBOM wygenerowany przez skanowanie lockfile po fakcie może wymieniać zależności deweloperskie, które nigdy nie są dostarczane, i pomijać pakiety pobrane przez build w inny sposób.

CRACI uruchamia buildy GitHub Actions na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache i zależnościami, których nie wymienia żaden lockfile. Każdy SBOM ma stan kompletności i jest eksportowany w CycloneDX lub SPDX. Monitorowane SBOM-y są stale ponownie oceniane, historia buildów pokazuje, które wcześniejsze buildy zawierały podatną zależność, a CRACI obsługuje VEX. Zob. generowanie SBOM oraz śledzenie podatności.

VEX: najczęściej zadawane pytania

Co oznacza skrót VEX?

VEX oznacza Vulnerability Exploitability eXchange. To czytelne maszynowo oświadczenie o tym, czy produkt jest dotknięty określoną znaną podatnością, publikowane po to, aby użytkownicy wiedzieli, które zgłoszone podatności wymagają działania.

Czym SBOM różni się od VEX?

SBOM wymienia komponenty produktu. VEX mówi, dla danej podatności, czy produkt jest nią dotknięty. SBOM rzadko zmienia się po wydaniu; oświadczenia VEX zmieniają się w miarę badania i naprawiania przez dostawcę. Dlatego VEX publikuje się zwykle jako osobny dokument odwołujący się do produktu, a nie wbudowany w SBOM.

Jakie są cztery statusy VEX?

not_affected, affected, fixed i under_investigation. Oświadczenie not_affected wymaga uzasadnienia lub oświadczenia o wpływie, a oświadczenie affected wymaga oświadczenia o działaniu, które mówi, co powinni zrobić użytkownicy.

Jakiego formatu VEX należy użyć?

Tego, który odczytują Państwa odbiorcy i narzędzia. OpenVEX jest najmniejszy i działa z Trivy i Grype. CycloneDX VEX pasuje do zespołów, które już dostarczają SBOM-y CycloneDX. CSAF VEX pasuje do organizacji, które już publikują biuletyny bezpieczeństwa CSAF, co jest częste w oprogramowaniu przemysłowym i korporacyjnym. Wielu dostawców ostatecznie konwertuje między nimi.

Czy VEX to to samo co biuletyn bezpieczeństwa?

Nie. Biuletyn bezpieczeństwa wyjaśnia podatność, kogo dotyczy i jak ją naprawić, głównie dla ludzi. VEX to wąski, czytelny maszynowo status dla produktu i podatności, głównie dla narzędzi. Często występują razem: standard CSAF ma zarówno profil biuletynu bezpieczeństwa, jak i profil VEX.

Kto pisze dokumenty VEX?

Zwykle dostawca produktu, często jego zespół reagowania na incydenty bezpieczeństwa produktów (PSIRT), ponieważ wie, jak produkt jest zbudowany i skonfigurowany. Minimalne wymagania CISA dopuszczają też autorów zewnętrznych, a każdy dokument musi wskazywać autora.

Czy skanery podatności odczytują VEX?

Kilka tak. Trivy przyjmuje OpenVEX, CycloneDX VEX i CSAF VEX przez opcję --vex i usuwa znaleziska oznaczone jako not_affected. Grype przyjmuje OpenVEX i CSAF VEX przez --vex i przenosi znaleziska not_affected i fixed na listę ignorowanych.