Softwareforsyningskæde: Sådan reducerer I risikoen i pakker og CI/CD

Du får en praktisk model til at styre risikoen ved eksterne softwarepakker og automatiske build-processer.

Artiklen forklarer, hvorfor låste versioner og en scanner ikke alene er nok.

Du får fem arbejdsspor, der forbinder udvikling, adgangsstyring, overvågning og beredskab.

Modellen kan bruges af både softwarevirksomheder og organisationer med egne udviklingsteams.

Mange danske virksomheder bygger, tilpasser eller drifter software med kode fra åbne pakke-registre. Det gør udviklingen hurtigere, men flytter også en del af tilliden til pakke vedligeholdere, build-miljøer og automatiske udgivelser. Når en legitim pakke eller afhængighed kompromitteres, kan påvirkningen nå både udvikleres arbejdsstationer, CI/CD-miljøer og de systemer, der senere modtager den færdige software.

Aktualiteten blev tydelig i CERT-EU’s Cyber Brief for august, offentliggjort 3. september 2026. Her omtales kompromitterede Rust-pakker, hvor en fejlstavet afhængighed kunne hente en ekstern kodekomponent under build. Det er ikke dokumentation for en dansk hændelse, men et aktuelt europæisk trussel signal: afhængigheder skal behandles som en drifts- og leverandørrisiko, ikke blot som en udvikler detalje.

En Software Bill of Materials, SBOM, giver et vigtigt overblik over komponenter og versioner i et produkt. Den fortæller dog ikke alene, om en pakke blev hentet fra den rigtige kilde, om den blev ændret efter godkendelse, hvem der kunne ændre build-konfigurationen, eller om en lækket automatiseringsnøgle kan udgive ny kode. Derfor skal softwareforsyningskæden styres på tværs af indkøb, udvikling, drift og hændelseshåndtering.

NIS 2-loven kræver for de omfattede væsentlige og vigtige enheder passende og forholdsmæssige foranstaltninger, herunder forsyningskædesikkerhed og sikkerhed i erhvervelse, udvikling og vedligeholdelse af net- og informationssystemer. Kravet er ikke en pligt til at vælge én bestemt pakkeplatform. Det er en pligt til at kunne vise, hvordan risici ved direkte leverandører og relevante softwareafhængigheder vurderes og håndteres.

Fem arbejdsspor for pakker og CI/CD

1. Kend de kritiske afhængigheder og byggeveje

Begynd med de systemer, hvor en fejl i en pakke eller build-proces kan påvirke kunder, produktion, betalinger eller følsomme data. Kortlæg de centrale pakke-registre, repositories, byggesystemer, release-artefakter og personer eller servicekonti med rettigheder. Afgræns også, hvilke builds der kan udgives automatisk, og hvilke der kræver en godkendelse.

2. Gør versionsvalg og kilde til en kontrolleret beslutning

Brug godkendte registre og interne spejle, hvor det er relevant. Lås afhængigheder til bestemte versioner og dokumentér, hvem der kan opdatere dem. En lockfil er ikke en garanti mod kompromittering, men den giver et reproducerbart udgangspunkt for at undersøge, hvad der faktisk indgik i en build. Vurder nye eller sjældent brugte pakker med særlig omhu, især når de får adgang til build-scripts eller hemmeligheder.

3. Beskyt build-miljøet og automatiseringsidentiteterne

CI/CD er ofte et attraktivt mål, fordi miljøet kan have adgang til kildekode, pakke-registre, signeringsnøgler og produktionsmiljøer. Giv servicekonti mindst mulige rettigheder, adskil udviklings- og produktions hemmeligheder, og brug kortlivede legitimationsoplysninger, når platformen understøtter det. Log ændringer i pipelines og release-konfigurationer, så en uventet udgivelse kan undersøges.

4. Kombinér scanning med menneskelig prioritering

Automatisk scanning kan finde kendte sårbarheder og uventede licenser, men den kan ikke alene afgøre forretningspåvirkning, reel eksponering eller troværdigheden af en ny pakke. Sæt en ejer og en frist på kritiske fund. Dokumentér, om I retter, afværger, overvåger eller accepterer en risiko, og test at den valgte løsning virker i den konkrete applikation.

5. Øv reaktionen på en kompromitteret afhængighed

En brugbar beredskabsøvelse starter med et realistisk spørgsmål: Kan I på få timer fastslå, om en mistænkelig pakke har indgået i en build, hvilke versioner der er berørt, og om de er nået til kunder eller drift? Øvelsen bør omfatte stop af nye builds, afgrænsning af adgang, genopbygning fra kendte artefakter, kommunikationsansvar og dokumentation af beslutninger. Den kan kobles til virksomhedens eksisterende it-beredskabsplan, så tekniske fund også får en driftsmæssig vej til beslutning og genopretning.

Det vigtigste mål er ikke flest mulige værktøjer, men en dokumenteret evne til at vælge sikre afhængigheder, begrænse konsekvensen af en fejl og handle hurtigt, når et varsel kommer. Måling kan derfor tage udgangspunkt i, hvor stor en del af kritiske builds der er reproducerbare, om CI/CD-adgange er gennemgået, hvor hurtigt en afhængighed kan matches til udgivelser, og om beredskabet er afprøvet. Det gør softwareforsyningskæden til en håndterbar del af informationssikkerheden og hjælper med at beskytte både drift, data og leverancer.