De levenscyclus van kwetsbaarheidsbeheer voor softwareleveranciers

Wat is de levenscyclus van kwetsbaarheidsbeheer?

De levenscyclus van kwetsbaarheidsbeheer is het herhaalbare proces dat een productleverancier volgt om een kwetsbaarheid af te handelen in software die hij levert: ontvangen of vinden, verifiëren, uitzoeken wat is getroffen, repareren, de fix uitbrengen en klanten informeren. In een leveranciersorganisatie wordt dit meestal uitgevoerd door een product security incident response team (PSIRT), terwijl engineeringteams de fixes maken.

Deze pagina behandelt de kant van de leverancier. IT-kwetsbaarheidsbeheer, het scannen en patchen van de servers en laptops die een organisatie gebruikt, deelt de terminologie maar niet de moeilijke delen. Een leverancier moet instaan voor elke ondersteunde release die klanten in handen hebben, en moet publiceren wat hij heeft gevonden.

De fasen van de levenscyclus

1. Ontvangen of ontdekken. Kwetsbaarheden komen binnen van externe onderzoekers via uw disclosureprogramma, van klanten, van coördinatoren zoals nationale CSIRT's en uit uw eigen monitoring: een nieuwe CVE in een open-sourceafhankelijkheid, een scannerbevinding of een interne test. Registreer elke melding met een tracking-ID en bevestig de ontvangst aan externe melders.
2. Verifiëren en triëren. Reproduceer het probleem of bevestig de match met de afhankelijkheid, bepaal of het een kwetsbaarheid in uw product is, en beoordeel hoe ernstig en hoe urgent die is. Sluit wat niet van toepassing is, met een reden die u later kunt laten zien. Prioriteringssignalen zoals EPSS en de CISA KEV-catalogus helpen de rest te rangschikken.
3. Getroffen producten en versies bepalen. Vind elk product, elke release en elke ondersteunde branch die de kwetsbare code of het kwetsbare component bevat, en elke klantimplementatie die er een draait. Deze stap bepaalt de omvang van de fix en de advisory.
4. Herstellen. Het verantwoordelijke team ontwikkelt en test een fix: een geüpgradede afhankelijkheid, een codewijziging, of een mitigatie zoals een configuratiewijziging wanneer een fix nog niet mogelijk is.
5. De fix uitbrengen. Lever bijgewerkte versies voor elke getroffen ondersteunde branch, via een kanaal dat klanten kunnen vertrouwen.
6. Informeren en openbaar maken. Publiceer een advisory die vermeldt wat is getroffen, hoe ernstig het is en wat er moet gebeuren, wijs een CVE-ID toe of verwijs ernaar, en vermeld de melder. Met machineleesbare formaten zoals CSAF en VEX kunnen klanten advisories automatisch verwerken.
7. Monitoren en leren. Let op misbruik en nieuwe informatie, werk de advisory bij en koppel de hoofdoorzaak terug naar de ontwikkeling, zodat dezelfde soort fout niet opnieuw wordt geleverd.

ISO/IEC 30111 en ISO/IEC 29147

Twee internationale standaarden beschrijven deze levenscyclus voor leveranciers. Ze verdelen die bij de grens van de organisatie:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titel	Vulnerability handling processes	Vulnerability disclosure
Dekt	Wat er intern gebeurt: verifiëren, onderzoeken, prioriteren en herstellen	De interfaces: meldingen ontvangen en advisories publiceren
Belangrijkste inhoud	Beleid en organisatie, verantwoordelijkheden van het PSIRT, afhandelingsfasen, aandachtspunten voor de softwareketen	Rollen van belanghebbenden, afhandeling van meldingen, inhoud van advisories, coördinatie, disclosure policy
Doelgroep	Leveranciers die gemelde kwetsbaarheden afhandelen	Leveranciers die meldingen ontvangen en kwetsbaarheden openbaar maken

De standaarden zijn ontworpen om samen te worden gebruikt. ISO/IEC 30111 noemt zes afhandelingsfasen: voorbereiding, ontvangst, verificatie, ontwikkeling van het herstel, release en post-release. De standaard vraagt ook om procesmonitoring, vertrouwelijkheid van kwetsbaarheidsinformatie en aandacht voor de softwareketen, omdat veel kwetsbaarheden in componenten zitten die u niet zelf hebt geschreven. Beide standaarden zijn actuele edities, bevestigd bij hun laatste ISO-beoordeling, en staan gemarkeerd voor herziening.

