VEX: mitä Vulnerability Exploitability eXchange -dokumentti kertoo

Mikä VEX on?

VEX, lyhenne sanoista Vulnerability Exploitability eXchange, on koneluettava lausunto siitä, koskeeko tietty tunnettu haavoittuvuus tuotetta. Toimittaja julkaisee sen, jotta tuotteen käyttäjät tietävät, mitkä haavoittuvuudet vaativat toimenpiteitä ja mitkä eivät. Useimmissa organisaatioissa tämä toimittajan työ kuuluu tuoteturvallisuuden poikkeamiin reagoivalle tiimille (PSIRT).

CISA:n Minimum Requirements for VEX (huhtikuu 2023) määrittelee sen tiedostomuodosta riippumatta: VEX-dokumentti on säiliö yhdelle tai useammalle VEX-lausunnolle, ja kukin lausunto antaa yhden tilan yhdelle haavoittuvuudelle yhdessä tai useammassa tuotteessa. VEX on suunniteltu toimimaan SBOM:ien, haavoittuvuustietokantojen ja tietoturvatiedotteiden kanssa, mutta se ei tarvitse mitään niistä.

Miksi VEX on olemassa: SBOM-kohina

SBOM luettelee tuotteen jokaisen komponentin, myös transitiiviset riippuvuudet. Skanneri vertaa näitä komponentteja tietoturvatiedotteisiin ja raportoi jokaisen CVE:n jokaisesta löytämästään versiosta. Monet näistä löydöksistä eivät koske tuotetta: haavoittuvaa funktiota ei koskaan kutsuta, build-asetus jättää sen pois käännöksestä tai tuotteen konfiguraatio estää hyökkäyksen. Ilman VEX:iä jokaisen asiakkaan on selvitettävä tämä itse tai avattava tukipyyntö toimittajalle.

VEX siirtää analyysin osapuolelle, joka voi tehdä sen kerran kaikkien puolesta: toimittajalle. Asiakkaan skanneri lukee VEX-dokumentin ja piilottaa löydökset, jotka toimittaja on merkinnyt tuotetta koskemattomiksi.

VEX on yksi monista keinoista. Miten vähentää haavoittuvuuskohinaa asettaa ne järjestykseen alkaen inventaariosta, joka vastaa sitä, mitä toimitat.

VEX:n neljä tilaa

Jokaisella VEX-lausunnolla on täsmälleen yksi neljästä tilasta:

Tila	Merkitys	Vaaditaan lisäksi
not_affected	Korjausta tai lieventämistä ei tarvita. Haavoittuvuus ei koske lueteltuja tuotteita.	Perustelu tai vaikutuslausunto, joka selittää miksi
affected	Haavoittuvuus koskee lueteltuja tuotteita, ja laatija suosittelee toimenpiteitä.	Toimenpidelausunto: mitä käyttäjien pitäisi tehdä
fixed	Luetelluissa tuoteversioissa on korjaus.	Ei mitään lisää
under_investigation	Laatija tutkii asiaa eikä ole vielä tehnyt päätöstä.	Ei mitään lisää; odotetaan muuttuvan

VEX-perustelut not_affected-tilalle

not_affected-lausunnon on kerrottava syy. CISA:n vaatimusten mukaan sen PITÄISI (SHOULD) käyttää yhtä viidestä perustelusta, ja sen ON PAKKO (MUST) antaa vapaamuotoinen vaikutuslausunto, jos se ei käytä. OpenVEX ja CSAF käyttävät samoja viittä:

• component_not_present: haavoittuva komponentti ei sisälly tuotteeseen.
• vulnerable_code_not_present: komponentti sisältyy tuotteeseen, mutta haavoittuva koodi ei, tyypillisesti sen vuoksi, miten se on konfiguroitu tai buildattu.
• vulnerable_code_not_in_execute_path: haavoittuva koodi on mukana, mutta tuote ei koskaan kutsu sitä.
• vulnerable_code_cannot_be_controlled_by_adversary: koodi on mukana ja käytössä, mutta hyökkääjä ei voi ohjata sitä haavoittuvuuden hyödyntämiseksi.
• inline_mitigations_already_exist: sisäänrakennetut suojaukset, joita käyttäjät eivät voi poistaa käytöstä, estävät hyödyntämisen.

Perustelut eroavat siinä, millaista näyttöä ne vaativat. component_not_present edellyttää tarkkaa tallennetta siitä, mitä tuote sisältää. Kolme keskimmäistä edellyttävät koodianalyysiä, kuten reachability-analyysiä tai manuaalista katselmointia, ja niitä asiakkaat kyseenalaistavat useimmin.

Mitä VEX-lausunto sisältää

CISA:n vähimmäisvaatimukset luettelevat nämä elementit:

