Den som hittar en sårbarhet i din produkt behöver ett tydligt, mänskligt nåbart sätt att rapportera den, och ditt team behöver en skriftlig policy för hur den rapporten bekräftas, triageras, åtgärdas och redovisas. Enligt EU:s cyberresilienslag (Förordning (EU) 2024/2847) innebär det att införa och verkställa en policy för samordnad delgivning av information om sårbarheter (CVD) samt att publicera en gemensam kontaktpunkt för sårbarhetsrapporter. Det finns inget undantag för SMF. Den här sidan beskriver vad policyn måste innehålla, hur du publicerar kontaktkanalen och hur CVD samverkar med vulnerability reporting och det bredare ramverket för vulnerability handling.
Sammanfattning
- CVD-policy är obligatorisk. Skriftlig, publicerad, verkställd, utan storlekströskel. Beskrivs i Vad CRA faktiskt kräver nedan.
- En gemensam kontaktpunkt krävs. Användarna måste kunna nå en människa; kanalen får inte begränsas till automatiserade verktyg.
security.txt(RFC 9116) är den vedertagna konventionen för att publicera kontakten, men CRA föreskriver inget specifikt format.- CVD är inte samma sak som ENISA-rapportering. CVD styr din relation med rapportören; den regulatoriska klockan mot ENISA och samordnande CSIRT löper parallellt. Se Samordning med ENISA nedan.
- Offentlig redovisning av åtgärdade sårbarheter är obligatorisk, med ett snävt undantag för fördröjning där säkerhetsriskerna med offentliggörande överväger nyttan tills användarna har fått möjlighet att patcha.
- Sanktionsdetaljer hör hemma i enforcement-guiden. Se påföljder och verkställighet för sanktionsstegen och marknadsåtgärderna.
De fyra ankarpunkterna för en CRA-efterlevnadsenlig CVD-hållning: policy, kontakt, publicering och hänvisning till enforcement.
Vad CRA faktiskt kräver för CVD
CVD-kravet är kort: tillverkare ska "införa och verkställa en policy för samordnad delgivning av information om sårbarheter". Den enda meningen bär fyra operativa komponenter, som var och en kan brista på olika sätt:
| Krav | Vad det innebär i praktiken | Vanligt fel |
|---|---|---|
| InföraDokumenterad policy | En skriftlig, tillgänglig policy finns. Den anger för rapportören vad som är i scope, hur rapportering sker, vilken respons som kan förväntas och när redovisning sker. | En odokumenterad intern rutin att triagera e-post till security@ räknas inte. |
| VerkställaOperativ process | Policyn drivs, inte bara publiceras. Bekräftelsefrister, triageåtaganden och redovisningsvillkor i dokumentet hålls i praktiken. | En policy som lovar bekräftelse inom 72 timmar och som rutinmässigt tar tre veckor är inte verkställd. |
| Underlätta rapporteringTillgänglig kanal | Policyn gör det enkelt för externa rapportörer att dela information om sårbarheter: en kontaktadress, en publicerad process och en mänskligt nåbar kanal som inte är bakom inloggning eller chattbot. | En portal endast bakom inloggning, mottagning enbart via bot eller en undanstoppad kontaktväg motsvarar inte skyldighetens riktning. |
| Bestraffa inte rapportörerNorm för god tro-forskning | Inte en ordagrann CRA-bestämmelse. CRA beskriver CVD som strukturerad rapportering och nämner att bug-bounty-program kan ge incitament till rapporter. ISO/IEC 29147 och ENISA:s vägledning för god praxis behandlar safe harbour för god tro-forskning som en normal del av en CVD-policy. | Att förbehålla sig rätten till rättsliga åtgärder mot god tro-forskning inom scope får rapporteringskanalen att kollapsa även om en kontaktadress finns. |
För det bredare ramverket (de åtta numrerade plikterna varav CVD är en) se vulnerability handling.
Den gemensamma kontaktpunkten
CVD-policyn fungerar bara om rapportörer kan hitta en verklig kontakt och få en mänsklig väg in till tillverkaren. Plikten om en gemensam kontaktpunkt blir tre konkreta krav :
- Lätt identifierbar. Kontakten måste vara lätt att hitta för användarna och ska finnas i de användarinstruktioner som följer med produkten. I praktiken innebär det att kontakten syns där användarna letar, till exempel på en offentlig säkerhets- eller kontaktsida, och inte är begravd i en integritetspolicy.
- Flera kanaler. "Välja det kommunikationsmedel som de föredrar" betyder 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. - Ingen mottagning enbart via bot. "Får inte begränsa sådana medel 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årbarhetsmottagning separeras, men de flesta tillverkare driver en dedikerad säkerhetsinkorg dirigerad till produktsäkerhetsteamet för att hålla CVD åtskild 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 som krävs är en kontaktkanal som är "lätt identifierbar" och en CVD-policy som är "införd och verkställd". Inom dessa ramar har branschen konvergerat kring security.txt som vedertagen konvention.
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 godkänner ä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å produktsupport- eller kontaktsidan, i de användarinstruktioner som följer med produkten, 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 plikten att "underlätta rapportering" och plikten att "inte begränsas till automatiserade verktyg" endast 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 verkställs genom ett dokumenterat mottagnings- och triageflöde. Mekaniken nedan föreskrivs inte av CRA, men det är så en verkställd policy ser ut i praktiken.
| Fas | Vad en verkställd policy gör | Vanligt fel |
|---|---|---|
| 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" går inte att verkställa på sin egen ordalydelse. |
| Triage | Validera (reproducerbar på en version som stöds), bedöm allvarlighetsgrad (CVSS v3.1 eller v4.0 med miljöjusteringar, se severity scoring), bedöm utnyttjningsbarhet (känd exploatering, offentlig PoC eller bevis för utnyttjande i vilt, vilket är porten till regulatorisk eskalering), och avgränsa till påverkade versioner via SBOM. | Att 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 live-infrastruktur); och redovisningsförväntningar (embargofönster, korrigeringsvillkor, erkännande). Typiskt embargo: tills patchen levereras, hårt stopp 90 dagar. | Att förbehålla sig rätten att vidta rättsliga åtgärder mot forskning inom scope, vilket får kanalen att kollapsa. |
| Avsluta loopen | Varje rapport får ett slutsvar: åtgärdad (med advisory och CVE), dubblett, åtgärdas ej (med motivering) eller utanför scope. | Att bekräfta en gång och sedan bli tyst, den vanligaste orsaken till att en CVD-policy inte ser verkställd ut utifrån. |
Samordning med ENISA och externa forskare
CVD-mottagning och ENISA-rapportering är olika skyldigheter med olika mottagare. CVD-policyn styr din relation med rapportören. Den regulatoriska anmälan styr din plikt mot ENISA och samordnande CSIRT. De löper parallellt och de utlöses på olika sätt.
När en CVD-rapport blir en regulatorisk utlösare. Tillverkare ska anmäla "alla aktivt utnyttjade sårbarheter" via SRP i en kadens på 24 timmar, 72 timmar och 14 dagar. Utlösaren är "aktivt utnyttjad", inte "rapporterad". En CVD-mottagning med en fungerande proof-of-concept är inte i sig en regulatorisk utlösare; den blir det när det finns tillförlitliga bevis på att en angripare har exploaterat sårbarheten i ett system utan tillstånd.
Allvarliga incidenter följer en annan kadens: 24 timmar, 72 timmar, därefter 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 vulnerability reporting.
ENISA och CSIRT-enheter som utsetts till samordnare. Anmälan lämnas via SRP med den elektroniska slutpunkten för den CSIRT-enhet som utsetts till samordnare i den medlemsstat där tillverkarens huvudsakliga verksamhetsställe finns. Tillverkare kan ta emot rapporter direkt eller indirekt via en CSIRT-enhet som utsetts till samordnare enligt NIS2-direktivet. För SRP-onboardingmekanik, se ENISA SRP onboarding.
Forskarsamordning. När en forskare erbjuder ett embargo medan du levererar en korrigering, 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 offentlig redovisning
Offentlig redovisning av en åtgärdad sårbarhet är inte valfri enligt CRA. När en säkerhetsuppdatering har gjorts tillgänglig ska tillverkare dela och offentligt redovisa en beskrivning av sårbarheten, information som gör det möjligt för användarna att identifiera den berörda produkten, konsekvenserna, allvarlighetsgraden och tydlig vägledning för åtgärd. En fördröjning är tillåten "i vederbörligen motiverade fall" där säkerhetsriskerna med offentliggörande är större än fördelarna, men bara "till dess att användarna har fått möjlighet att använda den relevanta programfixen".
Embargofönster. Den vedertagna branschstandarden är 90 dagar från rapport till offentlig redovisning, räknat 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 vanligen till dagar, eftersom den regulatoriska slutrapporten ska lämnas inom 14 dagar från att en korrigeringsåtgärd blivit tillgänglig.
Format för offentlig redovisning. 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), konsekvenser, åtgärd och erkännande där rapportören har godkänt att namnges. CSAF (Common Security Advisory Framework) är det maskinläsbara format som de flesta nationella CSIRT:er och ENISA:s sårbarhetsdatabas förväntar sig.
Undantaget för "vederbörligen motiverade" fördröjning är snävt. Det tillåter att hålla tillbaka offentliga detaljer 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 plikten att offentliggöra oavsett avsikt.
Vanliga fallgropar
| Fallgrop | Varför den brister mot CRA |
|---|---|
| Rättsliga hot mot god tro-forskare | Bryter mot plikten att "verkställa en policy för samordnad delgivning av information om sårbarheter" och avskräcker den mottagningskanal som samma plikt kräver. |
| Ingen offentlig kontaktkanal, bara en intern portalinloggning | Klarar inte plikten om en "lätt identifierbar" gemensam kontaktpunkt och plikten att "tillhandahålla en kontaktadress". |
security-noreply@-autosvar utan mänsklig triage |
Den gemensamma kontaktpunkten får inte begränsa kommunikationen till automatiserade verktyg. |
| Bekräfta mottagande och sedan inte svara mer | Policyn är "införd" men inte "verkställd"; båda krävs. |
| 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 | Säkerhetsuppdateringar måste kunna separeras från funktionsuppdateringar "om det är tekniskt möjligt". |
| Tysta patchar utan advisory | Bryter mot plikten att offentligt redovisa. |
| Behandla CVD-mottagning som ENISA-inlämning | Olika mottagare, olika skyldigheter. CVD undanröjer inte den regulatoriska rapporteringen, och den regulatoriska rapporteringen 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 sanktionslättnad på 24-timmars-fristerna för tidig varning, men lättnaden berör endast [dessa sanktionsavgifter](/cra-compliance/penalties-and-enforcement), inte den underliggande skyldigheten, och omfattar inte medelstora företag. En tvåpersonsleverantör av fasta program behöver en publicerad CVD-policy, en kontaktkanal och en triageprocess på samma sätt som en stor leverantör.
Är `security.txt` obligatoriskt enligt CRA?
Nej. CRA namnger varken security.txt eller RFC 9116. Det kräver en "lätt identifierbar" gemensam kontaktpunkt och en kontaktadress för sårbarhetsrapportering. security.txt är den vedertagna konvention som används för att uppfylla dessa plikter eftersom det är det automatiska skannrar och de flesta forskare kontrollerar först, men en kontakt som publiceras tydligt på en offentlig säkerhetssida och i de användarinstruktioner som följer med produkten är också efterlevnadsenlig. Det hårda kravet är en publicerad, fungerande, mänskligt nåbar kanal; formatet är ett val.
Kan CVD-mottagningen vara samma kanal som ENISA-inlämningen?
Nej. De har olika mottagare och olika skyldigheter. CVD-mottagningen är den kanal via vilken externa forskare och användare rapporterar sårbarheter till tillverkaren. ENISA-inlämningen är tillverkarens regulatoriska anmälan till ENISA och samordnande CSIRT, gjord via den gemensamma rapporteringsplattformen. 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 sanktionsnivån).
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. Den regulatoriska processen styr relationen med ENISA och samordnande CSIRT: en 24-timmars tidig varning, 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 då forskarens bevis gör den slutsatsen trovärdig. Att vänta på forensisk visshet leder till missad frist. De två processerna löper parallellt och avslutas på olika ytor.
Måste CVD-policyn erbjuda rättslig safe harbour till forskare?
Nej, CRA kräver ingen uttrycklig safe-harbour-klausul. CRA beskriver CVD som en strukturerad rapporteringsprocess och nämner bug-bounty-program som ett sätt att uppmuntra rapporter; 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 god tro-forskning inom det publicerade scopet. En policy som förbehåller sig rätten att vidta rättsliga åtgärder mot forskning inom scope får kanalen att kollapsa och misslyckas i praktiken med "verkställa"-halvan av CVD-policyplikten.