Andere kaders volgen dezelfde opzet. Het FIRST PSIRT Services Framework verdeelt het werk over het ontdekken van kwetsbaarheden, triage en analyse, herstel en openbaarmaking, en IEC 62443-4-1 neemt beheer van beveiligingsupdates en defecten op in zijn levenscyclus voor veilige ontwikkeling van industriële producten.

Rollen

• PSIRT of productbeveiligingsteam: is eigenaar van het proces, ontvangt meldingen, triëert, coördineert fixes en publiceert advisories. Zie CRACI voor PSIRT-teams en hoe een PSIRT verschilt van een CSIRT.
• Product- en engineeringteams: zijn eigenaar van de code, ontwikkelen en testen de fixes en leveren de releases.
• Releasemanagement: bepaalt welke ondersteunde branches een fix krijgen en wanneer.
• Klantenservice en communicatie: behandelen vragen van klanten en het publiek van de advisory.
• Juridische afdeling: adviseert over openbaarmaking, contracten en wettelijke meldingen.
• Externe partijen: melders, coördinatoren zoals CERT/CC of een nationaal CSIRT, upstream-maintainers van getroffen componenten en klanten die de fix moeten uitrollen.

Termijnen en SLA's

Er is niet één verplichte termijn. De meeste leveranciers stellen interne doelen per ernst vast en publiceren de externe doelen in hun disclosure policy. Een typische opzet:

• Bevestig een externe melding binnen enkele werkdagen.
• Triëer binnen dagen, zodat de melder en het verantwoordelijke team weten hoe het ervoor staat.
• Herstel binnen een termijn die wordt bepaald door ernst en misbruik, het kortst voor kritieke bevindingen en alles waarvan bekend is dat het wordt misbruikt.
• Maak openbaar wanneer de fix beschikbaar is, of op een afgesproken deadline als de fix uitloopt.

Druk van buitenaf bepaalt de uiterste grens. Onderzoekers stellen vaak een disclosure-deadline (Google Project Zero geeft leveranciers 90 dagen), en regelgeving voegt er eigen deadlines aan toe: de EU Cyber Resilience Act verplicht fabrikanten kwetsbaarheden onverwijld te verhelpen en stelt meldtermijnen voor actief misbruikte kwetsbaarheden (zie wat de CRA vereist). Wanneer een kwetsbaarheid al wordt misbruikt, zoals bij een zero-day, geldt voor elke fase de kortste termijn.

Waar de levenscyclus vastloopt

De meeste vertraging zit niet in het schrijven van de fix. Die komt doordat u niet weet wat u hebt geleverd.

• Niet weten welke releases een component bevatten. Er verschijnt een nieuwe CVE in een bibliotheek. Welke releases van vorig jaar bevatten die, en welke klanten gebruiken ze? Zonder vastlegging per release bouwen teams oude tags opnieuw of doorzoeken ze repositories met de hand, en is de lijst met getroffen versies in de advisory een gok.
• Transitieve afhankelijkheden. Veel kwetsbare pakketten hebt u niet zelf gekozen. Ze komen binnen als transitieve afhankelijkheden een aantal niveaus diep, dus een zoekopdracht in uw manifests mist ze.
• Ruis van ontwikkelafhankelijkheden. Scanners die lockfiles lezen, rapporteren testframeworks en buildtools die nooit worden geleverd. Elk daarvan kost triagetijd en laat de bevindingen die ertoe doen ondersneeuwen.
• Componenten buiten de pakketbeheerder. Binaries die door buildscripts worden gedownload, base images en componenten van leveranciers staan helemaal niet in een lockfile.
• Onduidelijk eigenaarschap. Een bevinding zonder eigenaar blijft liggen. Triage is pas klaar wanneer de fix een eigenaar heeft.
• Fixes die niet beklijven. Een kwetsbare versie komt terug via een andere afhankelijkheid of een oude branch, omdat niets voorkomt dat die in de volgende build terechtkomt.

Metrics

