Coordinated vulnerability disclosure: zo organiseert u een disclosureprogramma

Wat is coordinated vulnerability disclosure?

Coordinated vulnerability disclosure (CVD) is de praktijk waarbij een nieuw gevonden kwetsbaarheid vertrouwelijk wordt afgehandeld tussen de vinder en de leverancier tot er een fix of mitigatie beschikbaar is, waarna ze wordt gepubliceerd. De CERT Guide to Coordinated Vulnerability Disclosure beschrijft dit als het verzamelen van informatie van vinders van kwetsbaarheden, het coördineren van het delen van die informatie tussen de betrokken belanghebbenden, en het openbaar maken van de kwetsbaarheid en de mitigaties ervan, ook aan het publiek.

Voor een productleverancier heeft CVD twee helften. De naar buiten gerichte helft, meldingen ontvangen en advisories publiceren, behandelt deze pagina. De naar binnen gerichte helft, verifiëren, repareren en uitbrengen, is de levenscyclus van kwetsbaarheidsbeheer. Beide worden meestal uitgevoerd door een PSIRT.

CVD vs full disclosure vs bug bounty

	Coordinated disclosure	Full disclosure	Bug bounty
Wat het is	Vertrouwelijke melding, fix en daarna publicatie op een afgesproken moment	De vinder publiceert details direct, met of zonder de leverancier te informeren	Een programma dat betaalt voor geldige bevindingen
Wie de timing bepaalt	Leverancier en vinder samen, soms met een coördinator	De vinder	De voorwaarden van het programma, meestal volgens CVD
Risico voor gebruikers	Het laagst: details worden openbaar zodra er een fix is of een deadline verstrijkt	Het hoogst: aanvallers komen het tegelijk met verdedigers te weten	Zoals bij CVD
Kosten	Personeelstijd voor triage en reactie	Ongepland spoedwerk	Personeelstijd plus beloningen en vaak platformkosten

Een bug bounty is geen alternatief voor een vulnerability disclosure program (VDP). Het is een stimulans bovenop zo'n programma. Elke leverancier heeft een manier nodig waarop iedereen een kwetsbaarheid kan melden; een bounty bepaalt alleen of sommige meldingen worden beloond.

Wat er in een vulnerability disclosure policy staat

Een vulnerability disclosure policy is het openbare document dat de voorwaarden van uw programma vastlegt. ISO/IEC 29147, de internationale standaard voor vulnerability disclosure, stelt één element verplicht, een voorkeurscontactmethode, en beveelt er nog meer aan. Een volledig beleid behandelt:

• Hoe u meldt. Een speciaal adres of webformulier, en een manier om gevoelige details veilig te versturen, zoals een gepubliceerde encryptiesleutel.
• Wat erin moet staan. Getroffen product en versie, stappen om te reproduceren, impact en hoe de melder te bereiken is.
• Scope. Welke producten, versies en diensten eronder vallen, en welke testmethoden niet zijn toegestaan, zoals denial of service of toegang tot gegevens van andere gebruikers.
• Safe harbor. De toezegging geen juridische stappen te ondernemen tegen onderzoek te goeder trouw dat het beleid volgt.
• Wat melders kunnen verwachten. Wanneer u de melding bevestigt, hoe u hen op de hoogte houdt en uw streeftijd voor een fix.
• Disclosure-tijdlijn. Wanneer details openbaar worden, en wat er gebeurt als een fix langer duurt.
• Publicatie. Waar advisories verschijnen en of u CVE-ID's toewijst.
• Erkenning. Of en hoe u melders vermeldt, en of u bounty's betaalt.

Houd het beleid kort en specifiek. Melders lezen het om te bepalen of een melding bij u veilig is en de moeite waard.

security.txt: maak uw contactpunt makkelijk vindbaar

Een beleid werkt alleen als onderzoekers het kunnen vinden. RFC 9116, gepubliceerd in april 2022, definieert security.txt, een klein tekstbestand dat via HTTPS wordt aangeboden op /.well-known/security.txt.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Verplicht: Contact en Expires. RFC 9116 beveelt een vervaldatum aan die minder dan een jaar vooruit ligt, zodat het bestand niet veroudert.
• Optioneel: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical en Hiring.
• Ondertekening: de RFC beveelt een OpenPGP-cleartexthandtekening aan, met Canonical ingesteld.

