Udviklingsmiljø og byggekæde som mål i en red team‑øvelse

En organisation, der leverer software til kunder, har et mål, som en modstander kan finde mere værdifuldt end en database: vejen fra kildekode til den udgivelse, kunderne installerer. Et scenarie om udviklingsmiljøet hviler på et enkelt spørgsmål til forsvaret, nemlig om nogen ser og stopper misbrug af den vej, og på én fast betingelse for øvelsen: intet af det, holdet gør, må ændre det, der sendes til kunderne. Scenariet giver mening, når I udvikler software, som andre stoler på, og når byggekæden er en af jeres kronjuveler. Det giver ikke mening som erstatning for en teknisk afprøvning af de enkelte servere.

Hvorfor byggekæden er sit eget mål

NIST beskriver i SP 800-218, Secure Software Development Framework, at alle dele af miljøerne til softwareudvikling skal beskyttes mod interne og eksterne trusler, og nævner udvikling, bygning, test og distribution som eksempler på sådanne miljøer. Rammeværket taler også om at beskytte al kode mod uautoriseret adgang og manipulation og om at give kunderne en mulighed for at kontrollere, at en udgivelse er ægte.

For en red team-øvelse betyder det, at målet kan ligge flere steder i kæden:

Kildekoden · hvem kan læse og ændre den, og opdager nogen en ukendt ændring?
Byggeservere og pipelines · hvem kan påvirke, hvad der bliver bygget, og med hvilke rettigheder kører processen?
Signering · hvem har adgang til de nøgler eller tjenester, der gør en udgivelse troværdig?
Distribution · hvordan kommer den færdige software ud til kunderne, og hvem kontrollerer den undervejs?

Det, øvelsen kan sige noget om, er ikke, om hvert enkelt system er sikkert konfigureret. Det er, om forsvaret ser en modstander bevæge sig mod kæden, og om udviklingsafdelingen og sikkerhedsfunktionen reagerer sammen. → Målet for øvelsen

Flag, der beviser adgang uden at røre leverancen

Flaget er den sværeste del at planlægge. Et flag, der kræver en ændring i rigtig kode eller en rigtig signeret udgivelse, er udelukket, fordi det kan nå kunderne. Flag kan i stedet være:

Et aftalt dokument · placeret af white team i et kodelager, der aldrig bygges eller udgives.
En markeringsfil på en byggeserver · som holdet skal kunne læse og dokumentere, uden at påvirke en byggeproces.
Dokumenteret adgang til signeringsfunktionen · uden at signere noget. Det er nok at vise, at holdet kunne have bedt om en signatur.
En testudgivelse i en lukket kanal · hvis I har et separat miljø, der efterligner distributionen uden at nå rigtige kunder.

Uanset valg skal rules of engagement sige udtrykkeligt, at holdet ikke må ændre kode på grene, der indgår i udgivelser, ikke må bruge signeringsnøgler og ikke må røre distributionskanalerne. Den regel bør være fredet, også hvis scenariet ellers kalder på det. → Fredede områder

Hvem skal vide besked

Et skjult scenarie i udviklingsmiljøet har et særligt problem. Udviklere og release-ansvarlige er både en del af forsvaret og dem, der ville opdage en uventet ændring. Hvis ingen i udviklingsafdelingen ved besked, kan en reaktion på holdets spor stoppe en udgivelse eller sætte en hel afdeling i gang med at gennemgå kode.

En mulig løsning er, at en enkelt person med overblik over udgivelserne er med i white team. Den person kan holde øje med, at ingen udgivelse er i fare, uden at fortælle resten af afdelingen om øvelsen. Hvis byggekæden bruger eksterne tjenester til kodelagre eller bygning, skal deres vilkår for test også afklares, før scenariet godkendes. → Driftsleverandører og cloududbydere i øvelsen

Stopregler og en ren kæde bagefter

Byggekæden er et af de få steder, hvor en fejl i øvelsen kan sprede sig til kunder. Stopreglerne bør derfor være strammere end i resten af øvelsen. Et stop kan fx udløses, hvis en udgivelse er planlagt i perioden, hvis holdet opdager adgang til signering, som ingen kendte til, eller hvis en udvikler begynder at undersøge holdets spor på en måde, der kan forsinke en leverance.

