Wat je doet als er een CVE op je Yocto-image verschijnt
Een Yocto-image dat de fabriek verlaat, is een vaststaande verzameling bron, patches en packages. Een CVE die een half jaar later verschijnt, gaat over die verzameling. Niet over “Linux” in het algemeen, en niet over de versie die upstream intussen heeft.
Drie vragen, in die volgorde.
- Zat dit component in het image dat we geleverd hebben?
- Zit het lek in de bron die wij compileren, met onze patches en onze
PACKAGECONFIG? - Welke toestellen draaien die release nog?
De SBOM beantwoordt de eerste. De layer beantwoordt de tweede. De vloot beantwoordt de derde. Een scanner die versienummers vergelijkt, doet alsof de eerste vraag meteen de derde is. Dat is het rapport vol rood dat niemand durft te sluiten, en waarin het echte lek niet opvalt.
Hoe we de keuze voor Yocto zelf maken, staat in Yocto vs Ubuntu vs Debian. Hier gaat het over wat je met dat image doet zodra de eerste CVE binnenkomt.
De SBOM hoort bij het image dat je shipte
Een SBOM is de inventaris van één software-release: namen, versies, licenties, afhankelijkheden, en als het formaat het draagt ook hashes. SPDX is wat Yocto zelf schrijft. CycloneDX is wat sommige scanners vragen. Omzetten kan. Twee lijsten met de hand bijhouden, dat wijkt uit elkaar.
De inventaris die telt, is die van het rootfs. Yocto compileert ook native tools, een SDK en packages die IMAGE_INSTALL nooit op het toestel zet. Een CVE in een recipe die niet in het image zit, is geen CVE van het product. Het rapport met rootfs in de naam is het bestand dat je archiveert.
Die SBOM is een release-artefact, naast het image, de SRCREV’s en de handtekening. Image 2.4.1 en image 2.4.2 zijn twee inventarissen, ook als het dezelfde productnaam is. Een paneel zonder modem en een gateway mét libcurl zijn ook twee inventarissen, al delen ze een layer.
De klassenaam verschilt per tak. Op Scarthgap is SPDX nog create-spdx, en de check cve-check. Op recentere takken hangt dat aan het fragment core/yocto/sbom-cve-check. De documentatie van de tak die je bouwt, is de bron. Het principe blijft: het bestand komt uit de build die je ook tekent, niet uit een latere rebuild van een branch die intussen doorgeschoven is.
Een groene build is de staat op die dag
Tijdens de build legt Yocto de packages van het image naast een kopie van de NVD. Je krijgt per geïnstalleerd package de CVE’s met status Patched, Unpatched of Ignored. Dat hoort in de CI. Een Unpatched op een package in het productimage gaat niet mee naar productie tot iemand ernaar gekeken heeft.
Die poort zegt wat de database wist op het moment van de build. De machines in het veld bouwen niet opnieuw. Een rapport van releasedag dat geen relevante CVE meldde, wordt een archiefstuk zodra de NVD een nieuw record krijgt.
De opvolging is de gearchiveerde SBOM van elke release die je nog ondersteunt, opnieuw naast de feed. Niet de wereld rebuilden om te zien of OpenSSL in 2.4.1 genoemd wordt. Dat staat in het bestand van week één.
Een match is een vraag
Unpatched betekent dat Yocto geen patch heeft gevonden die deze CVE afdekt, en dat niemand hem als Ignored heeft gemarkeerd. Het betekent nog niet dat het toestel kwetsbaar is.
De volgorde die we aanhouden:
- Staat het package in de rootfs-SBOM van een release die nog ondersteund wordt? Zo niet, dan stopt het.
- Zit het pad in het image? Een
PACKAGECONFIGdie het getroffen stuk uitzet, een service die niet luistert, een bestand dat niet gecompileerd wordt: de CVE beschrijft code die niet op het toestel staat. - Zit de fix al in de recipe? Op een stabiele tak komt ze binnen als backport, niet als versiebump. Yocto herkent ze als de CVE-id in de bestandsnaam staat, of als de patchheader een
CVE:-regel heeft. Een patch die alleenfix-overflow.patchheet, telt niet mee en de check blijft hem tonen. - Pas dan bereikbaarheid en ernst. Netwerkpad, rechten, of het product die functie heeft.
De conclusie hoort in de layer.
CVE_STATUS[CVE-1234-0001] = "not-applicable-config: het getroffen PACKAGECONFIG staat uit"CVE_CHECK_IGNORE zonder reden is het oude mechanisme. CVE_STATUS met een reden is wat de volgende build kan lezen. Een spreadsheet “niet relevant” is dezelfde conclusie, tot de auteur weg is.
De patch zelf ziet er zo uit. Upstream-Status: Backport hoort erbij, met een verwijzing naar de upstream-commit. Dat is hoe de volgende persoon ziet dat het een backport is en geen lokale afwijking.
CVE: CVE-1234-0001Upstream-Status: Backport [url van de upstream-commit]Een versiescanner maakt hier het meeste lawaai. Upstream heeft 3.2.4. Het BSP heeft 3.0.13 plus de security-patches die de layer erop heeft gezet. Het versienummer ziet er oud uit. De bron kan de CVE al niet meer bevatten. Omgekeerd bewijst een nieuw versienummer niets als een lokale patch het gat heropent.
De kernel is het uiterste geval. Een vendor-fork deelt zijn versienummer met upstream en niet zijn boom. De NVD-match op “linux 6.6” gaat voor een groot deel over code die in die configuratie niet zit. Voor de Yocto-kernel is er een hulpscript dat de CVE-metadata naast de gecompileerde bron legt. Op een linux-imx of een vergelijkbare BSP-kernel is dat huiswerk van de laag die de fork bezit. Zolang die laag het niet doet, is de rode lijst geen triage. Stopt de SoM-leverancier met de fork, dan erf je die achterstand mee.
cve-check en de class vex zet je niet samen aan. Ze gebruiken dezelfde statusvariabelen. VEX is het document dat een klant vraagt om te zien waarom iets niet van toepassing is. Die reden is de CVE_STATUS-regel. Neemt de SPDX van de release die status mee, dan heb je geen tweede waarheid nodig.
Van de release naar de toestellen
Een bevestigde CVE in openssl van image 2.4.1 is nog geen lijst machines. Het wordt er een zodra je weet welke toestellen 2.4.1 melden, en welke al op een release staan waar de recipe de fix heeft.
Otaryx houdt die releases en die toestellen bij, en levert een getekend image met rollback. De beoordeling of de CVE het image raakt, blijft in de layer, bij wie de recipe kan lezen. Het platform brengt het image dat uit die beoordeling komt naar de groep die de oude release nog draait. Een scherm dat elke NVD-regel rood kleurt, verplaatst de inbox. De koppeling van een beoordeelde CVE aan precies die groep is waar we de monitoring naartoe trekken. Zonder die koppeling blijft het een lijst, met die koppeling wordt het een rollout.
De remediatie is meestal klein. Eén patch op de recipe, of één CVE_STATUS als de analyse “niet in dit image” is. Daarna rebuild van dat image, test, tekenen, een gefaseerde rollout, en controleren dat de toestellen de nieuwe versie melden. Een bump van de hele distributie omdat een scanner 3.0.13 te oud vond, hoort bij een Yocto-upgrade. Het is een slechte reactie op één CVE.
Sinds 11 september 2026
De Cyber Resilience Act vraagt vanaf 11 september 2026 dat een fabrikant actief uitgebuite kwetsbaarheden en ernstige incidenten meldt, via het Single Reporting Platform van ENISA. Een vroege melding binnen 24 uur nadat je het weet, een volledigere binnen 72 uur. Voor een actief uitgebuite kwetsbaarheid volgt het eindrapport uiterlijk 14 dagen nadat er een corrigerende maatregel is. Voor een ernstig incident binnen een maand na de 72-uursmelding.
Dat is een andere verzameling dan de Unpatched-lijst. Een record in de NVD, zonder aanwijzing dat iemand het misbruikt op een systeem zonder toestemming, is niet die melding. Een bevinding uit je eigen test evenmin, zolang er geen actieve uitbuiting is. De klok van 24 uur start als je weet dat het uitgebuit wordt.
De melding geldt voor producten die al op de markt staan. De plicht om bij te werken hangt aan de ondersteuningsperiode die je zelf aangeeft. De meldplicht voor actieve uitbuiting loopt daar niet vanzelf mee af. Wie niet meer kan zeggen welk image op welke machine staat, kan de melding niet begrenzen, en kan een klant ook niet vertellen dat een latere release de fix al heeft.
De rest van de verordening, beveiliging bij het ontwerp, updates tijdens de ondersteuningsperiode, technische documentatie en CE, geldt vanaf 11 december 2027. Een SBOM helpt bij de eerste vraag hierboven. Hij is het conformiteitsonderzoek niet. Dit is de kalender van de tekst, geen advies voor een dossier.
Wat je bewaart
Per release die nog in het veld kan staan:
- het image en de rootfs-SBOM uit dezelfde build
- het CVE-rapport van die build, als archief van wat je toen wist
- de
CVE_STATUS-regels in de layer, met reden - welke toestellen die release nu melden
- of de remediatie hen heeft bereikt
Kan je die vijf dingen voor image 2.4.1 nog leggen, dan is een nieuwe CVE een beoordeling van een middag, of een patch en een rollout. Kan je ze niet leggen, dan begint elk record met dezelfde zoektocht: wat hebben we toen eigenlijk geleverd.