• Dokumentin metatiedot: dokumentin tunniste, versio, joka kasvaa jokaisen muutoksen myötä, laatija (henkilö tai organisaatio, ei työkalu) sekä ensimmäinen julkaisuajankohta ja viimeisin päivitys.
• Tuotetiedot: yksi tai useampi tuotetunniste, mieluiten samat tunnisteet, joita tuotteen SBOM käyttää, kuten package URL (purl). Lausunto voi myös nimetä alikomponentin, jossa haavoittuvuus on.
• Haavoittuvuustiedot: yksi haavoittuvuustunniste lausuntoa kohden, yleensä CVE, sekä kuvaus tai linkki kuvaukseen.
• Tila sekä sen edellyttämä perustelu, vaikutuslausunto tai toimenpidelausunto.
• Lausunnon metatiedot: tunniste, versio ja aikaleimat itse lausunnolle.

Esimerkki VEX-dokumentista

Tämä OpenVEX-dokumentti kertoo, että tuote example-api 3.2.0 sisältää haavoittuvan log4j-core-version, mutta Log4Shell ei koske sitä, koska haavoittuva luokka poistetaan buildin aikana:

{
  "@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."
    }
  ]
}

Tuote ja sen alikomponentti tunnistetaan package URL -tunnisteilla, joten skanneri voi verrata niitä tuotteen SBOM:n komponentteihin. Sama lausunto CycloneDX- tai CSAF-muodossa sisältää samat tiedot eri rakenteessa.

VEX-formaatit: OpenVEX, CycloneDX VEX ja CSAF VEX

VEX on joukko vaatimuksia, ei tiedostomuoto. CISA nimeää kolme formaattia, jotka voivat välittää sen, eivätkä ne ole keskenään vaihdettavissa:

	OpenVEX	CycloneDX VEX	CSAF VEX
Mikä se on	Pieni, pelkästään VEX:iä varten tehty JSON-formaatti	CycloneDX-dokumentin vulnerabilities-osio	CSAF-tiedotestandardin csaf_vex-profiili
Standardi	Avoin spesifikaatio, v0.2.0	ECMA-424 (CycloneDX 1.6 ja uudemmat)	OASIS-standardi (CSAF 2.0, 2022)
Tilat	VEX:n neljä tilaa	Omat analyysitilansa: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Tuotteiden tilalistat: known_not_affected, known_affected, fixed, under_investigation
Perustelut	CISA:n viisi perustelua	Yhdeksän omaa, kuten code_not_reachable ja requires_configuration	CISA:n viisi perustelua lippuina
Sopii tiimeille, jotka	Haluavat mahdollisimman pienen VEX-tiedoston	Toimittavat jo CycloneDX-muotoisia SBOM:eja	Julkaisevat jo CSAF-tietoturvatiedotteita
Trivy lukee	Kyllä	Kyllä, SBOM-skannauksissa	Kyllä
Grype lukee	Kyllä	Ei mainittu	Kyllä

OpenVEX on kevein: dokumentti, jossa on laatija, aikaleima, versio ja lista lausuntoja. Sen spesifikaatio käsittelee VEX:iä lausuntojen sarjana, jossa kukin lausunto korvaa aiemmat tai täydentää niitä.

CycloneDX VEX käyttää samaa vulnerabilities-rakennetta, jota CycloneDX käyttää kaikkeen muuhunkin, ja analysis-objekti sisältää tilan, perustelun, vastausarvot, kuten update tai will_not_fix, sekä vapaamuotoisen kuvauksen. VEX-tiedot voivat olla SBOM:n sisällä tai erillisessä CycloneDX-dokumentissa, joka viittaa SBOM:iin BOM-Linkillä. Huomaa, että sen perustelusanasto ei ole CISA:n, joten muuntaminen OpenVEX- tai CSAF-muotoon tai niistä vaatii vastaavuustaulukon. SBOM-puolesta katso CycloneDX vs. SPDX.

CSAF VEX on täysi CSAF-dokumentti, jonka kategoria on csaf_vex. Se edellyttää tuotepuuta, CVE- tai muuta tunnistetta, huomautuksia sekä jokaiselle tuotteelle vaikutuslausuntoa (jos haavoittuvuus ei koske tuotetta) tai korjausta (jos koskee). Se on raskaampi kuin OpenVEX, mutta sopii organisaatioille, jotka jo jakavat CSAF-tiedotteita CSAF-palveluntarjoajan kautta.

VEX vs. VDR

Vulnerability Disclosure Report (VDR) luettelee haavoittuvuudet, jotka koskevat tuotetta, analyyseineen ja korjauksineen. NIST SP 800-161 suosittelee VDR:iä toimitusketjun käytäntönä, ja CycloneDX tukee molempia. Ero CycloneDX:n esimerkkien mukaan:

