Bilaga I Del II led 5 i EU:s cyberresilienslag (förordning (EU) 2024/2847) kräver att varje tillverkare inför och tillämpar en policy för samordnad sårbarhetsredovisning (CVD), och Artikel 13(17) kräver en enda kontaktpunkt som är nåbar av människor för mottagande av sårbarhetsrapporter. Det finns inget undantag för SMF. Den här sidan täcker vad policyn måste innehålla, hur du publicerar kontaktkanalen och hur CVD samverkar med Artikel 14-rapportering och det bredare Bilaga I Del II-ramverket.
Sammanfattning
- CVD-policy är obligatorisk enligt Bilaga I Del II led 5: skriftlig, publicerad, tillämpad, utan storleksgräns.
- Artikel 13(17) kräver en enda kontaktpunkt för att användare ska kunna rapportera sårbarheter; kanalen får inte begränsas till automatiserade verktyg.
security.txt(RFC 9116) är den vedertagna konventionen för att publicera kontaktuppgifterna, men CRA föreskriver inget specifikt format.- CVD är inte Artikel 14-rapportering: CVD styr din relation med rapportörer; Artikel 14 är det regulatoriska rapporteringskravet till ENISA och koordinator-CSIRT när en sårbarhet aktivt utnyttjas.
- Offentliggörande av åtgärdade sårbarheter är obligatoriskt enligt Bilaga I Del II led 4, med ett snävt undantag för fördröjning när säkerhetsrisken med publicering överväger nyttan, tills användarna haft möjlighet att patcha.
- Högsta bötenivå gäller: upp till €15 000 000 eller 2,5 % av den totala globala årsomfasättningen enligt Artikel 64(2), beroende på vilket belopp som är högst.
De fyra ankarpunkterna som definierar en CRA-efterlevnadsenlig CVD-hållning: policymandatet, kontaktplikten, publikationskonventionen och botetaket.
Vad cyberresilienslagen faktiskt kräver för CVD
Bilaga I Del II led 5 är kortfattad. Ordagrant från förordning (EU) 2024/2847:
(5) införa och tillämpa en policy för samordnad sårbarhetsredovisning;
Den enda meningen innehåller fyra operativa komponenter, som var och en kan brista på olika sätt i praktiken:
Innebär att en skriftlig, tillgänglig policy finns. En odokumenterad intern rutin att triagera e-post till security@ räknas inte som en policy.
Betyder att policyn följs i praktiken, inte bara finns publicerad. Bekräftelsefristerna, triageåtagandena och redovisningsvillkoren i dokumentet måste respekteras. En policy som utlovar bekräftelse inom 72 timmar men som rutinmässigt tar tre veckor är inte tillämpad.
Är den underförstådda riktning som hela skyldigheten ska tjäna. Bilaga I Del II led 6 gör det uttryckligt: tillverkare ska "underlätta delning av information om potentiella sårbarheter", "bland annat genom att tillhandahålla en kontaktadress".
Inte i CRA-texten. Skäl 76 beskriver CVD som en strukturerad rapporteringsprocess och nämner bug-bounty-program som incitament för rapportering. Branschpraxis (ISO/IEC 29147, ENISA:s vägledning för god praxis) behandlar safe harbour för forskning i god tro som en CVD-policynorm; CRA kodifierar inte det.
För det bredare Bilaga I Del II-ramverket (de åtta numrerade skyldigheterna varav CVD är en) se CRA sårbarshetshantering.
Den enda kontaktpunkten (Artikel 13(17))
Artikel 13(17) hänger samman med Bilaga I Del II led 5 och ger det operativ form. Ordagrant:
- För denna förordnings ändamål ska tillverkare utse en enda kontaktpunkt för att ge användare möjlighet att kommunicera direkt och snabbt med dem, bland annat för att underlätta rapportering av sårbarheter i produkter med digitala element.
Tillverkare ska säkerställa att den enda kontaktpunkten är lätt identifierbar för användarna. De ska även inkludera den enda kontaktpunkten i den information och de instruktioner till användaren som anges i Bilaga II.
Den enda kontaktpunkten ska ge användare möjlighet att välja önskat kommunikationssätt och ska inte begränsa sådana möjligheter till automatiserade verktyg.
Tre regler att internalisera:
- Lätt identifierbar. Kontakten måste vara synlig i produktinformationen, i Bilaga II-medföljandesinstruktionerna och på den offentliga webbplatsen. En kontakt som bara går att nå via integritetspolicyn klarar inte detta krav.
- Flera kanaler. "Välja önskat kommunikationssätt" innebär minst två. En fungerande
security@-inkorg plus ett webbformulär, med en PGP-nyckel tillgänglig för känsliga inskickningar, är den realistiska baslinjen. - Inget bot-only mottagande. "Ska inte begränsa sådana möjligheter till automatiserade verktyg" utesluter en hållning där den enda nåbara adressen är
security-noreply@eller en chattbot som stänger ärenden utan mänsklig granskning.
CRA kräver inte att konsumentsupport och sårbarhetsrapportering separeras, men de flesta tillverkare driver en dedikerad säkerhetsinkorg dirigerad till produktsäkerhetsteamet för att hålla CVD skilt från allmän support.
Publicera din CVD-policy: security.txt och mer
CRA namnger varken security.txt, RFC 9116 eller något specifikt publiceringsformat. Det kräver en kontaktkanal som är "lätt identifierbar" och en CVD-policy som är "införd och tillämpad". Inom dessa ramar har branschen konvergerat kring security.txt som den vedertagna konventionen.
RFC 9116-fält värda att publicera:
| Fält | Syfte |
|---|---|
Contact: |
En eller flera rapporteringskanaler. Minst en krävs. |
Expires: |
Datum efter vilket filen är inaktuell. Krävs av RFC 9116. |
Encryption: |
Offentlig nyckel (PGP, S/MIME) för konfidentiella rapporter. |
Acknowledgments: |
Sida som erkänner forskare för tidigare redovisningar. |
Policy: |
Länk till det fullständiga CVD-policydokumentet. |
Preferred-Languages: |
Språk som ditt triageteam arbetar på. |
Canonical: |
URL där filen förväntas finnas. |
Var du ska vara värd för den. Den konventionella platsen är https://example.com/.well-known/security.txt, servad över HTTPS. RFC 9116 accepterar även https://example.com/security.txt som reservalternativ, men well-known är att föredra.
Bortom security.txt. Standarden "lätt identifierbar" innebär att kontakten också bör framgå på produktsupporten eller kontaktsidan, i Bilaga II-medföljandesinstruktionerna, i utvecklardokumentation för API-produkter och på en offentlig CVD-policysida som forskare kan länka till.
Tillverkare som driver bug bounties lägger vanligtvis till HackerOne, Bugcrowd eller Intigriti som ytterligare mottagningskanaler. Dessa uppfyller skyldigheten att "underlätta rapportering" (Bilaga I Del II led 6) och skyldigheten "inte begränsad till automatiserade verktyg" (Artikel 13(17)) bara om de är öppna för externa rapportörer med mänskligt svar. En privat, inbjudningsbaserad bounty uppfyller i sig inte kravet på offentlig kontakt och måste samexistera med en offentlig kanal.
Ta emot och triagera sårbarhetsrapporter
En CVD-policy tillämpas via ett dokumenterat mottagnings- och triagearbetsflöde. Mekaniken nedan föreskrivs inte av CRA, men det är hur en tillämpad policy ser ut i praktiken.
| Fas | Vad en tillämpad policy gör | Vanlig brist |
|---|---|---|
| Bekräftelse | Bekräfta mottagande inom det publicerade SLA:t. Branschbaslinjen är 72 timmar; många policyer åtar sig 24 eller 48 timmar för rapporter med hög allvarlighetsgrad. Det du publicerar är det du gör. | "Vi svarar skyndsamt" är inte verkställbart som skrivna åtaganden. |
| Triage | Validera (reproducerbar på en version som har stöd), bedöm allvarlighetsgrad (CVSS v3.1 eller v4.0 med miljöjusteringar, se allvarlighetsgradering), bedöm utnyttjningsbarhet (känd exploatering, offentlig PoC eller bevis för utnyttjning i vilt, som är porten till Artikel 14) och begränsa till påverkade versioner via SBOM. | Stänga som "kan inte reproduceras" utan att ange vilken versionsomfång som testades. |
| Forskarrelation | Publicera tre saker: ett safe-harbour-uttalande för god tro-forskning inom scope; vad som är utanför scope (produktionsdata, social ingenjörskonst, denial-of-service mot produktionsinfrastruktur); och redovisningsförväntningar (embargofönster, korrigeringsvillkor, erkännande). Typiskt embargo: tills patchen levereras, hårt stopp 90 dagar. | Att förbehålla rätten att vidta rättsliga åtgärder mot forskning inom scope, vilket kollapsar kanalen. |
| Avsluta loopen | Varje rapport får ett slutsvar: åtgärdad (med advisory och CVE), dubblett, åtgärdas ej (med motivering) eller utanför scope. | Bekräfta en gång och sedan bli tyst, den vanligaste orsaken till att CVD-policyer inte ser tillämpade ut utifrån. |
Samordning med ENISA och externa forskare
CVD-mottagning och Artikel 14-rapportering till ENISA är olika skyldigheter med olika mottagare. CVD-policyn styr din relation med rapportören. Artikel 14 styr din regulatoriska anmälan till ENISA och koordinator-CSIRT. De löper parallellt och triggas på olika sätt.
När en CVD-rapport blir en Artikel 14-utlösare. Artikel 14(1) kräver att tillverkare anmäler "varje aktivt utnyttjad sårbarhet" via SRP. Artikel 14(2) anger kadensen: 24-timmars tidig varning, 72-timmarsanmälan och en slutrapport inom 14 dagar från att en korrigeringsåtgärd blivit tillgänglig. Utlösaren är "aktivt utnyttjad", inte "rapporterad". En CVD-rapport med en fungerande proof-of-concept är inte i sig en Artikel 14-utlösare; den blir det när det finns rimlig övertygelse om att en angripare har utnyttjat bristen mot ett verkligt mål. För allvarliga incidenter enligt Artikel 14(3) och 14(4) är kadensen 24 timmar, 72 timmar och sedan en slutrapport inom en månad från 72-timmarsanmälan. De två flödena delar de tidiga faserna och divergerar på slutrapportsdelen. Kollapsa dem inte till en enda "24h/72h/14d"-ram. Se CRA Artikel 14-rapportering.
ENISA och CSIRT utsedda som koordinatorer. Artikel 14(7) kräver inlämning via SRP med den elektroniska ändpunkten för den CSIRT som utsetts som koordinator i den medlemsstat där tillverkarens huvudsakliga etablering finns. Skäl 76 förankrar den bredare ramen: tillverkare kan ta emot rapporter direkt, eller indirekt via en CSIRT som utsetts som koordinator enligt Artikel 12(1) i direktiv (EU) 2022/2555 (NIS2). För SRP-onboardingmekanik, se ENISA SRP-onboarding.
Forskarsamordning. När en forskare erbjuder ett embargo medan du levererar en korrigering ska du dokumentera det överenskomna fönstret och respektera det. Om forskaren vägrar eller publicerar i förtid bör din CVD-policy ange hur du svarar, typiskt genom att påskynda advisoryn och patchen.
Tidpunkt för offentliggörande
Offentliggörande av en åtgärdad sårbarhet är inte valfritt enligt CRA. Bilaga I Del II led 4 kräver att tillverkare, "när en säkerhetsuppdatering har gjorts tillgänglig", ska "dela och offentliggöra information om åtgärdade sårbarheter, inklusive en beskrivning av sårbarheterna, information som gör det möjligt för användare att identifiera den berörda produkten med digitala element, sårbarheternas påverkan, deras allvarlighetsgrad och tydlig och tillgänglig information som hjälper användare att åtgärda sårbarheterna". Samma led tillåter en fördröjning "i vederbörligen motiverade fall, där tillverkare anser att säkerhetsrisken med publicering överväger säkerhetsnyttan", men bara "tills användarna har getts möjlighet att tillämpa den relevanta patchen".
Embargofönster. Den faktiska branschstandarden är 90 dagar från rapport till offentliggörande, mätt från det datum då tillverkaren först underrättades. Project Zero, CERT/CC och de flesta nationella CSIRT:er arbetar på eller nära den ankarpunkten. För aktivt utnyttjade sårbarheter kollapsar fönstret vanligtvis till dagar, eftersom Artikel 14(2)(c) kräver en slutrapport inom 14 dagar från att en korrigeringsåtgärd blivit tillgänglig.
Format för offentliggörande. En CRA-anpassad advisory bör som minimum innehålla ett CVE-ID, en tydlig beskrivning, påverkad produkt och versionsomfång, allvarlighetsgrad (CVSS-baspoäng), påverkan, åtgärd och erkännande om rapportören har godkänt att namnges. CSAF (Common Security Advisory Framework) är det maskinläsbara formatet som de flesta nationella CSIRT:er och ENISA:s sårbarhetsdatabas förväntar sig.
Undantaget för "vederbörligen motiverade" fördröjning i led 4 är snävt. Det tillåter att hålla offentlig information tills användarna kan patcha; det tillåter inte tysta korrigeringar som aldrig publiceras. En tillverkare som levererar en patch och aldrig beskriver vad den åtgärdade bryter mot led 4 oavsett avsikt.
Vanliga fallgropar
| Fallgrop | Varför den brister mot CRA |
|---|---|
| Rättsliga hot mot god tro-forskare | Bryter mot "tillämpa en policy för samordnad sårbarhetsredovisning" (Bilaga I Del II led 5) och avskräcker den mottagningskanal som led 6 kräver. |
| Ingen offentlig kontaktkanal, bara en intern portalinloggning | Klarar inte Artikel 13(17) "lätt identifierbar" och Bilaga I Del II led 6 "tillhandahålla en kontaktadress". |
security-noreply@-autosvar utan mänsklig triage |
Artikel 13(17) förbjuder att begränsa kommunikation till automatiserade verktyg. |
| Bekräfta mottagande och sedan inte svara mer | Policyn är "införd" men inte "tillämpad". Bilaga I Del II led 5 kräver båda. |
| Stänga rapporter som "åtgärdas ej" utan motivering | Externt oskiljbart från att ignorera rapporten; forskare eskalerar genom att publicera. |
| Bunta ihop säkerhetskorrigeringar i funktionsreleaser som användarna skjuter upp | Bryter mot Bilaga I Del II led 2: säkerhetsuppdateringar måste kunna separeras från funktionsuppdateringar "där det är tekniskt möjligt". |
| Tysta patchar utan advisory | Bryter mot offentliggörandeplikten i Bilaga I Del II led 4. |
| Behandla CVD-mottagning som Artikel 14 ENISA-inlämning | Olika mottagare, olika skyldigheter. CVD undanröjer inte Artikel 14, och Artikel 14 undanröjer inte CVD. |
Vanliga frågor
Behöver små tillverkare en CVD-policy enligt CRA?
Ja. CVD-policyplikten har ingen storlekströskel. Den gäller varje tillverkare som släpper en produkt med digitala element på EU-marknaden, oavsett antal anställda eller omsättning. Mikroföretag och små företag får en snäv lättnad från sanktionsavgifter på 24-timmarsfristerna i Artikel 14 enligt Artikel 64(10)(a), som täcker både Artikel 14(2)(a) för aktivt utnyttjade sårbarheter och Artikel 14(4)(a) för allvarliga incidenter. Lättnaden berör endast dessa avgifter, inte den underliggande skyldigheten, och omfattar inte medelstora företag. (Bilaga I Del II led 5; Artikel 64(10)(a); Artikel 3(19).)
Är `security.txt` obligatoriskt enligt CRA?
Nej. CRA namnger varken security.txt eller RFC 9116. Det kräver en "lätt identifierbar" enda kontaktpunkt och en kontaktadress för sårbarhetsrapportering. security.txt är den vedertagna konventionen som används för att uppfylla dessa skyldigheter eftersom det är det automatiserade skannrar och de flesta forskare kontrollerar först, men en kontakt som publiceras tydligt på en offentlig säkerhetssida och i Bilaga II-instruktionerna är också efterlevnadsenlig. Det hårda kravet är en publicerad, fungerande, mänskligt nåbar kanal; formatet är ett val. (Artikel 13(17); Bilaga I Del II led 6; RFC 9116.)
Kan CVD-mottagningskanalen vara samma kanal som ENISA Artikel 14-inlämningen?
Nej. De har olika mottagare och olika skyldigheter. CVD-mottagning är den kanal via vilken externa forskare och användare rapporterar sårbarheter till tillverkaren. Artikel 14-inlämningen är tillverkarens regulatoriska anmälan till ENISA och koordinator-CSIRT, gjord via ENISA:s gemensamma rapporteringsplattform. En forskare lämnar inte in till SRP; det gör tillverkaren. Att blanda ihop de två leder antingen till att en forskare inte bekräftas (CVD-brott) eller att ENISA inte underrättas när exploatering bekräftas (exponering för högsta bötenivå). (Artikel 14(1) och 14(7); Artikel 16; Artikel 64(2).)
Vad händer när en extern forskare rapporterar en aktivt utnyttjad sårbarhet?
Två klockor startar parallellt. CVD-processen styr forskarrelationen: bekräfta mottagande, triagera, kom överens om ett embargo, leverera en korrigering, publicera en advisory, erkänn rapportören. Artikel 14-processen styr myndighetsrelationen: en 24-timmars tidig varning till ENISA och koordinator-CSIRT, en 72-timmarsanmälan och en slutrapport inom 14 dagar från att en korrigeringsåtgärd blivit tillgänglig. 24-timmarsklockan startar när tillverkaren får kännedom om att exploatering pågår, vilket kan vara det ögonblick forskarens bevis gör den slutsatsen trovärdig. Att vänta på forensisk visshet riskerar att missa fristen. De två processerna löper parallellt och avslutas på olika ytor. (Artikel 14(1) och 14(2); Bilaga I Del II led 5.)
Måste CVD-policyn erbjuda rättslig safe harbour till forskare?
Nej, CRA kräver ingen uttrycklig safe-harbour-klausul. Skäl 76 beskriver CVD som en strukturerad rapporteringsprocess och nämner bug-bounty-program som ett sätt att uppmuntra till rapportering; det kodifierar inte safe harbour eller minskning av rättslig risk för forskare. Normen kommer från branschpraxis snarare än förordningen: ISO/IEC 29147, ENISA:s vägledning för god praxis och de flesta nationella CSIRT-rekommendationer sammanfaller på en skriftlig safe-harbour-klausul som täcker forskning i god tro inom det publicerade omfånget. En policy som förbehåller sig rätten att vidta rättsliga åtgärder mot forskning inom omfånget får kanalen att kollapsa och misslyckas i praktiken med "tillämpa"-halvan av Bilaga I Del II led 5. (Skäl 76; ISO/IEC 29147; ENISA:s CVD-vägledning för god praxis.)