Hvad er VEX, og hvorfor en SBOM alene skaber arbejde

Giver du en kunde en SBOM, har du fortalt dem, hvad din software indeholder. Du har samtidig givet dem en liste over hver eneste sårbarhed, nogen nogensinde har offentliggjort mod de komponenter — og de fleste af dem rammer dig ikke. En VEX er måden at sige det på, i en form en maskine kan læse.

Det er den utilsigtede konsekvens ved styklister, som ingen advarer om. At udgive en fortegnelse er den nemme del. Det, der følger, er en kunde, der kører fortegnelsen gennem en scanner, får fyrre hits og skriver til dig om alle fyrre.

Hvorfor de fleste sårbarheder i din SBOM ikke rammer dig

En sårbarhed er en egenskab ved en komponent og ved den måde, den bliver brugt på. At komponenten er til stede er nødvendigt, men sjældent tilstrækkeligt. Almindelige grunde til, at et offentliggjort hul ikke gælder dit produkt:

• Den sårbare kodesti bliver aldrig nået. Hullet sidder i en funktion i biblioteket, diges applikation ikke kalder.
• Den kræver en opsætning, du ikke bruger. Rigtig mange advarsler gælder kun, når en bestemt indstilling er slået til.
• Det er en afhængighed, der kun bruges under udvikling. Et sårbart build-værktøj kommer ikke i produktion — men vær forsigtig her: build-værktødig kører på udviklermaskiner og CI-servere, som er mål i sig selv.
• Du har allerede afbødet den uden at opdatere, ved at slå den ramte funktion fra eller blokere det input, der når frem til den.

Hver eneste af dem er et rigtigt og forsvarligt svar. Indtil for nylig fandtes der ingen standardmåde at nedskrive nogen af dem på, så svaret levede i en mailtråd, og den næste kunde spurgte igen.

Hvad en VEX egentlig er

Et Vulnerability Exploitability eXchange-dokument er et udsagn, pr. sårbarhed, om hvorvidt den rammer dit produkt. Er SBOM'en fortegnelsen, er VEX'en vurderingen.

Hver post kobler en sårbarhed med en status, og det er netop statusserne, det hele handler om:

• Ikke ramt — hullet findes i en komponent, men kan ikke udløses i dette produkt. Det er den, der sparer alle for tid, og den kræver en begrundelse fra en fast liste og ikke fritekst: komponenten er ikke til stede, den sårbare kode er ikke til stede, den er til stede men aldrig i en udførelsessti, den kan ikke nås af en angriber, eller der er allerede en afbødning på plads.
• Ramt — den gælder, og her er, hvad I gør ved den i mellemtiden.
• Rettet — allerede udbedret i denne version.
• Under vurdering — vi har set den og er ikke færdige med at beslutte.

Den sidste status er vigtigere, end den ser ud, og det er dér, de fleste VEX-dokumenter går galt.

Fristelsen til kun at udgive de flatterende poster

En VEX, der kun nævner de sårbarheder, du har afklaret, er værre end ingen VEX. Den læses som en ren attest, mens den i virkeligheden er en filtreret — og i samme øjeblik en kunde finder en kendt advarsel, diges dokument bare udelader, bliver hver eneste anden post mistænkelig.

En advarsel, ingen har vurderet endnu, bør stå som under vurdering. Det er en ærlig status, den er langt bedre end tavshed, og den fortæller læseren noget sandt: vi kender den, og vi er ikke færdige. Alternativet — at udelade den — fortæller intet, men antyder alt.

Hvor indholdet bør komme fra

Ikke fra en selvstændig dokumentskrivningsøvelse. Bliver det at lave en VEX til et projekt i sig selv, bliver det gjort én gang og aldrig opdateret.

Den brugbare iagttagelse er, at de fleste teams allerede producerer de her data og smider dem væk. Hver gang nogen vurderer et fund i et sikkerhedsværktøj og markerer det "rettes ikke — kan ikke udnyttes i vores opsætning, vi bruger ikke den codec", er dét et VEX-udsagn med en begrundelse på. Det er bare fanget i et sagssystem.