Zet vóór de Expires-datum een herinnering in de agenda. Een verlopen bestand vertelt onderzoekers dat niemand meeleest.

Embargo's en disclosure-tijdlijnen

Het embargo is de periode tussen de melding en de publicatie. De meest genoemde norm is het beleid van Google Project Zero: leveranciers krijgen 90 dagen om een patch beschikbaar te maken, en details worden 30 dagen nadat de patch is uitgebracht gepubliceerd. Een leverancier die iets meer tijd nodig heeft, kan om een respijtperiode vragen, tot maximaal 104 dagen in totaal. Wanneer een kwetsbaarheid al in het wild wordt misbruikt, zakt de deadline naar 7 dagen.

Uw eigen beleid kan andere voorwaarden stellen, en veel melders accepteren die. Het gaat erom dat de tijdlijn is vastgelegd, dat u melders op de hoogte houdt en dat u vóór de deadline om uitstel vraagt, niet erna. Een advisory die volgens planning verschijnt met een mitigatie, is beter dan stilte.

CVE-ID's en CNA's

De meeste advisories hebben een CVE-ID, zodat klanten en tools ze kunnen matchen. ID's worden toegewezen door CVE Numbering Authorities (CNA's), organisaties die binnen een afgesproken scope ID's mogen toewijzen. Veel softwareleveranciers zijn CNA voor hun eigen producten, waardoor ze het ID kunnen toewijzen en het record volgens hun eigen planning kunnen publiceren. Bent u dat niet, dan wijst een CNA met een scope die uw product dekt, of een CNA of Last Resort, het toe.

Coördinatie tussen meerdere partijen

Sommige kwetsbaarheden raken veel leveranciers tegelijk: een fout in een veelgebruikte bibliotheek, een protocol of een chip. Dan helpt een coördinator om elke getroffen leverancier te bereiken en één publicatiedatum af te spreken.

• CERT/CC, bij het Software Engineering Institute van Carnegie Mellon University, coördineert zaken met meerdere leveranciers en publiceert de CERT CVD-gids.
• Nationale CSIRT's in de EU. Onder NIS2 wijst elke lidstaat een CSIRT aan als CVD-coördinator. Dat treedt op als vertrouwde tussenpersoon tussen melders en leveranciers, onderhandelt over disclosure-tijdlijnen, behandelt kwetsbaarheden die meerdere entiteiten raken en accepteert anonieme meldingen.
• De European Vulnerability Database (EUVD) van ENISA, opgezet onder NIS2, is sinds mei 2025 operationeel en publiceert informatie over publiek bekende kwetsbaarheden, waaronder kwetsbaarheden die in de EU zijn gecoördineerd.

ISO/IEC 29147 behandelt ook het geval waarin u beide bent: een leverancier wiens product een kwetsbaar component van een andere leverancier bevat, en die upstream moet melden en uw eigen klanten moet informeren.

Nadat een melding binnenkomt

1. Bevestig binnen de tijd die uw beleid belooft, en geef de melder een tracking-ID.
2. Verifieer de melding en beoordeel de ernst.
3. Bepaal wat is getroffen: elk product, elke release en elke ondersteunde branch die de kwetsbare code of het kwetsbare component bevat.
4. Repareer en breng uit voor elke getroffen branch, en houd de melder op de hoogte.
5. Publiceer de advisory, met een CVE-ID, getroffen versies, herstel en vermelding van de melder. Machineleesbare advisories gebruiken CSAF, en VEX vertelt klanten welke producten niet zijn getroffen.

Het volledige proces, met rollen, termijnen en metrics, staat in de levenscyclus van kwetsbaarheidsbeheer.

Regelgeving maakt CVD-beleid verplicht

De EU Cyber Resilience Act verplicht fabrikanten een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden in te voeren en te handhaven, en een contactadres te bieden voor het melden van kwetsbaarheden, ook die in componenten van derden (bijlage I, deel II). Deze verplichtingen gelden vanaf 11 december 2027; zie wat de CRA vereist. NIS2 artikel 21, lid 2, onder e) noemt de afhandeling en openbaarmaking van kwetsbaarheden onder de beveiligingsmaatregelen die essentiële en belangrijke entiteiten moeten nemen. In de VS gaf Executive Order 14028 opdracht tot richtsnoeren voor de softwareketen die onder meer deelname aan een vulnerability disclosure program omvatten.

