[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:da:hvad-cra-kraever-af-jer-for-jeres-afhaengigheder-fornoeden-omhu-indberetning-opstroems-og-kendte-udnyttelige-saarbarheder":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"da","hvad-cra-kraever-af-jer-for-jeres-afhaengigheder-fornoeden-omhu-indberetning-opstroems-og-kendte-udnyttelige-saarbarheder","Hvad CRA kræver af jer for jeres afhængigheder: fornøden omhu, indberetning opstrøms og kendte udnyttelige sårbarheder, efter Kommissionens vejledning","Et softwareprodukt er mest andres kode. CRA gør fabrikanten ansvarlig for produktet som helhed og giver den tre pligter over for komponenterne i det: fornøden omhu efter artikel 13(5), indberetning af sårbarheder opstrøms og deling af rettelser efter artikel 13(6), og at bringe produktet i omsætning uden kendte udnyttelige sårbarheder. Kommissionens vejledning af 27. juli 2026, afsnit 3.4, 7.3 og 9.2, siger, hvad hver kræver, og hvad den ikke kræver: ingen dobbelte indberetninger, ingen pligt til at få jeres rettelse merget, og en definition af \\\"kendt\\\", der omfatter CVE-databasen og nyhederne.","2026-09-11","\nDet meste af et softwareprodukt med digitale elementer er kode, dets fabrikant ikke har skrevet: biblioteker, frameworks, et operativsystem, en database, en skytjeneste. Cyber Resilience Act, forordning (EU) 2024\u002F2847, gør ikke fabrikanten ansvarlig for de komponenters egen overensstemmelse. Den gør fabrikanten ansvarlig for produktet som helhed og knytter tre pligter til komponenterne i det. Artikel 13(5): udvise fornøden omhu, når de integreres. Artikel 13(6): indberette sårbarheder, I finder i dem, til deres vedligeholder, og dele de rettelser, I skriver. Bilag I, del I, punkt 2(a), læst med artikel 13(1): bringe produktet i omsætning uden kendte udnyttelige sårbarheder. Forordningen siger hver af dem i én sætning. Kommissionens vejledning af 27. juli 2026, C(2026) 5252, afsnit 3.4, 7.3 og 9.2, siger, hvad hver kræver, og denne artikel er de afsnit, med Kommissionens FAQ om gennemførelsen, version 1.4, afsnit 5.4, hvor den tilføjer noget.\n\n## Hvem der er ansvarlig for en komponent: kun den, der bringer den i omsætning\n\nPunkt 87 i vejledningen afgør det spørgsmål, som både vedligeholdere og integratorer stiller: \"Om CRA gælder for en given FOSS-komponent, afhænger alene af, om den fysiske eller juridiske person, der udgiver den, bringer den i omsætning.\" At integrere en komponent i et produkt, der tjener penge, \"har ingen indvirkning på den FOSS-komponents status\", og punkt 86 tilføjer, at fabrikanter \"ikke bliver ansvarlige for sådanne komponenters individuelle overensstemmelse med CRA, selv hvor fabrikanterne bidrager med kildekode til deres vedligeholdelse\". [Hvornår et projekt bringes i omsætning](\u002Farticles\u002Fis-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests), er et spørgsmål for dets udgiver. Hvad integratoren skylder, står i punkt 88: overensstemmelse \"for deres egne produkter med digitale elementer\", fornøden omhu efter artikel 13(5) \"over for de FOSS-komponenter, de integrerer\", og indberetningerne og rettelserne i artikel 13(6).\n\n## Fornøden omhu, artikel 13(5): beslut, hvad I behøver fra komponenten, og verificer det\n\nAfsnit 7.3 trækker linjen mellem risikovurderingen og den fornødne omhu. Risikovurderingen efter artikel 13(2) dækker produktet og de risici, der når det udefra, \"såsom eksterne netværk, miljøfaktorer eller andre eksterne forhold\", og for dem \"kræver CRA ikke, at fabrikanter kontrollerer eller styrer det eksterne miljø\", kun \"at identificere sådanne risici og afbøde dem gennem produktets design og udvikling\" (punkt 168). Eksemplet i punkt 169 er en backend, der ikke er en del af produktet, men kunne bruges til at sende det ondsindede kommandoer: Svaret ligger på produktniveau, \"kryptografisk autentificering af fjernkommandoer, verifikation af integriteten af konfigurationsændringer eller generering af sikkerhedsrelevante logfiler\", og forordningen \"pålægger ingen forpligtelser med hensyn til, hvordan backend-infrastrukturen er organiseret, bemandet eller drevet\".\n\nFornøden omhu er den anden pligt, og den \"vedrører elementer, der udgør en del af selve produktet med digitale elementer, navnlig integrerede software- eller hardwarekomponenter leveret af en tredjepart\" (punkt 170). Dens indhold står i én sætning i samme punkt: Den \"kan kun opnås ved at fastlægge, hvad produktet med digitale elementer kræver af sine komponenter for at opfylde sine cybersikkerhedsmål, og ved risikobaseret at verificere, at disse komponenter svarer til produktets behov\". Punkt 171 gør det konkret: Hvis produktet \"er afhængigt af kryptografiske funktioner, opdateringsmekanismer eller sikker kommunikation leveret af en komponent, skal fabrikanten som led i sin fornødne omhu identificere disse behov og verificere, at komponenten opfylder dem\". Dokumentationen \"kan bestå af dokumentation indhentet fra komponentfabrikanten, såsom tekniske specifikationer, sikkerhedsdokumentation eller relevant overensstemmelses- eller sikringsdokumentation\", og \"hvor det er relevant, kan fabrikanten også udføre test\".\n\nTo konsekvenser for en afhængighedsliste. For det første er fornøden omhu forholdsmæssig og specifik: Den spørger, hvad hver komponent gør for produktets sikkerhed, og kontrollerer det, ikke alt om hver pakke. Et logbibliotek og et TLS-bibliotek får ikke den samme sag. For det andet sker kontrollen \"ved integrationen\" (punkt 172), og komponenterne behandles \"som eksternt leverede komponenter, hvis egenskaber verificeres gennem fornøden omhu\", ikke omdesignes. Punkt 173: \"Hvor fabrikanten selv udvikler funktioner, skal den gennemføre de væsentlige krav direkte. Hvor fabrikanten integrerer komponenter udviklet af andre, skal den gennem fornøden omhu sikre, at disse komponenter kan anvendes på en måde, der gør produktet med digitale elementer som helhed i stand til at overholde kravene.\"\n\n## Indberetning opstrøms og deling af rettelser, artikel 13(6): fire grænser, vejledningen sætter\n\nArtikel 13(6) kræver, at en fabrikant, der identificerer en sårbarhed i en integreret komponent, indberetter den \"til den person eller enhed, der fremstiller eller vedligeholder komponenten\", og deler enhver rettelse, den udvikler. Afsnit 9.2.1 indhegner pligten på fire måder.\n\n**Kun den version, I integrerer, gennem vedligeholderens kanal, og ikke to gange.** Punkt 223: Fabrikanter \"er kun forpligtet til at indberette opstrøms for den version af komponenten, som de integrerer\"; hvor vedligeholderen har \"sikkerhedspolitikker, processer for koordineret offentliggørelse af sårbarheder eller udpegede kanaler\", går indberetningen gennem dem; og \"fabrikanter er ikke forpligtet til at indberette opstrøms, hvor de kan bekræfte, at den person eller enhed, der fremstiller eller vedligeholder en komponent, er bekendt med sårbarhedens eksistens\". Vejledningen beder fabrikanter om at tjekke \"offentligt tilgængelige sårbarhedsdatabaser, projektspecifikke sikkerhedsmeddelelser eller etablerede issue trackers, før de indberetter opstrøms\", for at spare vedligeholdere for dubletter.\n\n**Kun sårbarheder i komponenten, ikke i jeres integration af den.** Punkt 224: Pligten dækker \"de sårbarheder, der findes i selve den integrerede komponent, og ikke sårbarheder, der opstår som følge af integrationen mellem komponenten og anden kode udviklet af fabrikanten\". Hvor integrationen afslører en adfærd i komponenten, som ikke var synlig isoleret, opfordres der til at fortælle vedligeholderen det, det kræves ikke.\n\n**Ikke hvor der ingen vedligeholder er.** Punkt 225: Ingen indberetning opstrøms skyldes, \"hvor komponenten ikke længere har en vedligeholder, eller hvor fabrikanten ikke længere er afhængig af den oprindelige vedligeholder for nye versioner eller sikkerhedsrettelser\"; i stedet opfordres der til at informere komponentens brugere gennem \"eksisterende fællesskabsmekanismer (såsom mailinglister eller issue tickets) eller gennem offentlige sårbarhedsregistre\".\n\n**Del rettelsen; I skal ikke få den merget.** Punkt 226 til 229: En rettelse, I udvikler til en komponentsårbarhed, skal deles opstrøms, \"hvor det er relevant, i et maskinlæsbart format\" og for en open source-komponent \"på en måde, der er forenelig med komponentens licens\". Men fabrikanter \"er ikke efter CRA forpligtet til at sikre, at deres sikkerhedsrettelser nødvendigvis accepteres\" eller \"integreres i komponentens kodelager\", er ikke forpligtet til at acceptere vedligeholderens rettelse til gengæld, og hvor de afbøder sårbarheden ved at ændre noget andet i deres eget system, \"kræver CRA ikke, at fabrikanten deler ændringen af en anden del af systemet opstrøms\".\n\n## Hvornår en komponents sårbarhed er jeres at anmelde til myndighederne\n\nDen obligatoriske anmeldelse efter artikel 14 er en anden pligt end indberetningen opstrøms, og de to forveksles let. Vejledningens punkt 218 og FAQ 5.4 trækker linjen: En fabrikant anmelder en aktivt udnyttet sårbarhed, \"der er indeholdt i dens produkt\"; hvor en tredjepartskomponents sårbarhed \"ikke kan udnyttes i dens produkt med digitale elementer (f.eks. fordi den sårbare kode ikke kan nås)\" eller \"ikke er blevet udnyttet i dens produkt\", er den \"ikke omfattet af obligatorisk anmeldelse for denne fabrikant\". FAQ'en tilføjer, at komponentens egen fabrikant også anmelder den, \"hvis komponenten er bragt i omsætning\", og at integratoren \"stadig kan anmelde sårbarheden frivilligt efter artikel 15\". En listet CVE i en afhængighed starter altså to ting: den tilgængelighedsvurdering, der afgør, [om 24-timers uret er startet](\u002Farticles\u002Fwhen-does-the-cra-24-hour-clock-start-becoming-aware), og, hvis I har fundet noget, vedligeholderen ikke ved, indberetningen efter artikel 13(6).\n\n## Kendte udnyttelige sårbarheder i det øjeblik, I udgiver\n\nDet første væsentlige krav i bilag I, del I, punkt 2(a), er at gøre produktet tilgængeligt \"uden kendte udnyttelige sårbarheder\", og afsnit 9.2.2 besvarer de to ord, forordningen lader stå åbne. \"Udnyttelig\" er artikel 3(41): \"en sårbarhed, der har potentiale til reelt at blive anvendt af en modstander under praktiske driftsforhold\", som punkt 231 stiller over for sårbarheder, der kun kan udnyttes \"under teoretiske forhold (f.eks. i et laboratorium eller en simulering)\". \"Kendt\" er punkt 233 og 234, og det er bredt: En sårbarhed \"bør anses for kendt, når den er opført i relevante offentligt tilgængelige sårbarhedsdatabaser, såsom den europæiske sårbarhedsdatabase\" eller \"andre fremtrædende sårbarhedsdatabaser\"; når fabrikanten \"er blevet gjort bekendt med den via ikke-offentlige oplysninger, f.eks. via koordineret offentliggørelse fra en sikkerhedsforsker eller gennem fabrikantens egen interne test og analyse, herunder f.eks. ved brug af AI-baserede tjenester\"; og \"når den er blevet offentligt og fremtrædende rapporteret i pålidelige medier\".\n\nPunkt 235 holder det forholdsmæssigt: En rapport \"betyder ikke i sig selv, at den kan udnyttes i praksis eller gælder for det konkrete produkt\", fabrikanten \"skal undersøge den og bekræfte oplysningernes rigtighed og anvendelighed\", og \"der kan gå en begrænset tid mellem den første rapport om sårbarheden og dens bekræftelse\". Punkt 236 og 237 tager sig af den udgivelse, der ligger en dag ude, når en ny CVE lander i en afhængighed: Forpligtelsen \"gælder på tidspunktet for at bringe produktet i omsætning\", den er \"en risikobaseret forpligtelse\", og fabrikanten afgør på grundlag af \"sårbarhedens alvor, udnyttelighed og potentielle konsekvens\", om produktet kan bringes i omsætning, eller om sårbarheden først skal rettes, og \"kan også tage hensyn til risiciene ved at udskyde produktets frigivelse\", f.eks. hvor udgivelsen retter andre udnyttelige sårbarheder. Når først produktet er på markedet, gælder håndteringspligterne i bilag I, del II, under alle omstændigheder.\n\n## Varianter og produktfamilier\n\nEt kort afsnit, der sparer mest arbejde. Afsnit 7.4: Hvor produkter \"deler samme arkitektur, samme sikkerhedsrelevante design og samme tilsigtede formål og er udsat for de samme cybersikkerhedsrisici\", kan fabrikanten \"støtte sig til (i) én enkelt cybersikkerhedsrisikovurdering\", \"(ii) ét enkelt sæt teknisk dokumentation og (iii) én enkelt overensstemmelsesvurderingsprocedure\" og udstede \"én enkelt EU-overensstemmelseserklæring\", der \"klart identificerer de produktvarianter, den gælder for\" (punkt 175). Punkt 176 giver testen: Forskelle i \"farve, formfaktor, hukommelsesstørrelse eller andre ikke-sikkerhedsrelevante egenskaber\" splitter ikke familien; forskelle i \"kommunikationsgrænseflader, softwarestakke, opdateringsmekanismer eller fjernkonnektivitet\" gør, og de skal afspejles i dokumenterne.\n\n## Hvad I gemmer, pr. komponent\n\nDen registrering, der opfylder alle tre pligter, passer i den SBOM, I allerede laver til [bilag I, del II, punkt 1](\u002Farticles\u002Fdoes-the-cra-require-an-sbom), én række pr. komponent:\n\n1. Navn, integreret version og vedligeholderens sikkerhedskontakt eller offentliggørelseskanal.\n2. Hvad produktet behøver fra den for sin sikkerhed, i punkt 171's forstand: intet, eller kryptografi, opdateringer, autentificering, transport og så videre.\n3. Den dokumentation, I har for det behov, og hvornår I fik den: vedligeholderens dokumentation, en sikringsartefakt, jeres egen test.\n4. Om komponentens kendte sårbarheder kan nås i jeres produkt, og datoen for den seneste kontrol mod de databaser, punkt 233 nævner.\n5. Foretagne indberetninger opstrøms og delte rettelser, med datoer, eller bekræftelsen af, at vedligeholderen allerede vidste det.\n\nDen tabel er sagen om fornøden omhu, input til tilgængelighedsvurderingen, når en CVE dukker op, og den del af [den tekniske dokumentation](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point), en myndighed læser først, når spørgsmålet er \"vidste I det\".\n\n## Kilder\n\n- Forordning (EU) 2024\u002F2847, artikel 3(41), artikel 13(1), (2), (5) og (6), artikel 14(1), artikel 15, bilag I del I punkt 2(a) og del II punkt 1, betragtning 34.\n- Europa-Kommissionen, Kommissionens vejledning om anvendelsen af forordning (EU) 2024\u002F2847, C(2026) 5252 final af 27. juli 2026, bilag, afsnit 3.4 (punkt 85 til 88), afsnit 7.3 og 7.4 (punkt 167 til 177), afsnit 9.1 punkt 218, afsnit 9.2.1 og 9.2.2 (punkt 222 til 237).\n- Europa-Kommissionen, FAQ om Cyber Resilience Act, version 1.4 af 4. september 2026, afsnit 5.4.\n\nDette er ikke juridisk rådgivning. Afsnit 7.3 og 9.2 fylder tilsammen syv sider og besvarer afhængighedsspørgsmålet mere præcist end nogen værktøjsleverandørs side; læs dem med jeres lockfile åben.\n",1789383978076]