• VDR kertoo, mitkä haavoittuvuudet koskevat tuotetta. Se voi kattaa myös omasta koodista löytyneitä haavoittuvuuksia, joita ei ole koskaan julkaistu muualla.
• VEX on pääasiassa kielteinen lausunto: mitkä tunnetut haavoittuvuudet eivät koske tuotetta ja miksi. Se kattaa vain tunnetut haavoittuvuudet.

Monet toimittajat julkaisevat molemmat: VDR vastaa kysymykseen "mitä minun pitää korjata", VEX kysymykseen "minkä voin jättää huomiotta".

Miten skannerit käyttävät VEX:iä

VEX-dokumentti säästää työtä vain, jos asiakkaan työkalut lukevat sen. Kaksi laajasti käytettyä avoimen lähdekoodin skanneria lukee:

• Trivy ottaa VEX:n vastaan --vex-valitsimellaan (merkitty kokeelliseksi) paikallisesta tiedostosta, VEX-repositoriosta, OCI-attestaatiosta tai SBOM:ssa olevasta viittauksesta. Se lukee OpenVEX:iä, CycloneDX VEX:iä SBOM-skannauksissa ja CSAF VEX:iä, ja lopettaa not_affected-merkittyjen haavoittuvuuksien raportoinnin.
• Grype ottaa OpenVEX:n ja CSAF VEX:n vastaan valitsimella --vex. Se siirtää not_affected- ja fixed-osumat ohitettujen listalle, joka näytetään valitsimella --show-suppressed, ja voi valinnaisesti lisätä affected- ja under_investigation-lausunnot tuloksiin.

Vertailu riippuu tunnisteista. Jos VEX nimeää tuotteen eri tunnisteella kuin SBOM, skanneri ei pysty yhdistämään niitä ja löydös jää voimaan.

Kuka julkaisee VEX:iä

VEX tulee yleensä toimittajalta: ohjelmistotoimittajalta, avoimen lähdekoodin jakelulta tai laitevalmistajalta, joka toimittaa tuotteen. Toimittajan sisällä se on PSIRT-tehtävä, osa samaa haavoittuvuuksien hallinnan elinkaarta, joka tuottaa tietoturvatiedotteet ja korjaukset. Esimerkiksi Red Hat julkaisee CSAF VEX -dokumentteja CSAF-syötteensä omassa hakemistossa tietoturvatiedotteidensa rinnalla. PSIRT-insinöörien arjesta kerrotaan sivulla PSIRT-rooli.

Myös asiakkaat kirjoittavat VEX:iä omaan käyttöönsä ja kirjaavat triage-päätöksensä (luokittelu ja priorisointi) toimittajan tuotteesta, jotta heidän skannerinsa lakkaa nostamasta niitä esiin. Sääntely, kuten EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA), edellyttää valmistajilta toimittamiensa komponenttien haavoittuvuuksien käsittelyä, ja VEX on yksi tapa kertoa käyttäjille, mitkä niistä koskevat tuotetta.

VEX:n pitäminen ajan tasalla

• Tilat muuttuvat. Lausunto alkaa tyypillisesti tilasta under_investigation ja päättyy tilaan not_affected, tai tilaan affected ja sitten fixed. Julkaise jokainen muutos; CISA edellyttää, että versio kasvaa joka kerta.
• Uudet julkaisut tarvitsevat uudet lausunnot. Version 3.2.0 not_affected-arvio ei kerro mitään versiosta 3.3.0. Tarkista se uudelleen aina, kun komponentti, sen versio tai build-konfiguraatio muuttuu.
• Pidä VEX erillään SBOM:sta. SBOM kuvaa julkaisun ja pysyy muuttumattomana. VEX muuttuu edelleen julkaisun jälkeen, joten sen julkaiseminen omana dokumenttinaan säästää SBOM:ien uudelleenjulkaisulta.
• Julkaise siellä, mistä työkalut etsivät. SBOM:n vieressä, attestaationa konttikuvassa tai tiedotesyötteessäsi, ja kerro julkistamiskäytännössäsi, missä se on. Katso koordinoitu haavoittuvuuksien julkistaminen.

VEX:n rajoitukset

• Se on väite, ei todiste. not_affected-lausunto on laatijan arvio. CISA suosittelee sitomaan laatijan identiteetin dokumenttiin kryptografisesti, mutta useimmat käyttäjät luottavat VEX:iin edelleen siksi, että he luottavat toimittajaan.
• Hiljaisuus ei tarkoita mitään. VEX ei oleta oletustilaa. Haavoittuvuus, josta ei ole lausuntoa, on tuntematon, ei tuotetta koskematon.
• Formaatit eivät vastaa toisiaan yksi yhteen. CycloneDX käyttää eri tiloja ja perusteluja kuin OpenVEX ja CSAF, joten muunnoksissa yksityiskohtia katoaa.
• Se on vain niin hyvä kuin inventaario. Väite siitä, ettei komponenttia ole mukana, edellyttää tarkkaa tietoa siitä, mitä tuote sisältää, mukaan lukien transitiiviset riippuvuudet ja kaikki, mitä buildi latasi paketinhallinnan ohi.