Een melding is maar zo nuttig als uw vastlegging van wat u hebt geleverd

Elke melding roept dezelfde eerste vraag op: welke van onze releases bevatten dit? 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. De buildhistorie toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, zodat u weet in welke periode u was getroffen, en de inventarisweergave toont welke softwareversies op welke producten zijn uitgerold.

CRACI bundelt SBOM's over builds en repositories heen en beoordeelt gemonitorde SBOM's doorlopend opnieuw, dus zodra een kwetsbaarheid in een open-sourcecomponent is gepubliceerd, ziet u overal waar die voorkomt. Securityteams triëren bevindingen 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 zodra die is verholpen. Zie het volgen van kwetsbaarheden.

Coordinated vulnerability disclosure: veelgestelde vragen

Wat is coordinated vulnerability disclosure?

Coordinated vulnerability disclosure (CVD) is het proces waarbij de persoon die een kwetsbaarheid vindt die vertrouwelijk aan de leverancier meldt, de leverancier die repareert, en de details worden gepubliceerd zodra gebruikers zich kunnen beschermen, meestal op een datum die de partijen afspreken. Coördinatoren zoals CERT/CC of een nationaal CSIRT komen tussenbeide wanneer een leverancier onbereikbaar is of meerdere leveranciers zijn getroffen.

Wat is het verschil tussen een VDP en een bug bounty?

Een vulnerability disclosure program (VDP) vertelt iedereen hoe een kwetsbaarheid kan worden gemeld en wat er te verwachten valt, zonder voor bevindingen te betalen. Een bug bounty betaalt onderzoekers voor geldige bevindingen, meestal binnen een gedefinieerde scope en vaak via een bountyplatform. De meeste organisaties beginnen met een VDP; een bounty is een optionele aanvulling daarop, geen vervanging.

Wat moet er in een vulnerability disclosure policy staan?

Op zijn minst hoe er moet worden gemeld: een contactadres of formulier. ISO/IEC 29147 beveelt ook aan te vermelden wat een melding moet bevatten, hoe er veilig kan worden gecommuniceerd, wat melders kunnen verwachten en wanneer, wat binnen de scope valt, hoe u advisories publiceert en hoe u melders vermeldt. De meeste beleidsdocumenten voegen een safe-harborverklaring en een disclosure-tijdlijn toe.

Wat is security.txt?

security.txt is een plattetekstbestand dat is gedefinieerd in RFC 9116 en wordt aangeboden op /.well-known/security.txt. Het vertelt onderzoekers waar ze kwetsbaarheden kunnen melden. Het moet een veld Contact en een veld Expires bevatten en kan linken naar uw beleid, encryptiesleutel en erkenningspagina.

Hoe lang is een typische disclosure-deadline?

90 dagen is de meest genoemde norm. Google Project Zero geeft leveranciers 90 dagen om een patch beschikbaar te maken en publiceert details 30 dagen na de patch, met een deadline van 7 dagen wanneer een kwetsbaarheid al in het wild wordt misbruikt. Uw eigen beleid kan andere voorwaarden stellen, en coördinatoren onderhandelen per geval.

Is een beleid voor coordinated vulnerability disclosure verplicht?

Steeds vaker wel. De EU Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen een CVD-beleid in te voeren en te handhaven en een contactadres voor meldingen te bieden, en NIS2 noemt de afhandeling en openbaarmaking van kwetsbaarheden onder de vereiste beveiligingsmaatregelen. Elders vragen klanten en inkoopregels er vaak om.

Moet ik een CNA zijn om een CVE-ID te krijgen?

Nee. Een CVE Numbering Authority (CNA) wijst CVE-ID's toe binnen zijn eigen scope, en veel leveranciers worden CNA voor hun eigen producten. Bent u dat niet, dan kan een CNA met een scope die uw product dekt, of een CNA of Last Resort, het ID toewijzen.