[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:da:den-politik-for-koordineret-offentliggoerelse-af-saarbarheder-som-cra-kraever":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"da","den-politik-for-koordineret-offentliggoerelse-af-saarbarheder-som-cra-kraever","Den politik for koordineret offentliggørelse af sårbarheder, som CRA kræver: tre bestemmelser, og en politik på én side, der opfylder dem","Bilag I, del II, punkt 5, i Cyber Resilience Act kræver, at enhver omfattet fabrikant indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder. Artikel 13, stk. 17, kræver ét kontaktpunkt til indberetninger, som er let at finde og ikke begrænset til automatiserede værktøjer; bilag II, punkt 2, kræver kontaktpunktet og politikkens placering i brugeroplysningerne; bilag VII, punkt 2, litra b, sætter begge dele i den tekniske dokumentation. Hvad hver bestemmelse beder om, hvad en politik skal sige, og hvad den ikke må love.","2026-09-11","\nAf [de otte krav til håndtering af sårbarheder](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) i bilag I, del II, i Cyber Resilience Act, forordning (EU) 2024\u002F2847, er politikken for koordineret offentliggørelse af sårbarheder den, de fleste små fabrikanter aldrig har skrevet og kan skrive på en eftermiddag. Det er også den, en forsker, en kunde og en markedsovervågningsmyndighed alle vil lede efter ved navn. Tre bestemmelser definerer den.\n\n## Bestemmelse ét: selve politikken, bilag I, del II, punkt 5\n\nFabrikanter skal \"indføre og håndhæve en politik for koordineret offentliggørelse af sårbarheder\". To udsagnsord. **Indføre**: En skriftlig politik findes og er offentliggjort der, hvor en indberetter kan finde den. **Håndhæve**: Organisationen følger den, og det betyder, at den navngiver, hvem der modtager indberetninger, hvad der derefter sker, og inden for hvilken tid.\n\nPunkt 5 foreskriver ikke indholdet. Punkt 6 ved siden af gør en del af arbejdet: Fabrikanter skal \"træffe foranstaltninger til at lette deling af oplysninger om potentielle sårbarheder i deres produkt med digitale elementer samt i tredjepartskomponenter i produktet, herunder ved at stille en kontaktadresse til rådighed for indberetning af de sårbarheder, der opdages i produktet\". Og punkt 4 fastlægger, hvad der sker, når en rettelse findes: Afhjulpne sårbarheder offentliggøres med beskrivelse, berørte produkter, virkning, alvor og hvordan brugerne afhjælper, medmindre offentliggørelse ville gøre mere skade end gavn; da kan offentliggørelsen udskydes, indtil brugerne har kunnet opdatere.\n\n## Bestemmelse to: det ene kontaktpunkt, artikel 13, stk. 17\n\nArtikel 13, stk. 17, kræver, at fabrikanter udpeger ét kontaktpunkt \"for at gøre det muligt for brugerne at kommunikere direkte og hurtigt med dem, herunder for at lette indberetning af sårbarheder\". Kontaktpunktet skal være \"let at identificere for brugerne\", indgå i brugeroplysningerne i bilag II, og det \"skal give brugerne mulighed for at vælge deres foretrukne kommunikationsmiddel og må ikke begrænse disse midler til automatiserede værktøjer\".\n\nDen sidste sætning udelukker et kontaktpunkt, der kun er en webformular eller kun en bot. En sikkerheds-e-mailadresse, ved siden af den formular eller bug bounty-platform, I også bruger, opfylder den. En PGP-nøgle eller en anden måde at sende detaljer fortroligt på kræves ikke af teksten, men er det, en indberetter forventer.\n\n## Bestemmelse tre: hvor den offentliggøres og arkiveres\n\n**Bilag II, punkt 2**: Produktets brugeroplysninger skal omfatte \"det ene kontaktpunkt, hvor oplysninger om sårbarheder i produktet med digitale elementer kan indberettes og modtages, og hvor fabrikantens politik for koordineret offentliggørelse af sårbarheder kan findes\". Politikken har altså et offentligt sted, og brugeroplysningerne peger på det.\n\n**Bilag VII, punkt 2, litra b**: [Den tekniske dokumentation](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point) indeholder \"politikken for koordineret offentliggørelse af sårbarheder, dokumentation for, at der er stillet en kontaktadresse til rådighed til indberetning af sårbarheder\". Politikken er et styret dokument med version og dato, ikke kun en webside.\n\nSamme politik er også det, [artikel 24](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software) kræver af forvaltere af open source-software, i form af en dokumenteret cybersikkerhedspolitik, der fremmer håndtering af sårbarheder og frivillig indberetning.\n\n## Hvad en politik på én side skal sige\n\n1. **Anvendelsesområde.** Hvilke produkter og versioner politikken dækker, og den [supportperiode](\u002Farticles\u002Fhow-long-is-the-cra-support-period), hvori der handles på indberetninger.\n2. **Sådan indberetter man.** Det ene kontaktpunkt: mindst en e-mailadresse, plus en eventuel formular eller platform; hvordan detaljer sendes fortroligt; hvad der skal medtages (produkt, version, trin til at genskabe, virkning).\n3. **Hvad indberetteren kan forvente.** En bekræftelse inden for en angivet frist; en vurdering og et første svar inden for en angivet frist; opdateringer, mens sårbarheden håndteres. Vælg frister, I kan holde; et løfte om 48 timer, I ikke kan holde, er værre end fem arbejdsdage, I kan.\n4. **Sådan håndterer I den.** Triage, alvor, afhjælpning \"uden unødigt ophold\" (punkt 2), en sikkerhedsopdatering adskilt fra funktionsopdateringer, hvor det er muligt, og offentliggørelsen efter punkt 4, når opdateringen er tilgængelig. Hvor indberetteren også er kilden til en aktivt udnyttet sårbarhed, løber [artikel 14's ure](\u002Farticles\u002Fwhat-you-have-to-report-under-the-cra-the-two-triggers-defined) parallelt, og politikken bør sige det.\n5. **Offentliggørelse og kreditering.** Hvornår og hvordan I offentliggør afhjulpne sårbarheder, om I krediterer indberettere, og grunden til at udskyde offentliggørelse (punkt 4: hvor sikkerhedsrisikoen ved at offentliggøre opvejer fordelen, indtil brugerne kan opdatere).\n6. **Sikker havn.** En erklæring om, at forskning i god tro inden for politikkens vilkår ikke bliver genstand for retlige skridt fra jeres side. Det kræves ikke af forordningen, og det er det, der får forskere til at indberette til jer i stedet for om jer.\n7. **Ejer og version.** Hvem der ejer politikken, dens version og dato, og hvor den gældende version er offentliggjort.\n\n## Hvad den ikke må love\n\nIkke en dusør, medmindre I har et program. Ikke en rettelse inden en dato, I ikke kontrollerer. Ikke en fortrolighed, I ikke kan holde, da artikel 14 kan kræve, at CSIRT'et underrettes, og brugerne informeres. Og ikke en påstand om, at produktet ingen sårbarheder har: Del I, punkt 2, litra a, handler om kendte udnyttelige sårbarheder ved tilgængeliggørelsen, og hele pointen med en offentliggørelsespolitik er, at nye vil blive fundet.\n\nOffentliggør den på en stabil URL, sæt den URL i brugeroplysningerne, arkivér den daterede version sammen med den tekniske dokumentation, og sæt kontaktadressen de samme tre steder. Det er tre bestemmelser opfyldt med én side.\n\n## Kilder\n\n- Forordning (EU) 2024\u002F2847, bilag I, del II, punkt 2, 4, 5 og 6; artikel 13, stk. 17 (citeret); bilag II, punkt 2 (citeret); bilag VII, punkt 2, litra b (citeret); artikel 24 for forvaltere; artikel 14 for anmeldelsesurene. Læst i EU-Tidende-teksten på EUR-Lex den 11. september 2026.\n\nDette er ikke juridisk rådgivning. De tre bestemmelser er korte nok til at indsætte i politikkens egen præambel, og det er der, en omhyggelig læser vil lede efter dem.\n",1789383976700]