Efter øvelsen skal white team kunne dokumentere, at kæden er ren: hvilke konti og filer holdet oprettede, at de er fjernet, og at ingen udgivelse i perioden er påvirket. Den dokumentation kan få værdi, hvis kunder senere spørger til øvelsen. Overvej også at lade en person uden for holdet sammenholde holdets logbog med ændringshistorikken i kodelagre og byggesystemer, så kontrollen ikke alene hviler på holdets egen oplysning om, hvad det rørte. → Stopregler

Regler, der kan spille ind

Blandt de risikostyringsforanstaltninger, som væsentlige og vigtige enheder skal træffe efter NIS2, direktiv (EU) 2022/2555, står i artikel 21, stk. 2, litra e, sikkerheden ved erhvervelse, udvikling og vedligeholdelse af systemerne, herunder håndtering og offentliggørelse af sårbarheder. Et scenarie i udviklingsmiljøet kan give et billede af, om den del af risikostyringen fungerer i praksis, men det er ikke i sig selv dokumentation for, at kravet er opfyldt. Hvordan bestemmelsen er gennemført i dansk ret, og om den gælder jer, er beskrevet under → NIS2 og red teaming

Leverer I produkter med digitale elementer, kan forordningen om cyberrobusthed, forordning (EU) 2024/2847, også blive relevant, fordi den lægger forpligtelser på fabrikanterne. Efter artikel 71 finder den anvendelse fra den 11. december 2027, mens fabrikantens rapporteringsforpligtelser i artikel 14 gælder fra den 11. september 2026. Om et fund fra en øvelse kan udløse en pligt efter forordningen, er et spørgsmål til jeres juridiske rådgiver. Teksten er ikke juridisk rådgivning.

Den tekniske afprøvning af byggeservere og pipelines som systemer hører hjemme i en penetrationstest og er beskrevet på https://penetration-test.dk/.

Det skal I lade være med

At lade flaget kræve en ændring i rigtig kode · det kan nå kunderne.
At give holdet lov til at bruge signeringsnøgler · adgang kan dokumenteres uden.
At planlægge øvelsen hen over en udgivelse · eller uden at nogen i white team kender udgivelsesplanen.
At glemme eksterne tjenester i kæden · deres vilkår gælder ved siden af jeres tilladelse.
At afslutte uden at dokumentere, at kæden er ren · den dokumentation er en del af leverancen.

Hvad kan og ikke kan konkluderes

Scenariet kan vise, om forsvaret og udviklingsafdelingen opdager og reagerer på en modstander, der nærmer sig kildekode, byggeservere eller signering. Det kan ikke vise, at alle udgivelser er fri for manipulation, og det erstatter ikke en teknisk gennemgang af byggekæden eller et sikkert udviklingsforløb. Et flag, der blev nået, viser én vej; det siger ikke, at andre veje er lukket.

Tjekliste før scenariet

☐ Er det beskrevet, hvilket led i kæden scenariet skal nå?
☐ Er flaget placeret, så det aldrig kan indgå i en udgivelse?
☐ Er brug af signeringsnøgler og ændringer i leverede grene fredet i rules of engagement?
☐ Er en person med overblik over udgivelserne med i white team?
☐ Er vilkår for eksterne kodelagre og byggetjenester afklaret?
☐ Er det aftalt, hvordan det dokumenteres, at kæden er ren bagefter? → Oprydning efter øvelsen

Kilder

NIST SP 800-218, Secure Software Development Framework: beskyttelse af miljøerne til udvikling, bygning, test og distribution (PO.5), beskyttelse af kode mod manipulation (PS.1) og kontrol af udgivelsers ægthed (PS.2).
Direktiv (EU) 2022/2555 (NIS2): artikel 21, stk. 2, litra e.
Forordning (EU) 2024/2847 (forordningen om cyberrobusthed): artikel 13 om fabrikantens forpligtelser, artikel 14 om rapportering og artikel 71 om anvendelsesdatoer.

Senest gennemgået: oktober 2026.