Så den praktiske tilgang er at gøre selve vurderingsarbejdet til kilden: når en udvikler kvitterer for et fund med en begrundelse, bliver den begrundelse til analysedetaljen i det eksporterede dokument. Arbejdet er allerede lavet; eksporten er et formateringsproblem.

Hvilket format man skal bruge

Tre er i reel brug. CycloneDX bærer VEX-data indbygget ved siden af sin fortegnelse. OpenVEX er et bevidst minimalt format, der står alene. CSAF — en OASIS-standard med en dedikeret VEX-profil — er den tungeste af de tre og den, store virksomheder og offentlige indkøbere oftest nævner ved navn, fordi det er dét, myndighedernes advarselsudgivere bruger. CycloneDX er det pragmatiske standardvalg, hvis du allerede laver CycloneDX-SBOM'er, for så deler de to dokumenter identifikatorer og kan ikke glide fra hinanden; regn med at blive bedt om CSAF, hvis du sælger ind i reguleret indkøb — NIS2 er som regel grunden til, at en kunde begynder at spørge.

Uanset hvad du vælger, gælder samme regel som for selve SBOM'en: den beskriver et øjeblik. Generér den igen, når koden ændrer sig, og sæt dato på.

Hvad er et VEX-dokument?

Et Vulnerability Exploitability eXchange-dokument er et maskinlæsbart udsagn, pr. sårbarhed, om hvorvidt den reelt rammer dit produkt. Hvor en SBOM siger, hvad din software indeholder, siger en VEX, hvad du har besluttet om hvert kendt hul i de komponenter — typisk at produktet ikke er ramt, er ramt, er rettet, eller stadig er under vurdering. Formålet er at stoppe kunder og scannere i at rejse sårbarheder, der findes i en komponent, men ikke kan udløses i dit produkt.

Hvad er forskellen på en SBOM og en VEX?

En SBOM er fortegnelsen: hver pakke, din software indeholder, med version og licens. En VEX er vurderingen: for hver kendt sårbarhed i de pakker, om den reelt gælder dit produkt, og hvorfor. At udgive en SBOM uden en VEX har det med at skabe arbejde, fordi modtageren kører diges fortegnelse gennem en scanner og spørger dig om hvert eneste hit — inklusive det flertal, der ikke rammer dig.

Hvorfor skulle en sårbarhed ikke ramme mit produkt?

Fordi en sårbarhed er en egenskab ved en komponent og ved den måde, den bliver brugt på — ikke ved komponenten alene. Den sårbare kodesti bliver måske aldrig nået af diges applikation, hullet kræver måske en indstilling, du ikke slår til, afhængigheden bruges måske kun under bygning, eller du har måske allerede afbødet den uden at opdatere. Alle er forsvarlige svar — en VEX er blot standardmåden at nedskrive dem på, så du ikke skal forklare det igen på mail.

Skal en VEX nævne sårbarheder, jeg endnu ikke har vurderet?

Ja. En VEX bør nævne de sårbarheder, du endnu ikke har vurderet, markeret som under vurdering. En VEX, der kun nævner de poster, du har afklaret, læses som en ren attest, mens den i virkeligheden er filtreret, og i samme øjeblik en læser finder en kendt advarsel, diges dokument udelader, bliver hver eneste anden post mistænkelig. Under vurdering er en ærlig status, der fortæller læseren noget sandt: vi kender den og er ikke færdige med at beslutte.

Hvor CodeControl passer ind

CodeControl eksporterer VEX som CycloneDX 1.5 ud fra den vurdering, du allerede har lavet: at kvittere for et fund med en begrundelse oversættes til en analysetilstand med din egen note som detalje. En advarsel, ingen endnu har vurderet, står som under vurdering i stedet for at blive udeladt. Den genereres ud fra samme scanning som diges SPDX- og CycloneDX-SBOM'er, så de to dokumenter deler identifikatorer og kan ikke glide fra hinanden.