Opdateringer fra jer til kunden: leveringsvejen som testområde

Hver gang I sender en rettelse, en ny version eller en ny konfiguration til kunden, stoler kunden på, at det, der ankommer, kommer fra jer og er uændret. Den vej, opdateringen tager fra jeres udvikling til kundens drift, er derfor en del af det, kunden er afhængig af, og en NIS2-kunde kan med god grund bede om at få den belyst. Spørgsmålet hviler på NIS2-direktivets artikel 21, stk. 3, om leverandørers produktkvalitet og sikre udviklingsprocedurer, og på kundens egne regler for opdateringer.

En penetrationstest af selve produktet siger ikke meget om leveringsvejen. Skal den med, skal den stå i omfanget. Teksten er ikke juridisk rådgivning.

Hvorfor kunden spørger til leveringsvejen

Artikel 21, stk. 3, siger, at enhederne, når de vælger foranstaltninger for forsyningskædesikkerhed, skal tage hensyn til de sårbarheder, der er specifikke for hver direkte leverandør, og til den generelle kvalitet af leverandørernes produkter og cybersikkerhedspraksis, herunder sikre udviklingsprocedurer. En opdatering er det sted, hvor jeres udvikling møder kundens drift.

Styrelsen for Samfundssikkerhed (SAMSIK) har i sin vejledning om foranstaltninger, afsnit 4, et eksempel på overvejelser hos en omfattet virksomhed. Ét af spørgsmålene er, hvordan virksomheden sikrer, at leverandører, der opdaterer produktionssystemer, ikke utilsigtet bringer sårbarheder ind. Det er præcis den bekymring, der ligger bag kundens spørgsmål. → Artikel 21, stk. 3

Forordning (EU) 2024/2690 er bindende for en afgrænset kreds af digitale udbydere, blandt andet cloud, datacentre og udbydere af administrerede tjenester. Bilagets punkt 6.6.1 beder dem sikre, at sikkerhedspatches testes, før de bruges i produktion, og at de stammer fra pålidelige kilder, hvis integritet kontrolleres. Andre kunder kan bruge punkterne som skabelon, og det forklarer, hvorfor spørgsmålet om oprindelse og ændringer dukker op, selv hos kunder uden for forordningens kreds.

Leveringsvejens led

Leveringsvejen er ikke ét system. Den kan bestå af flere led, som kan ejes af forskellige parter:

Udgivelsen · hvem der kan godkende og frigive en ny version hos jer.
Opbevaringen · det sted, opdateringer ligger, indtil de hentes.
Transporten · den forbindelse, opdateringen sendes eller hentes ad.
Modtagelsen · det, der sker hos kunden, før opdateringen tages i brug.
Fjernudrulningen · hvis I selv installerer hos kunden, de konti og den adgang, I bruger til det.

Hvert led kan svigte for sig. En velbeskyttet udgivelse hjælper ikke meget, hvis opdateringerne ligger et sted, hvor andre kan lægge en fil ved siden af. Gennemgå derfor leddene, før I aftaler omfanget, og notér, hvem der ejer hvert af dem.

Hvad en test kan belyse

En test kan ikke vise, at hver opdatering er fejlfri. Den kan belyse, om leveringsvejen kan misbruges. Relevante spørgsmål er:

Hvem kan frigive · om kun de rette personer kan godkende en udgivelse, og om deres konti er beskyttet med multifaktorlogin.
Hvem kan ændre · om nogen uden for den aftalte kreds kan ændre eller udskifte en opdatering, hvor den ligger.
Hvad modtageren kontrollerer · om kundens installation afviser en opdatering, der ikke kommer fra jer i uændret stand.
Hvor langt udrulningen rækker · om de konti, der bruges til fjernudrulning, kun når det, de skal.

Den sidste del ligger tæt på jeres øvrige adgang til kunden. → Jeres supportadgang til kunden

Kontrollen af oprindelse og integritet kan være en opsætning mere end en funktion i produktet. Et fund kan derfor lige så vel ligge hos kunden som hos jer, og det skal beskrives sådan i dokumentationen.

