De systemer, der opbevarer IT-afdelingens scripts og skabeloner og udruller dem automatisk, kan have adgang til mere end nogen enkelt administrator. Den, der kan ændre i kodeopbevaringen eller i en byggeserver, kan få ændringen sendt ud til servere, klienter og cloudmiljøer, uden at nogen logger ind på dem. Svaret på, hvorfor området skal testes for sig, hviler derfor på rækkevidden: byggekæden er en vej ind i hele driften, og den bliver ikke altid behandlet med samme omhu som domænecontrollerne.
Her handler det om driftens egne systemer, fx opbevaring af skabeloner til infrastruktur, automatisering af serveropsætning og udrulning af interne værktøjer. Softwarehuse, der bygger produkter til kunder, har deres egen problemstilling, som er beskrevet på pentestrapport.dk.
Hvorfor byggekæden er et mål i sig selv
En byggeserver gør det, den bliver bedt om. Den henter kode, kører den med sine egne rettigheder og lægger resultatet ud, hvor den har adgang. For at kunne det har den typisk nøgler til cloudmiljøer, konti med ret til at ændre servere og forbindelser til interne systemer.
Det gør den til en samling af privilegier, som kan være sat op af én person en gang og siden kun er udvidet. OWASP har lavet en særskilt liste over risici i netop disse miljøer, og flere af punkterne handler om adgang, legitimationer og manglende logning frem for fejl i selve koden. Byggekæden er med andre ord et driftsspørgsmål. → Infrastruktur som kode og testen
Der er også en praktisk grund til at se på området særskilt. Når en almindelig server bliver ændret, sker det som regel med en administrator, der logger ind og efterlader spor. Når kæden udruller, ser ændringen ud som en helt normal udrulning. Den slags ændringer bliver måske ikke undersøgt bagefter, fordi de ligner hverdagen.
Det, der hører med i området
Inden testen skal I have et overblik over, hvad I faktisk har. Det er måske ikke samlet ét sted.
- Kodeopbevaring · hvor scripts, skabeloner og konfigurationer ligger, og om det er en tjeneste i skyen eller en server i huset.
- Byggeservere og agenter · maskiner, der udfører opgaverne, også dem, der står på et udviklingsnet eller hos en afdeling uden for IT.
- Forbindelser · hvilke miljøer kæden kan udrulle til, og med hvilke konti.
- Hemmeligheder · hvor nøgler og adgangskoder til udrulningen er gemt.
- Tredjepartsdele · udvidelser, færdige byggetrin og eksterne tjenester, som kæden henter eller kalder.
Systemer, som en enkelt medarbejder har bygget for at automatisere sit eget arbejde, hører også med. De kan være de mindst dokumenterede. → Interne værktøjer bygget af IT selv
Det, testen afprøver
En test af området ser på adgangen til kæden og på, hvad kæden selv kan nå. Den ændrer ikke i jeres udrulninger, men vurderer, om det ville være muligt, og hvem der kunne.
- Hvem kan ændre · om flere personer, konti eller grupper kan ændre i kode og byggetrin, end opgaverne kræver.
- Godkendelse · om en ændring kan gå direkte i drift, uden at en anden person har set den.
- Kædens egne konti · hvor brede rettigheder byggeserveren og dens agenter har i de miljøer, de udruller til.
- Synlige hemmeligheder · om nøgler og adgangskoder står i kode, historik eller logfiler, som mange kan læse. → Adgangskoder i scripts og konfigurationsfiler
- Administrationsfladen · om byggeserverens egen administration er afskærmet og kræver stærkt login.
Aftal på forhånd, hvilke repositorier og byggeservere der er med, og om testeren må læse koden. Læseadgang gør vurderingen mere præcis, men den skal være netop det: læsning, ikke ret til at udrulle.
Fundtyper, I kan forvente
Rapportens fund i området kan ligne fund fra andre dele af driften, men de vejer tungere, fordi de rækker længere.
- Byggekonto med for meget · kontoen, der udruller, er administrator i hele miljøet, selv om den kun skal ændre få ressourcer. → Tjenestekonti og deres rettigheder
- Nøgler med lang levetid · faste nøgler, der aldrig skiftes, og som er kopieret til flere byggetrin. → Nøgler og hemmeligheder i cloud
- Ingen adskillelse mellem miljøer · samme kæde og samme konti udruller til både test og produktion.
- Fri adgang til at ændre byggetrin · alle med læseret til kodeopbevaringen kan også ændre i den.
- Glemte agenter · byggemaskiner, der ikke længere bruges, men stadig har forbindelse og rettigheder.
- Manglende spor · det kan ikke ses bagefter, hvem der ændrede hvad, og hvornår.
Sådan retter I på begrebsniveau
Rettelserne følger de samme principper som for anden privilegeret adgang. Det særlige er, at kæden selv er en aktør, der skal begrænses.
- Begræns retten til at ændre · færre personer med skriveadgang, og krav om, at en anden godkender ændringer, før de udrulles.
- Giv kæden mindre · hver udrulning får kun de rettigheder, den skal bruge, og kun i det miljø, den hører til.
- Skil test fra produktion · forskellige konti og forskellige nøgler, så en fejl i testmiljøet ikke når driften.
- Flyt hemmeligheder ud af koden · nøgler opbevares centralt, skiftes og kan spærres uden at ændre koden.
- Ryd op i agenter og udvidelser · det, der ikke bruges, fjernes, og det, der bruges, har en ejer.
- Gem sporene · log ændringer i kode, byggetrin og rettigheder, så de kan bruges ved en hændelse. → Logning efter testen
NIST har en vejledning om at bygge sikkerhed ind i udrulningskæder, som kan bruges som fælles reference, når rettelserne skal begrundes over for dem, der ejer kæden.
Det skal I lade være med
- At holde kæden uden for testen, fordi den hører til udvikling. Har driften adgang til at udrulle med den, er den et driftssystem.
- At give testeren ret til at udrulle. Læseadgang er nok til at vurdere opsætningen.
- At rette nøglen og lade kontoen være. En ny nøgle til en konto med for brede rettigheder løser kun halvdelen.
- At glemme byggemaskiner hos andre afdelinger. Agenter uden ejer kan være en rest fra tidligere projekter.
- At lade alle med læseadgang kunne ændre. Læse og skrive er to forskellige rettigheder.
Hvad kan og ikke kan konkluderes
Testen kan vise, hvem der kunne ændre i kæden, hvor brede rettigheder kæden havde, og om hemmeligheder lå frit i testperioden. Den kan ikke garantere, at kode, der allerede er udrullet, er uændret, og den vurderer ikke kvaliteten af koden i jeres skabeloner eller værktøjer. Et resultat uden fund gælder de repositorier og byggeservere, der var med i aftalen.
Tjekliste til byggekæden
- ☐ Har I en liste over kodeopbevaring, byggeservere og agenter med en ejer for hver?
- ☐ Ved I, hvilke miljøer kæden kan udrulle til, og med hvilke konti?
- ☐ Kræver ændringer godkendelse af en anden person, før de går i drift?
- ☐ Er test og produktion adskilt med egne konti og nøgler?
- ☐ Ligger nøgler og adgangskoder uden for koden og dens historik?
- ☐ Bliver ændringer i byggetrin og rettigheder logget?
Kilder
- OWASP Top 10 CI/CD Security Risks: OWASP-projektets liste over risici i bygge- og udrulningsmiljøer, herunder adgangsstyring, legitimationer, opsætning, tredjepartstjenester og logning.
- NIST SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines: vejledning fra 2024 om at indbygge sikkerhed i bygge-, test-, paknings- og udrulningstrin.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Interne værktøjer bygget af IT selv · Egne softwareprodukter og testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
