VDR, VEX, OpenVEX en CSAF
Interlynk
Softwaretransparantie heeft een zeer noodzakelijke en langverwachte impuls gekregen. De Software Bill of Materials (SBOM) heeft als doel de sleutelartefact te worden voor softwaretransparantie en coördinatie van kwetsbaarheden binnen en tussen organisaties. Aangezien SBOM-formaten noodzakelijke details bevatten, waaronder softwarecomponenten en hun herkomst, kan een goede SBOM worden gebruikt om bekende kwetsbaarheden in de software bij te houden en te monitoren.
De SBOM-componentenlijst kan worden gebruikt met kwetsbaarheidsdatabases (bijv. NVD) om een kwetsbaarheidlijst voor het product te creëren.
Echter, SBOM alleen kan mogelijk niet genoeg detail coderen om niet-exploiteerbare kwetsbaarheden van exploiteerbare te scheiden. Dit kan leiden tot een nieuwe stroom van ruis in een al rumoerige omgeving van beveiligingsdatapunten.
Vroege adoptanten van SBOM hebben dit begrepen en hebben nieuwe normen evenals updates voor bestaande normen voorgesteld om de status van elke kwetsbaarheid naast de SBOM zelf te specificeren. In deze context spelen bestaande praktijken zoals VDR, CSAF en opkomende normen VEX en OpenVEX een sleutelrol.
VDR: Kwetsbaarheid openbaarmakingsrapport
VDR is de lijst van bekende kwetsbaarheden die door de softwareleverancier is gepubliceerd. Een typisch document vermeldt kwetsbaarheden, bijbehorende CVE, CVSS, Impact, Tijdlijn en mitigatiestrategieën, samen met de contactinformatie binnen de leverancier. De VDR is niet ontworpen voor programmatische consumptie, en het werkelijke formaat (HTML, Excel, PDF, CSV) kan per organisatie variëren.
Voorbeeld van een Kwetsbaarheiddisclosure Rapport bij Invicti
NIST-800–161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations beveelt de volgende rol voor VDR aan om een gedetailleerd begrip en proactief beheer van kwetsbaarheden aan te tonen.
Ondernemingen, waar van toepassing en geschikt, kunnen overwegen om
klanten een Kwetsbaarheiddisclosure Rapport (VDR) te verstrekken om aan te tonen
dat er juiste en volledige kwetsbaarheidsbeoordelingen voor componenten die worden vermeld in
SBOMs zijn uitgevoerd. De VDR moet de analyse en bevindingen bevatten die de
impact (of het ontbreken van impact) beschrijven die de gerapporteerde kwetsbaarheid heeft op een
component of product. De VDR moet ook informatie bevatten over plannen
om de CVE aan te pakken. Ondernemingen zouden overwegen de VDR te publiceren
binnen een veilig portaal dat beschikbaar is voor klanten en de VDR te ondertekenen met
een vertrouwde, verifieerbare priv钥 die een tijdstempel bevat dat
de datum en tijd van de VDR-handtekening en de bijbehorende VDR aangeeft. Ondernemingen
zouden ook overwegen een apart notificatiekanaal op te zetten voor
klanten in gevallen waarin kwetsbaarheden opduiken die niet zijn bekendgemaakt
in de VDR. Ondernemingen zouden hun hoofdaannemers moeten verplichten om
deze controle te implementeren en deze vereiste door te geven aan relevante
sub-tier aannemers.
VDR rapporteert bekende kwetsbaarheden met het product maar heeft geen directe relatie met de SBOM
Hoewel, in theorie, VDR de status van elke kwetsbaarheid kan beschrijven, maakt het gebrek aan een gemeenschappelijke rapportagestandaard het minder praktisch voor programmatische consumptie en, daarom, een knelpunt in de beoordeling van kwetsbaarheidsexploitabiliteit.
VEX: Kwetsbaarheid Exploitability eXchange
Het concept van VEX is ontstaan binnen dezelfde NTIA-multi-stakeholdergroep die de SBOM-aanbevelingen heeft geformaliseerd in SBOM Framing en SBOM Minimum Elementen. VEX is nog niet geformaliseerd, maar het voorstel is gericht op het delen van een bewering over de status van een kwetsbaarheid in specifieke producten of versies. De status kan zijn - Niet Aangetast, Aangetast, Hersteld, Onder Onderzoek.
VEX: Enkel Document dat Meerdere Producten, Meerdere Kwetsbaarheden, Meerdere Statussen
Eerder dit jaar stemde de werkgroep ook in met de Minimale Eisen voor VEX, waarbij elk VEX-document wordt beschreven als een set van VEX-verklaringen, waarbij elke verklaring één status voor één kwetsbaarheid draagt.
VEX Document en Verklaringen van Minimale Eisen voor VEX
Met andere woorden, wanneer SBOM en VEX samen worden gebruikt, kan een goed beschreven SBOM worden gekoppeld aan componenten en mogelijke kwetsbaarheden, terwijl VEX kan worden gebruikt om het aantal werkelijk van toepassing zijnde kwetsbaarheden te verminderen. Een lid van de gemeenschap beschreef het mooi als “Eerst zet SBOM alle relevante lichten aan, en VEX zet alle onnodige uit.”
VEX Variëteiten: VEX1 ingebed in SBOM om enkele status te deactiveren, VEX2 later uitgebracht om nieuw ontdekte kwetsbaarheid uit te schakelen, VEX3 later uitgebracht om werk in uitvoering voor een andere kwetsbaarheid te verklaren
Hoewel niet strikt noodzakelijk, is een VEX-document bedoeld als een directe metgezel van de SBOM. VEX kan rechtstreeks ingebed worden in CycloneDX 1.4 en is opgenomen in het Beveiligings profiel van de SPDX 3.0 release kandidaat. VEX is ook een profiel in CSAF versie 2.0 (Zie CSAF hieronder).
OpenVEX: Open Vulnerability Exploitability eXchange
OpenVEX is een implementatie van VEX die is ontworpen om interoperabel en inbedbaar te zijn. Hoewel VEX in principe een mechanisme bood voor het communiceren van de status van kwetsbaarheden naast de SBOM zelf, was het niet mogelijk om deze statussen buiten CycloneDX of CSAF in te bedden. OpenVEX heeft als doel agnostisch te zijn ten opzichte van de SBOM-specificatie en fungeert als een alternatief voor VEX met een formele schema die al aanwezig is.
OpenVEX Voorbeeld
CSAF: Gemeenschappelijk Security Advies Kader
OASIS CSAF is een open specificatie voor de “creatie, update en interoperabele uitwisseling van beveiligingsadviezen als gestructureerde informatie over producten, kwetsbaarheden en de status van impact en remediëring.”
Met andere woorden, CSAF maakt de bekendmaking van kwetsbaarheden en hun impact programmatisch toegankelijk. CSAF is echter bedoeld om aanzienlijk meer te zijn dan alleen de bekendmaking en coördinatie van kwetsbaarheden. Vanaf versie 2.0, goedgekeurd in november 2022, ondersteunt CSAF vijf verschillende profielen:
CSAF Basis (standaard)
Beveiligingsincidentrespons (voor beveiligingsincidenten zoals lekken)
Informatieadvies (voor niet-kwetsbaarheid informatie zoals misconfiguratie)
Beveiligingsadvies (voor kwetsbaarheid informatie)
VEX (voor kwetsbaarheid exploiteerbaarheid informatie)
Een CSAF Advies van RedHat die een kwetsbaarheid in OpenShift verklaart
Beste praktijken
Kwetsbaarheid openbaarmaking via VDR is een goed gevestigde praktijk, en CSAF is sinds 2017 ook verbeterd (bijvoorbeeld, Red Hat CSAF). VEX en OpenVEX hebben tot doel directe metgezellen van SBOM te zijn om de kwetsbaarheidsgeluiden te beheersen. Er is echter geen formele specificatie voor VEX (naast de CISA-voorbeelden), en OpenVEX is nog steeds v0.0.0 aan het einde van juni 2023. Met andere woorden, het openbaar maken van de kwetsbaarheidstatus naast SBOM blijft een actief gebied.
Bij Interlynk raden we de volgende processen aan om de beste beveiligingspraktijken te demonstreren en de kwetsbaarheidsgeluiden in de organisatie te beperken:
1. Bouw SBOM per release: Veel SBOM-generatorhulpmiddelen, inclusief open-source opties, kunnen SBOM genereren uit afhankelijkheid grafieken, CI/CD, afbeeldingsscans of software compositieanalyses. Voor producten die zijn samengesteld met onderliggende projecten, gebruik een hulpmiddel zoals sbom-assemble voor het assembleren en bijhouden van de SBOM voor het eindproduct.
2. Sla SBOM op en volg deze: Hoewel het mogelijk is om enige waarde uit SBOM's te halen via tools zoals sbom-grep, kan een formeel systeem (zoals SBOM Link) het verbinden van SBOM aan bekende kwetsbaarheden eenvoudig maken en de artefacten voor de toekomst behouden.
3. Registreer kwetsbaarheidstatus: Voor elke productrelease, gebruik een systeem om de status van belangrijke kwetsbaarheden vast te leggen zoals geïdentificeerd door de SBOM-analyse. De definitie van een belangrijke kwetsbaarheid varieert afhankelijk van de reikwijdte van de applicatie en de risicotolerantie van de organisatie. Echter, minimaal zouden organisaties zich moeten voorbereiden om een registratie te hebben voor kwetsbaarheden die als Kritiek of Hoog zijn gerapporteerd. Het uiteindelijke doel zou moeten zijn om de status van elke belangrijke kwetsbaarheid op één enkele en specificatie-agnostische plaats vast te leggen. Dit zal de vertaling naar standaarden zoals CycloneDX VEX, OpenVEX en SPDX3.0 of CSAF vergemakkelijken indien nodig.
4. Breng product uit met SBOM EN kwetsbaarheidstatussen/VDR: Een productrelease met SBOM zou ook een document voor kwetsbaarheidstatus moeten bevatten. Een SBOM zonder de openbaarmaking van de kwetsbaarheidstatus zal waarschijnlijk onnodige ruis veroorzaken. Als de organisatie beveiligingsadviezen produceert via CSAF, is dit een uitstekende plaats voor kwetsbaarheidstatus openbaarmakingen. Zo niet, dan kunnen statussen worden ingebed in CycloneDX 1.4, SPDX 3.0 (Binnenkort beschikbaar), of opgenomen worden naast SBOM met OpenVEX.
5. Breng VEX uit voor nieuw ontdekte kwetsbaarheden: Als er een nieuw gerapporteerde kwetsbaarheid van toepassing is op een eerder vrijgegeven product, moeten er een of meer nieuwe VEX worden gegenereerd om de analyse van de kwetsbaarheid ten opzichte van het product vast te leggen. We raden aan te beginnen met 'Onder Onderzoek' zo snel mogelijk en bij te werken naarmate de reikwijdte van de kwetsbaarheid wordt gevonden. Let op dat we NIET aanraden om een kwetsbaarheidstatus te genereren voor alle nieuw gerapporteerde kwetsbaarheden. In plaats daarvan raden we aan ons te concentreren op kwetsbaarheden die in een van de componenten zijn ontdekt die eerder in de SBOM zijn opgenomen. Dit is waarom het opslaan en volgen van SBOM een essentieel onderdeel van de praktijk is.
Softwaretransparantie via SBOM heeft de potentie om de broodnodige aandacht en middelen voor beveiligingspraktijken tijdens de ontwikkeling te brengen. Echter, kwetsbaarhedemanagement is al een probleem dat veel middelen vereist, zelfs voordat SBOM deel werd van het gesprek. VEX en gerelateerde specificaties zijn bedoeld om geen extra druk op de beveiligingsteams te veroorzaken en onnodige waarschuwingen uit te schakelen. Dit blijft een voortdurend proces, maar organisaties kunnen nog steeds robuuste praktijken rond dit onderwerp opbouwen om afleidingen te minimaliseren.