Sådan kommer leveringsvejen ind i omfanget

Leveringsvejen kan falde uden for, når en test bestilles som en test af en applikation. Skriv den ind som et selvstændigt punkt:

Formål · at belyse, om opdateringer kan ændres eller frigives af andre end de aftalte.
Afgrænsning · hvilke led der indgår, og hvilke der ejes af andre, fx en platform, I udgiver gennem.
Testmiljø · om testen foregår mod en kopi af leveringsvejen, så ingen kunde får en ændret opdatering.
Kundens del · om kunden vil lade sin modtagelse indgå, og hvem hos kunden der godkender det.

Det sidste punkt kræver kundens tilladelse, fordi modtagelsen kører i kundens miljø. → Afgrænsning mod kundens eget miljø

Når andre ejer et af leddene

Nogle leverandører udgiver gennem en platform, de ikke selv driver, fx en kodeplatform, en cloudtjeneste eller en appbutik til udstyr. Platformens del kan I ikke teste uden platformens regler, og måske slet ikke. Det, I kan teste, er jeres egen brug af den: hvem hos jer har adgang, hvordan kontiene er beskyttet, og hvem der kan ændre det, der ligger der.

Kunden har brug for at vide, hvor grænsen går. Skriv det i dokumentationen: hvilke led der blev testet, hvilke der hører under en anden ejer, og hvad I ved om den ejers egen kontrol. Så kan kunden selv vurdere, om resten skal belyses på anden måde, fx gennem platformens egen dokumentation. → Test af noget, I ikke ejer

Et tænkt eksempel

Et softwarehus leverer styringssoftware til en fødevareproducents pakkelinjer og sender kvartalsvise opdateringer, som producentens driftsfolk selv installerer. Producenten er omfattet af NIS 2-loven og beder om dokumentation for, at opdateringerne er sikre.

Softwarehuset aftaler med sin testleverandør, at leveringsvejen indgår som eget punkt. Testen viser, at udgivelsen kun kan frigives af to navngivne udviklere med multifaktorlogin, men at den mappe, opdateringerne hentes fra, kan skrives i af en bredere gruppe hos softwarehuset. Producentens installation kontrollerer ikke, hvem der står bag filen. Softwarehuset strammer adgangen til mappen og tilbyder en kontrol af afsenderen, som producenten aktiverer. Dokumentationen beskriver begge fund og hvem der rettede hvad.

Det skal I lade være med

At antage, at produkttesten dækker leveringsvejen · de to er forskellige omfang.
At teste mod den rigtige leveringsvej uden aftale · en ændret testfil kan nå en kunde.
At glemme byggemiljøet · det sted, versionen samles, er en del af vejen.
At lade fjernudrulningens konti være fælles · så kan ingen se, hvem der installerede hvad.
At love kunden, at opdateringer er fejlfri · en test belyser vejen, ikke indholdet af hver version.

Hvad kan og ikke kan konkluderes

En test af leveringsvejen kan vise, om de testede led på testtidspunktet kunne misbruges til at ændre eller frigive en opdatering. Den kan ikke vise, at fremtidige versioner er uden sårbarheder, og den siger intet om led, der lå uden for omfanget. Kunden vurderer selv resultatet i sin leverandørstyring. Opfølgningen i form af gentagne test er beskrevet i → Et testprogram over flere år

Tjekliste til leveringsvejen

☐ Er leveringsvejens led beskrevet, og er ejeren af hvert led kendt?
☐ Er det aftalt, hvem der kan frigive en opdatering?
☐ Står leveringsvejen som eget punkt i testens omfang?
☐ Foregår testen, så ingen kunde modtager en ændret opdatering?
☐ Har kunden godkendt, hvis modtagelsen hos kunden indgår?
☐ Er det beskrevet, hvordan kunden kan kontrollere, at en opdatering kommer fra jer?

Kilder

NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 2, litra d, og stk. 3.
Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 6.6.1, litra b og c, om test og oprindelse af sikkerhedspatches.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4, eksemplet om leverandører, der opdaterer produktionssystemer.

Senest gennemgået: oktober 2026.