Metric	Wat die laat zien
Tijd tot bevestiging	Of melders antwoord krijgen wanneer uw beleid dat belooft
Tijd tot triage	Hoe lang een bevinding wacht voordat iemand weet of die ertoe doet
Tijd tot herstel, per ernst	Hoe snel fixes worden geleverd, gemeten van ontvangst tot een beschikbare release
Tijd tot advisory	Hoe lang klanten na de fix op informatie wachten
Aandeel binnen het doel	Of interne SLA's worden gehaald, vooral voor kritieke en misbruikte bevindingen
Backlog op leeftijd	Bevindingen die vastzitten, en waar
Niet-getroffen-percentage	Hoeveel triage-inspanning naar bevindingen gaat die niet van toepassing zijn

Meet elke fase apart. Een lange hersteltijd blijkt vaak een lange tijd te zijn om de getroffen releases te vinden.

Laat de levenscyclus draaien op een vastlegging van wat u hebt geleverd

Elke fase na de triage hangt af van weten wat er in elke release zit. CRACI draait uw GitHub Actions-builds op zijn eigen runners en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit CI-caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Elke SBOM heeft een volledigheidsstatus en wordt geëxporteerd als CycloneDX of SPDX.

CRACI beoordeelt gemonitorde SBOM's doorlopend opnieuw en bundelt ze over builds en repositories heen, en SBOM's van leveranciers kunnen worden toegevoegd, zodat ingekochte componenten samen met die van uzelf worden gemonitord. Wanneer een nieuwe CVE opduikt, toont de buildgeschiedenis welke eerdere builds de kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u was getroffen, en de inventarisweergave toont welke softwareversies op welke producten zijn uitgerold. Securityteams triëren bevindingen in CRACI en sturen ze naar de teams die verantwoordelijk zijn voor de fix, CRACI ondersteunt VEX, en policy gates kunnen builds blokkeren die een specifieke CVE bevatten, zodat een verholpen kwetsbaarheid wegblijft. Zie het volgen van kwetsbaarheden.

Levenscyclus van kwetsbaarheidsbeheer: veelgestelde vragen

Wat zijn de fasen van de levenscyclus van kwetsbaarheidsbeheer?

Voor een productleverancier: de kwetsbaarheid ontvangen of ontdekken, verifiëren en triëren, de getroffen producten en versies vinden, het herstel ontwikkelen, de fix uitbrengen, de advisory publiceren en daarna monitoren en leren. ISO/IEC 30111 noemt de fasen voorbereiding, ontvangst, verificatie, ontwikkeling van het herstel, release en post-release.

Wat is ISO/IEC 30111?

ISO/IEC 30111:2019 is de internationale standaard voor processen voor het afhandelen van kwetsbaarheden. De standaard geeft leveranciers eisen en aanbevelingen voor het verwerken en herstellen van gemelde kwetsbaarheden in hun producten en diensten, van beleid en de rol van het PSIRT tot de afhandelingsfasen en aandachtspunten voor de softwareketen.

Wat is het verschil tussen ISO/IEC 30111 en ISO/IEC 29147?

ISO/IEC 29147 behandelt het naar buiten gerichte deel: meldingen ontvangen en advisories publiceren. ISO/IEC 30111 behandelt de interne afhandeling daartussen: verifiëren, onderzoeken, prioriteren en repareren. De twee zijn bedoeld om samen te worden gebruikt. Zie coordinated vulnerability disclosure voor de kant van 29147.

Wat is vulnerability triage?

Triage is de stap waarin een securityteam bevestigt dat een gemelde of ontdekte kwetsbaarheid echt is, beoordeelt hoe ernstig en urgent die is voor uw product, en die doorstuurt naar het team dat verantwoordelijk is voor de fix. Goede triage sluit ook de bevindingen die niet van toepassing zijn, met een vastgelegde reden.

Hoe verschilt productkwetsbaarheidsbeheer van IT-kwetsbaarheidsbeheer?

IT-kwetsbaarheidsbeheer patcht de systemen die een organisatie gebruikt. Productkwetsbaarheidsbeheer handelt fouten af in software die de organisatie bouwt en aan anderen levert, en voegt dus stappen toe die IT-teams niet hebben: uitzoeken welke uitgebrachte versies zijn getroffen, een fix aan klanten leveren en hen daarover informeren in een advisory.

Welke metrics moet een proces voor kwetsbaarheidsafhandeling volgen?

De tijd tot bevestiging van een melding, tot triage, tot herstel en tot advisory, elk per ernst, plus het aandeel bevindingen dat uw interne doelen haalt, de open backlog op leeftijd en hoeveel bevindingen zijn gesloten als niet getroffen.