VEX alkaa tarkasta SBOM:sta

Jokainen VEX-lausunto osoittaa komponentteihin, ja helpoimmin puolustettava perustelu, component_not_present, pitää paikkansa vain, jos inventaario on kattava. Lukitustiedostoja jälkikäteen skannaamalla generoitu SBOM voi luetella kehitysriippuvuuksia, joita ei koskaan toimiteta, ja jättää pois paketit, jotka buildi haki jollain muulla tavalla.

CRACI ajaa GitHub Actions -buildit omilla runnereillaan ja tallentaa paketit, jotka kukin jobi todella haki, mukaan lukien transitiiviset riippuvuudet, välimuisteista palautetut paketit ja riippuvuudet, joita mikään lukitustiedosto ei luettele. Jokaisessa SBOM:ssa on kattavuustila, ja sen voi viedä CycloneDX- tai SPDX-muodossa. Valvottuja SBOM:eja arvioidaan jatkuvasti uudelleen, buildihistoria näyttää, mitkä aiemmat buildit sisälsivät haavoittuvan riippuvuuden, ja CRACI tukee VEX:iä. Katso SBOM-generointi ja haavoittuvuuksien seuranta.

VEX: usein kysytyt kysymykset

Mitä VEX tarkoittaa?

VEX on lyhenne sanoista Vulnerability Exploitability eXchange. Se on koneluettava lausunto siitä, koskeeko tietty tunnettu haavoittuvuus tuotetta, ja se julkaistaan, jotta käyttäjät tietävät, mitkä raportoidut haavoittuvuudet vaativat toimenpiteitä.

Mitä eroa on SBOM:lla ja VEX:llä?

SBOM luettelee tuotteen komponentit. VEX kertoo tietyn haavoittuvuuden osalta, koskeeko se tuotetta. SBOM muuttuu harvoin julkaisun jälkeen; VEX-lausunnot muuttuvat sitä mukaa, kun toimittaja tutkii ja korjaa. Siksi VEX julkaistaan yleensä erillisenä, tuotteeseen viittaavana dokumenttina eikä upoteta SBOM:iin.

Mitkä ovat VEX:n neljä tilaa?

not_affected, affected, fixed ja under_investigation. not_affected-lausunto tarvitsee perustelun tai vaikutuslausunnon, ja affected-lausunto tarvitsee toimenpidelausunnon, joka kertoo, mitä käyttäjien pitäisi tehdä.

Mitä VEX-formaattia minun kannattaa käyttää?

Käytä sitä, jota vastaanottajasi ja heidän työkalunsa lukevat. OpenVEX on pienin ja toimii Trivyn ja Grypen kanssa. CycloneDX VEX sopii tiimeille, jotka jo toimittavat CycloneDX-muotoisia SBOM:eja. CSAF VEX sopii organisaatioille, jotka jo julkaisevat CSAF-tietoturvatiedotteita, mikä on yleistä teollisuus- ja yritysohjelmistoissa. Monet toimittajat päätyvät muuntamaan niiden välillä.

Onko VEX sama asia kuin tietoturvatiedote?

Ei. Tietoturvatiedote selittää haavoittuvuuden, kenen tuotteita se koskee ja miten se korjataan, pääasiassa ihmisille. VEX on suppea, koneluettava tila tuote- ja haavoittuvuuskohtaisesti, pääasiassa työkaluille. Ne kulkevat usein yhdessä: CSAF-standardissa on sekä tietoturvatiedoteprofiili että VEX-profiili.

Kuka kirjoittaa VEX-dokumentteja?

Yleensä tuotteen toimittaja, usein sen tuoteturvallisuuden poikkeamiin reagoiva tiimi (PSIRT), koska se tietää, miten tuote on buildattu ja konfiguroitu. CISA:n vähimmäisvaatimukset sallivat myös kolmansien osapuolten laatia VEX:iä, ja jokaisen dokumentin on nimettävä laatijansa.

Lukevatko haavoittuvuusskannerit VEX:iä?

Useat lukevat. Trivy hyväksyy OpenVEX:n, CycloneDX:n ja CSAF VEX:n --vex-valitsimellaan ja pudottaa pois not_affected-merkityt löydökset. Grype hyväksyy OpenVEX:n ja CSAF VEX:n valitsimella --vex ja siirtää not_affected- ja fixed-löydökset ohitettujen listalle.