Cyber Resilience

Kildekode leveret til kunden: Kommissionen regner den også som et produkt

Kildekode leveret til kunden: Kommissionen regner den også som et produkt

Licenserer I kildekode til en kunde som led i forretningen, lægger Kommissionen til grund, at koden er bragt i omsætning efter Cyber Resilience Act, også selv om kunden selv tilpasser og kompilerer den. Grundlaget er Kommissionens vejledning, og den danske lovtekst siger noget andet ordret, så forbeholdet hører med.

Leverandørens ansvar stopper ved det, der er leveret. Hvad kunden bygger videre, svarer kunden selv for.

Hvad den danske tekst siger

Artikel 3, nr. 4, i den danske udgave af forordning (EU) 2024/2847 definerer software som den del af et elektronisk informationssystem, der består af maskinkode. Ordet kildekode står ikke i den danske definition.

Den engelske udgave bruger udtrykket computer code. Kommissionens vejledning C(2026) 5252 læser det i punkt 22 som både maskinkode og kildekode. Vejledningen er ikke bindende, og kun EU-Domstolen kan fastslå, hvordan definitionen skal forstås. Indtil der er en afgørelse, er det rimeligt at planlægge efter Kommissionens læsning, men forbeholdet bør stå i jeres egen dokumentation.

Kode som produkt

Vejledningens punkt 24 siger, at det at levere kode til kunder som et produkt er at bringe den i omsætning, hvad enten det er maskinkode eller kildekode. Formen ved overdragelsen er uden betydning. Det afgørende er, at koden leveres som led i en forretning.

Eksempel 7 i vejledningen er skrevet til netop den situation. Virksomhed A licenserer kildekode til virksomhed B som tekstfiler til en intern platform, B kan tilpasse. B skal selv tilpasse og kompilere koden. Alligevel bringer A koden i omsætning og er omfattet. Eksemplet tilføjer, at A ikke svarer for B’s efterfølgende tilpasning og kompilering.

Hvor ansvaret stopper

Eksempel 7 trækker grænsen ved leverancen. Det, A leverer, skal opfylde kravene. Det, B gør med koden bagefter, er B’s sag. Bliver B’s tilpassede udgave til et produkt, som B selv bringer i omsætning, har B fabrikantens pligter for det.

For leverandøren betyder det, at risikovurderingen, den tekniske dokumentation og sårbarhedshåndteringen skal dække den kode, der er leveret, som den er leveret. Brugeroplysningerne bør efter vores vurdering forklare, hvilke dele kunden typisk ændrer, og hvilke sikkerhedsegenskaber der kan gå tabt ved en ændring. Det sidste er vores tolkning af kravene til brugeroplysninger i bilag II.

Kode, der ikke er bragt i omsætning

Vejledningens punkt 23 nævner tre tilfælde, hvor kode som udgangspunkt ikke bringes i omsætning.

  • Open source-kode delt i offentlige repositorier · Ikke bragt i omsætning
  • Ufærdig kode delt til test eller review under udviklingen · Ikke bragt i omsætning
  • Eksempel- og demokode i vejledninger og undervisningsmateriale · Ikke bragt i omsætning

Kodeeksempler i jeres dokumentation og en testudgave sendt til en samarbejdspartner under udviklingen falder altså normalt uden for. En licenseret kodebase til en betalende kunde gør ikke.

Produktansvaret er en anden sag

Vejledningens fodnote 9 peger på en forskel til produktansvarsdirektivet (EU) 2024/2853. Efter direktivet er kode i sig selv ikke et produkt, og betragtning 13 i direktivet omtaler den rene kildekode. Fodnoten tilføjer, at det ikke udelukker ansvar efter national erstatningsret. To regelsæt kan altså trække grænsen forskelligt for den samme kode. Dette er ikke juridisk rådgivning om produktansvar, og spørgsmålet hører hjemme hos en jurist.

Hvad det betyder for leverancen

Et softwarehus, der leverer kildekode, bør behandle hver leverance som en version af et produkt. Det indebærer en identifikation af leverancen (artikel 13, stk. 15, kræver type-, parti- eller serienummer eller anden identifikation), en komponentliste over de tredjepartskomponenter, koden indeholder, og en plan for, hvordan rettelser når kunden.

Det sidste er ofte det sværeste. Har kunden ændret i koden, kan en rettelse ikke uden videre lægges ovenpå, og det bør aftalen tage højde for. Forordningen siger intet om aftalen, så hvordan det beskrives, er praksis.

Et tænkt eksempel

Et softwarehus sælger en løsning til lagerstyring. To store kunder har ikke det færdige program, men en licens til kildekoden, som deres egne udviklere tilpasser. Softwarehuset har hidtil set de to leverancer som projekter. Efter Kommissionens læsning er hver leverance en version, der er bragt i omsætning. Softwarehuset skal derfor kunne sige, hvilken version hver kunde fik, hvilke tredjepartskomponenter den indeholdt, og hvordan en sikkerhedsrettelse når frem. Hvad de to kunder senere ændrer, ligger uden for softwarehusets ansvar, men rettelsen til den oprindelige kode skal stadig kunne leveres. Eksemplet er tænkt.

Hvad det kræver, og hvad det koster at lade være

Det kræver, at kildekodeleverancer får de samme processer som jeres øvrige produkter, fra risikovurdering til sårbarhedshåndtering, og at hver leverance kan identificeres. Kravene gælder fra 11. december 2027.

Behandler I kildekode som en konsulentydelse uden produktproces, står I uden bevis, hvis Kommissionens læsning holder. Vejledningen er det fælles materiale, myndighederne i EU har at gå ud fra.

Det skal I lade være med

  • At skrive, at den danske lovtekst nævner kildekode · den siger maskinkode, og kildekode bæres af vejledningen.
  • At regne kildekode for undtaget, fordi kunden kompilerer · vejledningens eksempel 7 siger det modsatte.
  • At påtage jer ansvar for kundens tilpasninger · grænsen går ved det, I har leveret.

Det skal auditten kunne vise

  • ☐ En liste over kunder, der modtager kildekode, og hvilke versioner de har.
  • ☐ En identifikation af hver kildekodeleverance.
  • ☐ Risikovurdering og dokumentation, der dækker koden, som den leveres.
  • ☐ En beskrevet vej for rettelser til kunder, der har ændret koden.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find de kunder, der får kildekode fra jer, og se, om leverancerne er med i jeres produktproces.

Læs også: Hvornår er softwaren bragt i omsætning? · SaaS og kildekode

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.