Hærdning af pipeline bør ikke forsinke levering. Disse lette kontroller fanger det, vi og vores underleverandører og partnere oftest ser — uden at ødelægge udviklerflow.
Denne guide forklarer de minimumsværn, der beskytter jeres build- og releaseprocesser mod almindelige CI/CD-angrebsveje, hvordan de udrulles sikkert, og hvordan man måler, at de forbliver på plads.
Nøgledefinitioner (almindeligt sprog)
Runner/Eksekverer: Maskinen, containeren eller servicen, der eksekverer jeres jobs. Behandl den som produktion: den kan læse kode, hemmeligheder og build-artefakter.
Artefakt: Alt produceret af dit build (pakker, images, binære filer, manifests). Artefakter bevæger sig mellem stadier og skal eksplicit have tillid.
Oprindelse: Bevis på at et artefakt blev bygget af betroet kode på betroet infrastruktur med kendte input.
Formidlede hemmeligheder: Kortlivede legitimationsoplysninger udstedt ved jobstart, scoped til minimumsbehov, og tilbagekaldt ved afslutning.
Hvorfor ledere bør bekymre sig
- • CI/CD er den smalle bro mellem kildekode og kunder. Hvis angribere kontrollerer den, kan de sende deres kode til dine brugere.
- • Autoværn reducerer sprængradius og skaber beviser: du kan vise revisorer og kunder, at kun verificerede artefakter når produktion.
- • Letvægtskontroller undgår den sædvanlige afvejning: sikkerhedssignaler går op, mens leveringshastigheden forbliver høj.
Omfang, ejerskab og ændringskontrol
Vi og vores kontraktorer og partnere starter med et skriftligt scope: hvilke repos, miljøer og pipelines er indenfor rammerne, og hvem godkender ændringer til følsomme jobs. Vi udpeger ejere af runner-flåder, hemmelighedslagre og release-trin, så ansvarlighed er tydelig.
- • Definér beskyttede stier (f.eks. release pipelines, infra-as-code), der kræver code review og signerede ændringer.
- • Dokumentér hvem der kan oprette eller godkende runners, og hvilke images de må bruge.
- • Kræv to-personers review for ændringer, der berører deploy-trin, signeringsnøgler eller scope for hemmeligheder.
Sikker håndtering: nøgler og hemmeligheder i CI/CD
Vi og vores kontraktorer og partnere adskiller langlivede rodnøgler fra daglig pipeline-brug. Build- og signeringsnøgler opbevares i et HSM eller cloud KMS; jobs modtager kortlivede least-privilege-tokens udstedt ved runtime og logget til audit.
- • Ingen klartekst-langlivede hemmeligheder i repos, jobvariabler eller runner-billeder.
- • Brug OIDC eller workload identity til at udstede tokens pr. job med eksplicitte audiences og udløb i minutter.
- • Rotér klienthemmeligheder ved rolleafvigelser og hændelseshåndtering; mål gennemsnitlig tid til tilbagekaldelse.
Grundlæggende kontroller
- • Scoped runners/eksekverere: isolér efter repo/lejer; undgå delte privilegerede runners.
- • Artefakt-signering + verifikation før promotion/deploy; luk ned ved mismatch.
- • Kortlivede hemmeligheder via brokers; hold produktionshemmeligheder ude af generiske pipelines.
- • Oprindelse af afhængigheder: lockfiles og interne mirrors for kritiske stier.
Metode: minimale autoværn, maksimal effekt
Vi og vores kontraktorer og partnere starter med én beskyttet pipeline og én service. Vi aktiverer signerede artefakter og verifikation ved deploy, flytter deploy-legitimationsoplysninger bag en broker og migrerer mønstret på tværs af repos. Små, gentagelige skridt slår store big-bang-ændringer.
- • Beskyt release-pipelinen først, udvid derefter til build- og testfaser.
- • Fastlås basebilleder og runners; genopbyg regelmæssigt fra kode, ikke manuelt.
- • Tilføj verifikation tidligt — promotions-gates bør tjekke signaturer og politik, før et deploy sker.
Hvad du får (og hvad du ikke får)
- • Reproducerbare trin: præcise YAML/job-diffs og CLI-kommandoer til at aktivere signering, verifikation og håndtering af hemmeligheder via broker.
- • Reference-runner-billeder og IaC-uddrag, som kan anvendes med minimal redigering.
- • Tjekliste for autoværn knyttet til ejere: hvem driver hvad og hvordan det overvåges.
- • Hvad du ikke får: et teoretisk foredrag om forsyningskæderisiko uden implementerbare ændringer.
Anatomi af et CI/CD-kompromis
- Fodfæste: angriber får adgang til en delt runner eller et repo med pipeline-tilladelser.
- Hemmeligheder: statiske tokens i jobvariabler eller logfiler lækker adgang til registries eller cloud-roller.
- Artefakt-bytte: usignerede eller uverificerede artefakter erstattes mellem build og deploy.
- Lateral bevægelse: pipeline skriver til produktionsmiljøer uden for det tiltænkte scope.
- Påvirkning: ondsindet kode leveret til brugere eller kontrol over infrastruktur.
Metrikker ledere kan følge
- • Dækning af runner-isolering: Procentdel af jobs på repo/tenant-afgrænsede runners (ikke delte privilegerede pools).
- • Rate af signerede artefakter: Procentdel af udrulninger, der verificerer signaturer og proveniens før udgivelse.
- • Levetid for hemmeligheder: Median credential TTL udstedt til jobs; sigt efter minutter, ikke dage.
- • Opdateringsgrad for base image: Dage siden sidste runner/base image blev genopbygget fra kode.
- • Blokerede promotionsforsøg: Antal udrulninger nægtet af verifikationsporte (et sundt tidligt signal).
Bedste praksis: runners og executors
- • Per-repo eller per-tenant runners uden delte admin-pools; deaktiver Docker-in-Docker medmindre påkrævet.
- • Uforanderlige runner-billeder bygget fra kode; genopbyg efter en tidsplan og efter kritiske CVE’er.
- • Netværks-egress-politikker på runners; ingen standardadgang til produktionsnetværk.
Bedste praksis: artefakter og releases
- • Signer ved build med nøgler i KMS/HSM; gem attestationer med artefakter.
- • Verificér ved promotion/deploy; luk ned og giv alarm ved uoverensstemmelse eller manglende attestation.
- • Bevar SBOM’er for kritiske tjenester; diff på ændringer til følsomme komponenter.
Bedste praksis: hemmeligheder og identitet
- • Brug workload identity (f.eks. OIDC) til at udstede legitimationsoplysninger pr. job; scope efter repo, branch og jobformål.
- • Fjern langlivede cloud-nøgler fra jobvariabler og logfiler; rens output som standard.
- • Rotér hemmeligheder automatisk; giv alarm om forældede tokens eller ubrugt adgang.
Bedste praksis: afhængigheder og inputs
- • Fastlås versioner via lockfiles; gennemgå ændringer i transitive afhængigheder på følsomme tjenester.
- • Brug interne mirrors til kritiske pakker og containerbaser; giv alarm om uventede kilder.
- • Scan før build, ikke efter release; stop builds ved væsentlige politikovertrædelser.
Almindelige anti-mønstre der slår fejl
- • Delte privilegerede runners til alt (ét kompromis, fuld blast radius).
- • Signering uden verifikationskontrol (ingen tjekker signaturen ved deploy).
- • Spredning af statiske hemmeligheder på tværs af jobs; de lækker i logfiler og cachelag.
- • At behandle pipeline som et udviklingslegetøj i stedet for et produktionssystem.
Levering, træning og overdragelse
Vi og vores kontraktorer og partnere leverer kørbare eksempler til jeres CI-udbyder samt træning til platform- og serviceteams. Vi dokumenterer, hvem der ejer nøgler, runner-billeder og verifikationspolitikker, med playbooks til rotation og hændelseshåndtering.
Hvordan man ruller sikkert ud
- Vælg én kritisk service og beskyt dens release-pipeline end-to-end (runners → signering → verifikation → brokerede hemmeligheder).
- Skabeloniser den fungerende konfiguration; anvend på de næste to services med små justeringer.
- Aktivér alarmer og dashboards for verifikationsfejl og udstedelse af hemmeligheder.
- Planlæg kvartalsvise nøglerotationer og genopbygning af runners; verificér med en testkørsel.
- Udvid til bredere repos, når ejere er trygge, og metrics stabiliserer sig.
Hvordan succes ser ud over 6–12 måneder
- • De fleste udrulninger blokeret ved verifikationsfejl under den tidlige udrulning, derefter et støt fald efterhånden som mønstre sætter sig.
- • Ingen delte privilegerede runners på kritiske stier.
- • Alle produktionsartefakter signeres og verificeres ved promotion/deploy.
- • Hemmeligheder udstedt pr. job med kort levetid og tydelige audit-spor.
CI/CD-sikkerhedsværn bør føles kedelige og holdbare. Når de udføres korrekt, forvandler de skræmmende overskrifter om forsyningskæden til enkle tjek, der kører hver dag. Vi og vores underleverandører og partnere hjælper dig med at vælge de få kontroller, der betyder noget, indbygger dem i dine pipelines og holder dem der uden at bremse teamsene.