Sikkerhedsaudit

Afgrænsning af sikkerhedsauditten hos en softwarefabrikant: kodelager, byggesystem og opdateringsserver

Afgrænsning af sikkerhedsauditten hos en softwarefabrikant: kodelager, byggesystem og opdateringsserver

Hos en virksomhed, der udvikler og udgiver software, står nogle af de vigtigste systemer bag produktet: kodelageret, byggesystemet og serveren, kunderne henter opdateringer fra. De er virksomhedens egne systemer, og de bør stå i omfanget, når virksomheden får en sikkerhedsaudit. Produktets egenskaber hører derimod ikke med, og rapporten skal sige det.

Artiklen viser, hvor grænsen går, hvorfor den går der, og hvordan den skrives ind i opdraget og rapporten.

Hvorfor systemerne hører til virksomheden

NIS 2-loven gælder de net- og informationssystemer, en enhed bruger til sine operationer eller til at levere sine tjenester (§ 6, stk. 1). For et softwarehus er udvikling og udgivelse kernen i driften. Kodelager og byggesystem er derfor efter vores tolkning en del af det, en NIS2-audit skal se på.

Forordningen om cyberrobusthed (CRA) peger samme vej fra den anden side. Kommissionen skriver i sin vejledning af 27. juli 2026, at pipelines til kontinuerlig integration og levering ikke er fjerndatabehandling og derfor står uden for produktet. Det samme gælder systemer til audit og test. Vejledningen er ikke bindende, men den bekræfter, at de systemer, produktet bliver bygget med, ikke er produktet selv.

Er virksomheden ikke omfattet af NIS 2-loven, er logikken den samme i en frivillig audit. Her vælger I selv omfanget, og hvordan det gøres, står i afgrænsning af en sikkerhedsaudit uden lovkrav.

Den del, der hører til begge

Ikke alle servere er så lette at placere. Den backend, et produkt har brug for for at udføre sine funktioner, kan være fjerndatabehandling og hører i så fald med til produktet. Den skal med i produktets risikovurdering og dokumentation efter Kommissionens vejledning.

Samtidig er de samme servere en del af virksomhedens drift. Det er vores tolkning, at de derfor skal ses fra to sider. Audit af virksomheden ser på driften: adgang, opdatering, logning, backup og leverandører. Gennemgangen af produktet ser på, hvad serverne gør for produktets sikkerhed. Hvilke dele af en backend der tæller med, er gennemgået under fjerndatabehandling og produktets backend.

Hvad auditten ser efter i de tre systemer

Det følgende er praksis og kan tilpasses virksomhedens risikovurdering.

Kodelageret. Hvem har skriveadgang, og bliver adgangene gennemgået? Er privilegerede konti beskyttet med flerfaktor? Kan det ses, hvem der har ændret hvad? Er der backup, og er gendannelsen prøvet?

Byggesystemet. Er det adskilt fra resten af driften? Hvem kan ændre byggeopskrifterne? Hvor ligger de hemmeligheder, byggesystemet bruger, fx nøgler til signering, og hvem kan nå dem?

Opdateringsserveren. Hvem kan lægge en pakke ud? Bliver det logget? Hvad sker der, hvis serveren bliver kompromitteret, og er det med i beredskabsplanen?

Ligger systemerne hos en ekstern platform eller udbyder, hører aftalen og udbyderens dokumentation med i leverandørstyringen. Auditten nævner ikke, hvilken platform der er god eller dårlig. Den ser efter, om virksomheden har vurderet sin egen.

Når noget går galt i byggekæden

En kompromittering af byggesystem eller opdateringsserver kan føre til, at ondsindet kode når ud i produktet hos kunderne. Efter artikel 14, stk. 5, litra b, er en hændelse med den virkning en alvorlig hændelse, som fabrikanten skal indberette. Den pligt gælder siden 11. september 2026. At netop disse systemer er omfattet, står ikke i forordningen og er en tolkning. Hvordan den slags hændelser vurderes, er gennemgået under alvorlig hændelse i kodelager, byggemiljø eller opdateringsserver.

For auditten betyder det, at beredskabet omkring de tre systemer også skal kende indberetningsvejen efter CRA. Hvordan beredskabet prøves, står under CRA-indberetningen i beredskabsauditten.

Det, auditten ikke dækker

Auditten tager ikke stilling til produktets egenskaber efter bilag I, til risikovurderingen for produktet, til den tekniske dokumentation eller til, om produktet kan CE-mærkes. Den er hverken en overensstemmelsesvurdering eller en erklæring. Hvad en gennemgang af selve produktet er, står under CRA-gennemgang af et softwareprodukt.

Opdraget og rapporten

Skriv i opdraget, at kodelager, byggesystem og opdateringsserver er med, og at produktets egenskaber er holdt ude. Skriv også, hvilke servere der både er drift og fjerndatabehandling, så auditor ved, hvilken side der skal belyses. Hvordan et opdrag kan stilles op, står i opdraget på én side.

Rapporten bør gentage forbeholdet i klare ord: den udtaler sig om virksomhedens systemer og ikke om produktets overensstemmelse med CRA. Så kan en kunde ikke læse den som en udtalelse om produktet.

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

Det kræver en liste over de systemer, der bruges til at udvikle, bygge og udgive software, med ejer og placering, og en beslutning om, hvilke servere der også hører til produktet.

Bliver de tre systemer glemt, kan auditten give et pænt billede af kontoret og mailen, mens den vej, kode tager ud til kunderne, står uprøvet. Står forbeholdet ikke i rapporten, kan den senere blive brugt som bevis for noget, den aldrig har undersøgt.

Det skal I lade være med

  • At holde udviklingsmiljøet uden for omfanget, fordi det “hører til produktet” · det er virksomhedens eget system.
  • At lade auditrapporten følge med til kunder som svar på CRA · den udtaler sig ikke om produktet.
  • At glemme nøglerne til signering · de er blandt de mest værdifulde hemmeligheder i huset.

Det skal auditten kunne vise

  • ☐ Et opdrag, hvor kodelager, byggesystem og opdateringsserver står i omfanget.
  • ☐ En liste over servere, der både er drift og fjerndatabehandling.
  • ☐ Adgangsgennemgang og ændringsspor for kodelager og byggesystem.
  • ☐ Beredskab for kompromittering af byggekæden, også efter artikel 14.
  • ☐ Et forbehold i rapporten om, at produktets overensstemmelse ikke er vurderet.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Læs også: Audit af virksomheden eller af softwareproduktet · Audit af adgangsstyringen

→ Kontakt · Tlf. 70 13 63 23 · Cybersikkerhedsaudit 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

Overvejer I, hvilken AI I skal vælge?

Skriv kort, hvilken AI-tjeneste eller model det drejer sig om, og hvad der sætter spørgsmålet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.