De fleste team ser for seg en sårbarhet for eskalering av rettigheter som en kjernefeil eller en misbrukt feil. sudo på en produksjonsserver. I 2026 befinner den farligere versjonen seg et annet sted: i pipeline som bygger og sender koden din. A CI/CD jobben har rutinemessig skrivetilgang til lagringsstedene dine, tokener for pakkeregistrene dine og legitimasjon for skyen din. En angriper som får kode som kjører i den jobben trenger ikke å eskalere mye. pipeline har allerede gjort det for dem.
Denne veiledningen forklarer hvordan en sårbarhet for privilegiumsøkning ser ut i CI/CD pipelines og containere, går gjennom de vanligste stiene angripere bruker, og viser hvordan man lukker hver enkelt.
TL;DR: sårbarhet for eskalering av rettigheter i CI/CD pipelines
I en pipeline, trenger angriperen ofte ikke å eskalere privilegier. pipeline har dem allerede. En sårbarhet for eskalering av rettigheter i CI/CD er vanligvis en tillatelse som er tegnet bredere enn jobben trenger, og venter på at upålitelig kode skal kjøres inni den.
- Pipelines er privilegerte per design. De leser kildekode, oppbevarer hemmeligheter, publiserer artefakter og distribuerer til produksjon, noe som gjør dem til et av de mest verdifulle eskaleringsmålene i organisasjonen din.
- De fleste eskaleringsveier er feilkonfigurasjoner, ikke utnyttelser. Brede standardtokener,
pull_request_targetArbeidsflyter som kjører fork-kode og langlivede skynøkler gjør mer skade enn noen nulldagsprosess. - Eskalering av containerrettigheter gjør én jobb om til en hel løper. Privilegerte containere, rotbrukere og en montert Docker-socket gjør byggecontaineren til en døråpning, ikke en grense.
- Det skjer allerede i stor skala. CHAINDROP-ormen brukte utvidet tilgang på GitHub Actions-kjørere for å lese legitimasjonsinformasjon rett fra løperens minne.
- Løsningen er minste privilegium, håndhevet kontinuerlig. Omfang hvert token, herd hver container og oppdag tillatelsesavvik før en angriper finner den.
Hva er det for en sårbarhet?
En sårbarhet for privilegieskalering er enhver svakhet som lar en bruker, prosess eller kodestykke få tillatelser utover det den var ment å ha. MITRE ATT&CK sporer det som sin egen taktikk, TA0004: Privilegieeskalering, fordi det er steget som forvandler et lite fotfeste til reell skade.
Det finnes to klassiske former:
- Vertikal eskalering: oppgradering, for eksempel fra en vanlig bruker til root, eller fra en skrivebeskyttet token til en som kan skrive.
- Horisontal eskalering: bevege seg sidelengs, for eksempel bruke én jobbs tilgang til å nå et annet teams depot, hemmeligheter eller miljø.
Angripere utnytter en sårbarhet for privilegiesekalisering gjennom tre typer svakheter: programvarefeil, feilkonfigurasjoner og overdreven tilgang. På servere får feil mest oppmerksomhet. CI/CD pipelines, feilkonfigurasjoner og overdreven bruk av tillatelser gjør nesten all jobben.
Hvorfor det er så farlig i CI/CD pipelines
A pipeline er ikke bare et byggeverktøy. Det er en automatisert identitet med noen av de bredeste tilgangene i bedriften din. En typisk jobb kan:
- Sjekk ut og endre kildekoden
- Les hemmeligheter fra miljøvariabler, hvelv og skybaserte metadatatjenester
- Publiser pakker, bilder og utgivelsesartefakter
- Distribuer til staging og produksjon
Ocuco OWASP Topp 10 CI/CD Sikkerhetsrisiko navngir dette problemet direkte. Risikoen CICD-SEC-5: Utilstrekkelig Pipeline-Baserte tilgangskontroller beskriver hvordan angripere som kjører ondsinnet kode i en pipeline misbruke tillatelsene som er gitt til å bevege seg sidelengs, innenfor eller utenfor CI/CD system.
Dette er ikke teoretisk. Under CHAINDROP-kampanjen i august 2026 ble skadevaren hentet ut midlertidige legitimasjonsdetaljer fra GitHub Actions-runnerens minne og brukte stjålne publiseringstokener til å infisere flere pakker. På Linux-kjørere, nyttelasten kjørte samleren sin gjennom sudo å lese minnet til runner-prosessen. Det er privilegieøkning i CI/CD pipelines i sin reneste form: en forgiftet avhengighet, forhøyet tilgang til løperen og alle hemmeligheter jobben kan berøre. Det er det samme mønsteret vi ser i våre ukentlige funn på ondsinnede npm-pakker.
Hvor skjuler en sårbarhet for privilegiumsøkning seg i en pipeline?
Seks vanlige stier, hva hver enkelt låser opp for en angriper, og kontrollen som lukker den.
| Eskaleringsvei | Hvordan det skjer | Hva angriperen får | Hvordan lukke den |
|---|---|---|---|
| Overprivilegerte pipeline token | Arbeidsflyter kjører med brede standard token-omfang fordi ingen permissions blokken er satt | Skrivetilgang til kode, utgivelser og andre arbeidsflyter | Angi skrivebeskyttede standardinnstillinger og gi skrivetilgang per jobb, kun der det er nødvendig |
| Forgiftet pipeline gjennomføring | pull_request_target eller lignende utløsere sjekker ut og kjører kode fra en upålitelig fork | Lagringshemmeligheter og et skrivetoken, fra en enkelt pull request | Kjør aldri fork-kode i en privilegert kontekst; del opp klarerte og ikke-klarerte jobber |
| Eskalering av containerrettigheter | Byggecontainere kjører som root, i privilegert modus eller med Docker-socketen montert | Root på runner-verten og tilgang til alle jobber den kjører | Kjør som ikke-root, slipp funksjoner og blokker privilegieeskalering i containerspesifikasjonen |
| Langvarige skylegitimasjoner | Statiske skynøkler lagret som hemmeligheter eller miljøvariabler | Permanent tilgang til skykontoer, lenge etter at jobben er avsluttet | Bruk kortvarig, føderert legitimasjon og tilbakekalle eksponerte hemmeligheter automatisk |
| Vedvarende selvhostede løpere | Løpere brukes på nytt på tvers av jobber og repositorier uten å bli gjenoppbygd | Utholdenhet, og muligheten til å tukle med andre lags bygg | Bruk flyktige løpere og isoler dem per tillitsnivå |
| Overprivilegerte menneskelige kontoer | Inaktive administratorer, eksterne samarbeidspartnere og ureviderte tillatelsesendringer hoper seg opp | En gyldig konto som kan endres pipelines og grenbeskyttelse | Gjennomgå tilgang kontinuerlig og varsle om avvikende endringer i tillatelser |
Eskalering av containerrettigheter: når byggecontaineren ikke er en grense
Containere føles som isolasjon, så team behandler dem ofte som en sikkerhetsgrense. CI/CD, er de ofte ikke en av dem. Eskalering av containerrettigheter skjer når kode i en byggecontainer får kontroll over verten, og med den alle andre jobber som kjører der.
Tre innstillinger står for de fleste tilfeller:
- Kjører som root. Hvis prosessen inne i beholderen er rot, starter ethvert utbrudd fra den sterkest mulige posisjonen.
- Privilegert modus. En privilegert container har nesten samme tilgang til verten som en prosess som kjører direkte på den.
- En montert Docker-socket. Montering
/var/run/docker.sockinn i en jobb slik at den kan bygge bilder effektivt overfører den jobben som root til verten, fordi den kan starte nye privilegerte containere.
Sikkerhetsforskere har vist hvordan dette utspiller seg i ekte CI-systemer. I et veldokumentert tilfelle gikk forskere fra byggeskript som kjørte inne i en CI-container til en full container escape på Cloudflare Pages' byggeverter, forcisfordi containeren ble behandlet som sikkerhetsgrensen.
Slik ser en herdet Kubernetes-jobbspesifikasjon ut. Nøkkelinnstillingen er allowPrivilegeEscalation: false, Som hindrer en prosess i å få flere rettigheter enn den overordnede, for eksempel gjennom setuid-binærfiler.
# Herdet byggepod: blokkerer de vanligste eskaleringsstiene for containerrettigheter apiVersjon: v1 slag: Pod metadata: navn: ci-bygg spec: sikkerhetskontekst: kjørSomIkkeRoot: sant kjør som bruker: 10001 seccompProfil: typen: KjøretidStandard containere: - navn: bygge bilde: register.example.com/bygg-bilde@sha256: sikkerhetskontekst: tillatPrivilegiumOpptrapping: falsk privilegert: falsk readOnlyRootFilsystem: sant evner:
Det samme prinsippet gjelder for selve Dockerfilen. Legg til en ikke-root-bruker og bytt til den før inngangspunktet:
# Kjør containeren som en ikke-root-bruker FRA node:22-slim LØPE brukeradd --uid 10001 --opprett-hjem bygger WORKDIR / app KOPI --chown=byggmester:byggmester . . BRUKER bygger CMD ["node", "index.js"]
Kubernetes-dokumentasjonen om konfigurere en sikkerhetskontekst dekker hver av disse innstillingene i detalj.
GitHub-handlinger: en eskaleringssårbarhet som gjemmer seg i det åpne lyset
GitHub Actions er der mange team først møter rettighetsøkning i CI/CD pipelines, fordi de farlige mønstrene ser helt vanlige ut. To er verdt å sjekke i alle arkiver i dag.
Token-omfang. Hver arbeidsflyt får en GITHUB_TOKENGitHubs egen veiledning om automatisk token-autentisering er tydelig: en handling kan nå det tokenet selv om du ikke sender det eksplisitt, så du bør alltid begrense tillatelsene til et minimum. Å angi skrivebeskyttede tillatelser øverst i arbeidsflyten og gi skrivetilgang per jobb fjerner den vanligste eskaleringsveien i ett trinn:
navn: bygge on: [skyv] # Standard for hver jobb: skrivebeskyttet tillatelser: innhold: lese jobber: test: kjører på: ubuntu-nyeste trinn: # Fest tredjepartshandlinger til en fullstendig commit SHA, ikke en modifiserbar tag - bruker: handlinger/kassen@commit-sha> - løpe: npm ci og npm-test slipp: behov: test kjører på: ubuntu-nyeste # Bare denne jobben kan skrive, og bare det den trenger tillatelser: innhold: skrive trinn: - bruker: handlinger/kassen@commit-sha> - løpe: ./scripts/release.sh
Upålitelige utløsere. Arbeidsflyter utløst av pull_request_target kjøre med måldepotets hemmeligheter og et skrivekompatibelt token, selv når pull request kommer fra en fork. Hvis den arbeidsflyten deretter sjekker ut og kjører forkens kode, kan hvem som helst åpne en pull request og kjøre kode med dine rettigheter. Det er en sårbarhet for privilegiesekalisering som ikke trenger å utnyttes i det hele tatt, bare en pull requestBehold privilegerte trinn på klarert kode, og kjør uklarert kode i en separat arbeidsflyt uten hemmeligheter.
Hvis du vil se disse mønstrene på et trygt sted, xygeni-geit depotet samler inn bevisst usikkert pipeline og IaC konfigurasjoner for opplæring. For en bredere gjennomgang av GitHub-oppsettet ditt, se veiledningen vår om hvordan vite om en GitHub-app eller et repository er trygt.
Slik forhindrer du sårbarhet for eskalering av rettigheter i CI/CD pipelines
Lukker opptrapping av privilegier i CI/CD pipelines handler om ett prinsipp: færrest privilegier, anvendt på hvert lag og kontrollert kontinuerlig i stedet for én gang. En praktisk sjekkliste:
- Omfang hver token. Skrivebeskyttet som standard, skrivetilgang per jobb og ingen organisasjonsomfattende tokener i arbeidsflyter for repositoriet.
- Skill mellom klarert og uklarert kode. Kjør aldri kode fra forks eller eksterne bidragsytere i en jobb som inneholder hemmeligheter.
- Herd hver byggebeholder. Ikke-root-brukere, ingen privilegert modus, ingen Docker-socket, funksjoner fjernet,
allowPrivilegeEscalation: false. - Erstatt langvarige hemmeligheter. Foretrekk kortvarige fødererte legitimasjonsopplysninger, og tilbakekall alt som eksponeres umiddelbart.
- Fest det du kjører. Referer til tredjepartshandlinger og bilder etter commit SHA eller sammendrag, så en kompromittert tag kan ikke endre din pipeline.
- Se opp for avdrift. Tillatelser utvides over tid. Varsle om nye administratorer, svekket beskyttelse i grener og uventede endringer i arbeidsflyten.
- Porten pipeline. Mislykkes med byggingen når en kritisk feilkonfigurasjon oppstår, før den slås sammen.
Det vanskelige er å ikke kjenne til disse reglene. Det er å håndheve dem på tvers av hundrevis av databaser og arbeidsflyter som endres hver dag.
Hvordan stopper Xygeni et sårbarhet for eskalering av rettigheter i CI/CD?
Hver eskaleringsbane, matchet med Xygeni-funksjonaliteten som oppdager eller blokkerer den.
| Risiko | Hva Xygeni gjør |
|---|---|
| Pipeline feilkonfigurasjoner | Feilkonfigurasjonsdetektorer skanne CI-jobbdefinisjoner, bygge skript og konfigurasjonsfiler på tvers av GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI og Jenkins, og flagge tillatelser som er bredere enn beste praksis tillater. |
| Eskalering av containerrettigheter | IaC og containerkontroller dekke Dockerfiles, docker-compose-filer, Kubernetes-manifester og Helm-diagrammer, inkludert containere som kjører som root |
| Overprivilegerte og inaktive brukere | Analyse av brukere med minst privilegier identifiserer inaktive og overprivilegerte brukere, og Health Check gjør hvert funn om til en billett |
| Tillatelsesavvik | Varsler om avviksdeteksjon ved uvanlige tillatelsesendringer, avvikende sammenslåinger og uventede plugin-installasjoner |
| Eksponerte legitimasjonsdetaljer | Hemmelighetsdeteksjon dekker kode, pipelines og containerbilder, med automatisk tilbakekalling for støttede hemmelige typer |
| Ondsinnet kode i pipeline | Blokkerer reverse shells og nedlastinger av skadelig programvare i pipelinei sanntid, og MEW oppdager skadelige pakker før en signatur finnes |
| Enforcement | Pre-commit hooks og CI guardrails mislykkes byggingen på kritiske problemer, med tilpassede YAML-policyer for dine egne regler |
Sjekker stemmer overens med OWASP Topp 10 CI/CD Sikkerhetsrisiko og standards som CIS, NIST, og OpenSSFHvert funn flyter inn i Xygeni ASPM, hvor den prioriteres sammen med funn av kode, avhengigheter og hemmeligheter, slik at sårbarheten for rettighetseskalering som faktisk når produksjon blir fikset først.
Mest privilegieøkning i CI/CD pipelines ligger allerede i arbeidsflytfilene dine og venter på at uklarert kode skal kjøre.
FAQ
Hva er en sårbarhet for privilegiumsøkning i CI/CD?
Det er enhver svakhet som lar kode kjøre i en pipeline få mer tilgang enn jobben krever, for eksempel et overprivilegert token, en arbeidsflyt som kjører uklarert kode med hemmeligheter, eller en byggecontainer som kan nå verten.
Hva er eskalering av containerrettigheter?
Eskalering av containerrettigheter er når en prosess i en container får høyere rettigheter, ofte root på verten. Vanlige årsaker er at den kjører som root, privilegert modus og en montert Docker-socket.
Betyr allowPrivilegeEscalation: false stoppe containerrømming?
Den blokkerer én viktig vei: en prosess som får flere privilegier enn den overordnede, for eksempel gjennom setuid-binærfiler. Den fungerer best kombinert med en ikke-root-bruker, tapte funksjoner og ingen privilegert modus.
Is pull_request_target alltid farlig?
Ikke av seg selv. Det blir et sårbarhet for privilegieserering når arbeidsflyten sjekker ut og kjører kode fra pull request, fordi den koden deretter kjører med hemmelighetene dine og et skrivekompatibelt token.
Hvordan finner jeg stier for eskalering av rettigheter på tvers av mange repositorier?
Manuelle vurderinger skaleres ikke. En automatisert CI/CD Sikkerhetsverktøyet skanner kontinuerlig alle arbeidsflyter, containerspesifikasjoner og tillatelsessett, og varsler når noe utvides.
