Hos et softwarehus, der udvikler til jer, er det udviklingsprocessen, I auditerer. Fire områder bærer kontrollen: hvordan udviklingsmiljøet er beskyttet, hvem der har adgang til jeres kode, hvordan der testes for sikkerhed, og hvem der godkender, at en version sættes i drift. Hvert område kan belægges med konkrete spor i softwarehusets egne systemer.
Artiklen er skrevet til køberen. Softwarehusets egne pligter som producent af produkter med digitale elementer er et andet emne og behandles ikke her.
Hvad forordningen bruger som målestok
Gennemførelsesforordning (EU) 2024/2690 gælder de digitale udbydere, der er nævnt i dens artikel 1. Bilagets punkt 6.2 handler om sikker udvikling og er interessant for alle købere, fordi det eksplicit omfatter den situation, hvor udviklingen er lagt ud til en anden.
Efter punkt 6.2.1 anvendes regler for sikker udvikling, både når enheden udvikler selv, og når den outsourcer udviklingen, og de dækker specifikation, udformning, udvikling, indførelse og test. Punkt 6.2.2 nævner bl.a. disse elementer, her i forkortet gengivelse:
- analyse af sikkerhedskrav allerede i specifikations- og udformningsfasen
- principper for sikker kodning
- sikkerhedskrav til udviklingsmiljøerne
- processer for sikkerhedstest gennem hele udviklingen
- beskyttelse, rensning og anonymisering af testdata
Efter punkt 6.2.3 gælder ved outsourcet udvikling også politikkerne om forsyningskæden.
Står køberen uden for forordningen, kan punkterne bruges som målestok og som tjekliste til aftalen. NIS 2-vejledningen om foranstaltninger fra Styrelsen for Samfundssikkerhed nævner, at kriterierne for valg af leverandør kan omfatte leverandørens praksis for sikkerhed, herunder procedurerne for sikker udvikling.
Ved køb: krav til det, der leveres
Punkt 6.1.2 i samme bilag handler om, hvad processerne ved erhvervelse skal omfatte. Det er bl.a. sikkerhedskrav, krav om sikkerhedsopdateringer i hele levetiden, oplysninger om hardware- og softwarekomponenter, oplysninger om sikkerhedsfunktioner og sikker konfiguration, og metoder til at validere, at kravene er opfyldt, med dokumentation af resultaterne.
Det sidste punkt er auditten i en nøddeskal. Hvis kravene ikke kan valideres, er der intet at kontrollere.
De fire områder
Kontrolpunkterne her er praksis og ikke en officiel liste.
Udviklingsmiljøet. Hvor ligger jeres kode, og hvordan er udviklingsmiljøet adskilt fra produktion? Er der brugt rigtige data i test, og er de i så fald beskyttet, renset eller anonymiseret? Forordningens punkt om testdata giver et konkret spørgsmål at stille.
Kodeadgang. Hvem hos softwarehuset kan læse og ændre jeres kode? Gælder det også konsulenter og underleverandører? Bed om en liste og om, hvordan adgangen lukkes, når en udvikler forlader projektet.
Test. Hvilke sikkerhedstest indgår i udviklingen, og hvornår? Bed om resultatet fra den seneste test af en version, der er gået i drift, og om, hvordan fundne fejl blev håndteret.
Frigivelse. Hvem godkender, at en version sættes i drift? Kan en udvikler selv frigive sin egen kode? Bed om sporet for den seneste frigivelse: hvem skrev ændringen, hvem gennemgik den, hvem godkendte den, og hvornår.
Komponenter, softwarehuset ikke selv har skrevet
Meget af den kode, et softwarehus leverer, er hentet fra andre: biblioteker, rammeværk, moduler. Forordningens punkt 6.1.2 nævner oplysninger om softwarekomponenter som noget, der hører med ved erhvervelse. Spørg derfor, om softwarehuset kan vise en oversigt over de komponenter, jeres system bygger på, og hvordan det holder øje med, at de bliver opdateret. Svaret siger noget om, hvor hurtigt en sårbarhed i en komponent kan rettes hos jer.
En stikprøve gennem én ændring
En almindelig fremgangsmåde er at vælge én ændring og følge den fra krav til drift. Et tænkt eksempel: I vælger en ændring af loginfunktionen. Softwarehuset viser kravet, ændringen i kodehistorikken, den kollega, der gennemgik koden, testresultatet og godkendelsen til drift. Mangler et af sporene, er det et fund.
Stikprøven er lille, men den viser, om processen findes i praksis. Er der tvivl, tages en ændring mere.
Jeres eget ansvar
Nogle aftaler lægger test eller godkendelse hos kunden. Er det tilfældet, skal I kunne vise jeres egen del af sporet. Kontrollér, at aftalen er klar om, hvem der godkender en frigivelse, og om softwarehuset må frigive uden jeres accept.
Hvordan ændringer i et kørende miljø håndteres hos en driftsleverandør, står under ændringsstyring hos leverandøren. Overgangen mellem udvikling og drift er ofte der, hvor ansvaret skifter hænder.
Hvad det kræver, og hvad det koster at lade være
Det kræver en aftale, der nævner sikker udvikling, test og godkendelse, og retten til at se sporene. Stikprøven kan gennemgås på et møde, hvor softwarehuset viser sine systemer.
Uden et kig på sporene ved I ikke, om jeres system er testet for sikkerhed, før det gik i drift, eller hvem der kan ændre det.
Det skal I lade være med
- At nøjes med en beskrivelse af udviklingsprocessen · følg én ændring hele vejen.
- At glemme testdata · rigtige data i test er stadig rigtige data.
- At lade frigivelse til drift være uafklaret i aftalen · skriv ned, hvem der godkender.
Det skal auditten kunne vise
- ☐ Aftalens krav til sikker udvikling, test og frigivelse.
- ☐ Beskrivelse af udviklingsmiljøet og brug af testdata.
- ☐ Liste over personer med adgang til jeres kode.
- ☐ Resultat af seneste sikkerhedstest før en frigivelse.
- ☐ Sporet for én ændring fra krav til drift.
- ☐ Hvem der godkender frigivelse, og om jeres accept kræves.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690, bilag punkt 6.1.2 og 6.2, læst 12. november 2026.
- Styrelsen for Samfundssikkerhed, Vejledning til NIS 2-loven. Implementering af cybersikkerhedsforanstaltninger, 1. udgave juni 2025, kap. 4, læst 12. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg den seneste ændring i jeres system, og bed softwarehuset vise sporet fra krav til drift.
Læs også: Sikkerhedsbilaget som auditgrundlag · Tre afgørelser om software, der gik i drift utestet
→ Kontakt · Tlf. 70 13 63 23 · Leverandøraudit hos Nielco IT
