Wie een kwetsbaarheid in uw product vindt, heeft een duidelijk en voor mensen bereikbaar kanaal nodig om die te melden, en uw team heeft een schriftelijk beleid nodig voor hoe een melding wordt bevestigd, getrieerd, opgelost en openbaar gemaakt. Onder de EU Verordening cyberweerbaarheid (Verordening (EU) 2024/2847) betekent dit een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden (CVD) invoeren en handhaven, plus één centraal contactpunt voor kwetsbaarheidsmeldingen publiceren. Er is geen vrijstelling voor kmo's. Deze pagina behandelt wat het beleid moet bevatten, hoe u het contactkanaal publiceert en hoe CVD zich verhoudt tot vulnerability reporting en het bredere kader voor vulnerability handling.
Samenvatting
- Een CVD-beleid is verplicht. Schriftelijk, gepubliceerd, gehandhaafd, zonder omvangsdrempel. Verder uitgewerkt in What the CRA actually requires hieronder.
- Eén centraal contactpunt is verplicht. Gebruikers moeten een mens kunnen bereiken; het kanaal mag niet beperkt zijn tot geautomatiseerde hulpmiddelen.
security.txt(RFC 9116) is de de facto conventie voor het publiceren van het contactpunt, maar de CRA schrijft geen specifiek formaat voor.- CVD is niet hetzelfde als ENISA-melding. Het CVD-beleid regelt uw relatie met de melder; de regelgevende klok richting ENISA en de coördinerende CSIRT loopt parallel. Zie Coordination with ENISA hieronder.
- Publieke openbaarmaking van verholpen kwetsbaarheden is verplicht, met een beperkte uitsteloptie wanneer het beveiligingsrisico van openbaarmaking zwaarder weegt dan het voordeel totdat gebruikers de kans hebben gehad om de patch toe te passen.
- Boetedetails horen in de handhavingsgids. Zie boetes en handhaving voor de boeteladder en marktmaatregelen.
De vier ankerpunten van een CRA-conforme CVD-positie: beleid, contact, publicatie en verwijzing naar handhaving.
Wat de CRA daadwerkelijk vereist voor CVD
De CVD-plicht is kort: fabrikanten moeten "een beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden invoeren en handhaven". Die ene zin draagt vier operationele componenten, die elk op een eigen manier kunnen falen:
| Vereiste | Wat dit in de praktijk betekent | Veelvoorkomende fout |
|---|---|---|
| InvoerenGedocumenteerd beleid | Er bestaat een schriftelijk, toegankelijk beleid. Het beschrijft wat binnen scope valt, hoe te melden, welke reactie te verwachten is en wanneer openbaarmaking plaatsvindt. | Een ongedocumenteerde interne gewoonte van het triëren van security@-e-mails kwalificeert niet. |
| HandhavenUitgevoerd proces | Het beleid wordt uitgevoerd, niet alleen gepubliceerd. Bevestigingstijdlijnen, triagetoezeggingen en openbaarmakingsvoorwaarden die in het document staan, worden in de praktijk nagekomen. | Een beleid dat bevestiging binnen 72 uur belooft maar routinematig drie weken duurt, wordt niet gehandhaafd. |
| Melden vergemakkelijkenToegankelijk kanaal | Het beleid maakt het externe melders gemakkelijk om informatie over kwetsbaarheden te delen: een contactadres, een gepubliceerd proces en een voor mensen bereikbaar kanaal dat niet achter een login of chatbot zit. | Een uitsluitend login-portaal, alleen-bot-intake of een verborgen contactpad doet de plicht stranden. |
| Melders niet bestraffenNorm voor onderzoek te goeder trouw | Geen letterlijke CRA-bepaling. De CRA omschrijft CVD als gestructureerde melding en noemt bug-bountyprogramma's als een manier om meldingen te stimuleren. ISO/IEC 29147 en de ENISA-richtsnoeren behandelen safe harbour voor onderzoek te goeder trouw als een normaal onderdeel van een CVD-beleid. | Het voorbehouden van juridische stappen tegen onderzoek te goeder trouw binnen scope doet het meldkanaal instorten, ook als er een contactadres bestaat. |
Voor het bredere kader (de acht genummerde plichten waarvan CVD er één is), zie vulnerability handling.
Het centrale contactpunt
Het CVD-beleid werkt alleen als melders een echt contact vinden en een menselijke route naar de fabrikant hebben. De plicht in de CRA om één centraal contactpunt aan te wijzen, vertaalt zich in drie concrete vereisten :
- Gemakkelijk te identificeren. Het contactpunt moet eenvoudig te vinden zijn in de productinformatie en in de gebruiksaanwijzing die het product vergezelt. Een contactpunt dat alleen vindbaar is door het privacybeleid te lezen, voldoet niet aan deze toets.
- Meerdere kanalen. "Communicatiemiddelen van hun voorkeur kiezen" betekent ten minste twee. Een werkende
security@-mailbox plus een webformulier, met een PGP-sleutel beschikbaar voor gevoelige meldingen, is de realistische basislijn. - Geen alleen-bot-intake. "Beperkt die middelen niet tot geautomatiseerde hulpmiddelen" sluit een opstelling uit waarin het enige bereikbare adres
security-noreply@is of een chatbot die tickets sluit zonder menselijke beoordeling.
De CRA vereist geen scheiding tussen consumentenondersteuning en kwetsbaarheidsintake, maar de meeste fabrikanten beheren een speciale beveiligingsinbox die naar het productbeveiligingsteam wordt gerouteerd, om CVD gescheiden te houden van algemene ondersteuning.
Uw CVD-beleid publiceren: security.txt en verder
De CRA noemt security.txt, RFC 9116 of enig ander specifiek publicatieformaat niet. Zij vereist een contactkanaal dat "gemakkelijk te identificeren" is en een CVD-beleid dat "is ingevoerd en wordt gehandhaafd". Binnen die grenzen heeft de sector security.txt als de facto conventie omarmd.
RFC 9116-velden die de moeite waard zijn om te publiceren:
| Veld | Doel |
|---|---|
Contact: |
Eén of meer meldkanalen. Ten minste één is verplicht. |
Expires: |
Datum waarna het bestand verouderd is. Verplicht volgens RFC 9116. |
Encryption: |
Publieke sleutel (PGP, S/MIME) voor vertrouwelijke meldingen. |
Acknowledgments: |
Pagina waarop onderzoekers worden gecrediteerd voor eerdere openbaarmakingen. |
Policy: |
Link naar het volledige CVD-beleidsdocument. |
Preferred-Languages: |
Talen waarin uw triageteam werkt. |
Canonical: |
URL waar het bestand naar verwachting staat. |
Waar het te hosten. De gebruikelijke locatie is https://example.com/.well-known/security.txt, geserveerd via HTTPS. RFC 9116 aanvaardt ook https://example.com/security.txt als terugval, maar well-known heeft de voorkeur.
Verder dan security.txt. De norm "gemakkelijk te identificeren" houdt in dat het contactpunt ook moet verschijnen op de productondersteunings- of contactpagina, in de gebruiksaanwijzing die het product vergezelt, in de ontwikkelaarsdocumentatie voor API-producten en op een publieke CVD-beleidspagina waarnaar onderzoekers kunnen verwijzen.
Fabrikanten die bug-bountyprogramma's voeren, voegen doorgaans HackerOne, Bugcrowd of Intigriti toe als aanvullend meldkanaal. Die kanalen voldoen aan de plicht om melden te vergemakkelijken en de plicht om niet tot geautomatiseerde hulpmiddelen te beperken alleen als zij open staan voor externe melders met menselijke reactie. Een private, alleen-op-uitnodiging-bounty voldoet op zichzelf niet aan de vereiste voor een publiek contactpunt en moet naast een publiek kanaal bestaan.
Kwetsbaarheidsmeldingen ontvangen en triëren
Een CVD-beleid wordt gehandhaafd via een gedocumenteerde intake- en triageworkflow. De onderstaande mechanismen zijn niet door de CRA voorgeschreven, maar zo ziet een handhaafbaar beleid er in de praktijk uit.
| Fase | Wat een handhaafbaar beleid doet | Veelvoorkomende fout |
|---|---|---|
| Bevestiging | Ontvangst bevestigen binnen de gepubliceerde SLA. De basislijn in de sector is 72 uur; veel beleidsregels verbinden zich tot 24 of 48 uur voor meldingen van hoge ernst. Wat u publiceert, doet u ook. | "Wij reageren zo snel mogelijk" is op het eerste gezicht onhandhaafbaar. |
| Triage | Valideer (reproduceerbaar op een ondersteunde versie), beoordeel ernst (CVSS v3.1 of v4.0 met omgevingsaanpassingen, zie severity scoring), beoordeel uitbuitbaarheid (bekende exploit, publieke PoC of bewijs in het wild, wat de regelgevende escalatie aanjaagt), en baken af op getroffen versies via de SBOM. | Sluiten als "niet reproduceerbaar" zonder het geteste versiebereik te noemen. |
| Relatie met de melder | Publiceer drie zaken: een safe-harbourbepaling voor onderzoek te goeder trouw binnen scope; buiten-scope-items (productiedata, social engineering, denial-of-service tegen live-infrastructuur); en openbaarmakingsverwachtingen (embargoperiode, herstelvoorwaarden, naamsvermelding). Typisch embargo: tot de patch uitkomt, harde achtervang van 90 dagen. | Het recht voorbehouden om juridische stappen te ondernemen tegen onderzoek binnen scope, waardoor het kanaal instort. |
| De cirkel sluiten | Elke melding krijgt een eindreactie: hersteld (met advies en CVE), duplicaat, wordt niet hersteld (met redenering) of buiten scope. | Eenmalig bevestigen en daarna zwijgen; de meest voorkomende reden waarom CVD-beleid van buitenaf niet gehandhaafd lijkt. |
Coördinatie met ENISA en externe onderzoekers
CVD-intake en ENISA-melding zijn verschillende verplichtingen met verschillende doelgroepen. Het CVD-beleid regelt uw relatie met de melder. De regelgevende melding regelt uw plicht jegens ENISA en de coördinerende CSIRT. Ze lopen parallel en worden anders getriggerd.
Wanneer een CVD-melding een regelgevende trigger wordt. Fabrikanten moeten "elke actief uitgebuite kwetsbaarheid" via het SRP melden in een cadans van 24 uur, 72 uur en 14 dagen. De trigger is "actief uitgebuit", niet "gemeld". Een CVD-intake met een werkend proof-of-concept is op zichzelf geen regelgevende trigger; het wordt dat wanneer er betrouwbaar bewijs bestaat dat een kwaadwillende actor de kwetsbaarheid in een systeem heeft uitgebuit zonder toestemming.
Ernstige incidenten volgen een andere cadans: 24 uur, 72 uur, en daarna een eindrapport binnen een maand na de 72u-kennisgeving. De twee stromen delen de vroege fasen en lopen uiteen op de eindrapportage. Voeg ze niet samen tot één "24u/72u/14d"-formulering. Zie vulnerability reporting.
ENISA en als coördinator aangewezen CSIRTs. Indiening gebeurt via het SRP via het elektronische endpoint van de CSIRT die als coördinator is aangewezen in de lidstaat van de hoofdvestiging van de fabrikant. Fabrikanten kunnen meldingen rechtstreeks ontvangen, of indirect via een onder de NIS2-richtlijn als coördinator aangewezen CSIRT. Voor de mechanismen rond SRP-onboarding, zie ENISA SRP onboarding.
Coördinatie met onderzoekers. Wanneer een onderzoeker een embargo aanbiedt terwijl u een herstel uitrolt, documenteer dan de overeengekomen periode en respecteer die. Wanneer de onderzoeker weigert of vroegtijdig publiceert, moet uw CVD-beleid bepalen hoe u reageert, doorgaans door het advies en de patch te versnellen.
Timing van publieke openbaarmaking
Publieke openbaarmaking van een verholpen kwetsbaarheid is niet optioneel onder de CRA. Zodra een beveiligingsupdate beschikbaar is gesteld, moeten fabrikanten informatie delen en openbaar maken over de verholpen kwetsbaarheid, waaronder een beschrijving, informatie aan de hand waarvan gebruikers het getroffen product kunnen identificeren, de gevolgen, de ernst en duidelijke informatie om de kwetsbaarheid te verhelpen. Uitstel is toegestaan "in naar behoren gemotiveerde gevallen" wanneer de beveiligingsrisico's van openbaarmaking zwaarder wegen dan de voordelen, maar alleen "totdat de gebruikers de mogelijkheid hebben gekregen de desbetreffende patch uit te voeren".
Embargoperiodes. De de facto industriestandaard is 90 dagen van melding tot publieke openbaarmaking, gerekend vanaf de datum waarop de fabrikant voor het eerst werd ingelicht. Project Zero, CERT/CC en de meeste nationale CSIRT's hanteren dat ankerpunt of zitten er dichtbij. Voor actief uitgebuite kwetsbaarheden krimpt de periode doorgaans tot enkele dagen, omdat het regelgevende eindrapport vereist is binnen 14 dagen nadat een corrigerende maatregel beschikbaar komt.
Formaat van publieke openbaarmaking. Een CRA-conform advies moet minimaal bevatten: een CVE-ID, een duidelijke beschrijving, getroffen product en versiebereik, ernst (CVSS-basisscore), gevolgen, herstel en naamsvermelding wanneer de melder daarmee heeft ingestemd. CSAF (Common Security Advisory Framework) is de machineleesbare drager die de meeste nationale CSIRT's en de kwetsbaarhedendatabase van ENISA verwachten.
Het "naar behoren gemotiveerde" uitstel is beperkt. Het staat toe publieke details achter te houden totdat gebruikers kunnen patchen; het staat geen stille herstelacties toe die nooit worden gepubliceerd. Een fabrikant die een patch uitbrengt en nooit beschrijft wat die verhelpt, schendt de publieke-openbaarmakingsplicht, ongeacht intentie.
Veelgemaakte fouten
| Valkuil | Waarom dit de CRA schendt |
|---|---|
| Juridische dreigingen aan onderzoekers te goeder trouw | Doorbreekt de plicht om "een beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden te handhaven" en ontmoedigt het meldkanaal dat dezelfde plicht vereist. |
| Geen publiek contactkanaal, alleen een interne portaallogin | Schendt de plicht van "gemakkelijk te identificeren" voor het centrale contactpunt en de plicht om "een contactadres te verstrekken". |
security-noreply@-autoresponder zonder menselijke triage |
Het centrale contactpunt mag de communicatiemiddelen niet tot geautomatiseerde hulpmiddelen beperken. |
| Ontvangst bevestigen en daarna niet meer reageren | Het beleid is "ingevoerd" maar niet "gehandhaafd"; beide zijn vereist. |
| Meldingen sluiten als "wordt niet hersteld" zonder redenering | Voor de buitenwereld niet te onderscheiden van het negeren van de melding; onderzoekers escaleren door te publiceren. |
| Beveiligingsfixes bundelen in functiereleases die gebruikers uitstellen | Beveiligingsupdates moeten scheidbaar zijn van functionaliteitsupdates "indien technisch haalbaar". |
| Stilzwijgend patchen zonder advies | Schendt de plicht tot publieke openbaarmaking. |
| CVD-intake behandelen als de ENISA-indiening | Verschillende doelgroepen, verschillende verplichtingen. CVD ontslaat niet van regelgevende melding, en regelgevende melding ontslaat niet van CVD. |
Veelgestelde vragen
Hebben kleine fabrikanten een CVD-beleid nodig onder de CRA?
Ja. De CVD-beleidsplicht kent geen omvangsdrempel. Zij geldt voor elke fabrikant die een product met digitale elementen op de EU-markt brengt, ongeacht het aantal werknemers of de omzet. Micro-ondernemingen en kleine ondernemingen genieten een beperkte boete-ontheffing op de 24-uurstermijnen voor de vroege waarschuwing, maar die ontheffing raakt alleen [die boetes](/cra-compliance/penalties-and-enforcement), niet de onderliggende plicht, en strekt zich niet uit tot middelgrote ondernemingen. Een firmwareleverancier van twee personen heeft een gepubliceerd CVD-beleid, een contactkanaal en een triageproces nodig, op dezelfde manier als een grote leverancier.
Is `security.txt` verplicht onder de CRA?
Nee. De CRA noemt security.txt of RFC 9116 niet. Zij vereist een "gemakkelijk te identificeren" centraal contactpunt en een contactadres voor kwetsbaarheidsmelding. security.txt is de de facto conventie om aan die plichten te voldoen, omdat geautomatiseerde scanners en de meeste onderzoekers daar als eerste kijken, maar een contact dat prominent op een publieke beveiligingspagina en in de gebruiksaanwijzing die het product vergezelt staat, is ook conform. De harde vereiste is een gepubliceerd, werkend, voor mensen bereikbaar kanaal; het formaat is een keuze.
Kan de CVD-intake hetzelfde kanaal zijn als de ENISA-indiening?
Nee. Het zijn verschillende doelgroepen en verschillende verplichtingen. CVD-intake is het kanaal waarlangs externe onderzoekers en gebruikers kwetsbaarheden aan de fabrikant melden. De ENISA-indiening is de regelgevende melding van de fabrikant aan ENISA en de coördinerende CSIRT, gedaan via het centrale meldingsplatform. Een onderzoeker dient niet bij het SRP in; de fabrikant doet dat. Het samenvoegen leidt tot ofwel het niet bevestigen van een onderzoeker (CVD-schending) of het niet melden aan ENISA wanneer uitbuiting is bevestigd (serieuze handhavingsblootstelling).
Wat gebeurt er wanneer een externe onderzoeker een actief uitgebuite kwetsbaarheid meldt?
Twee klokken starten tegelijkertijd. Het CVD-proces regelt de relatie met de onderzoeker: ontvangst bevestigen, triëren, een embargo overeenkomen, een herstel uitbrengen, een advies publiceren, de melder crediteren. Het regelgevende proces regelt de relatie met ENISA en de coördinerende CSIRT: een vroege waarschuwing van 24 uur, een kennisgeving van 72 uur en een eindrapport binnen 14 dagen nadat een corrigerende maatregel beschikbaar komt. De 24-uursklok start wanneer de fabrikant zich ervan bewust wordt dat de uitbuiting actief is, wat het moment kan zijn waarop het bewijs van de onderzoeker die conclusie geloofwaardig maakt. Wachten op forensische zekerheid doet de deadline missen. De twee processen lopen parallel en eindigen op verschillende oppervlakken.
Moet het CVD-beleid juridische safe harbour aan onderzoekers bieden?
Nee, de CRA vereist geen expliciete safe-harbourclausule. De CRA omschrijft CVD als een gestructureerd meldingsproces en noemt bug-bountyprogramma's als een manier om meldingen te stimuleren; zij codificeert geen safe harbour of vermindering van juridisch risico voor onderzoekers. De norm komt uit de praktijk in de sector en niet uit de verordening: ISO/IEC 29147, ENISA-richtsnoeren en de meeste nationale CSIRT-aanbevelingen convergeren op een schriftelijke safe-harbourclausule voor onderzoek te goeder trouw binnen de gepubliceerde scope. Een beleid dat het recht voorbehoudt om juridische stappen te ondernemen tegen onderzoek binnen scope, doet het kanaal instorten en faalt in de praktijk op de "handhaven"-helft van de CVD-beleidsplicht.