La maggior parte dei team immagina una vulnerabilità di escalation dei privilegi come un bug del kernel o un uso improprio sudo su un server di produzione. Nel 2026, la versione più pericolosa vive da qualche altra parte: nel pipeline che compila e distribuisce il tuo codice. CI/CD Il job detiene di norma l'accesso in scrittura ai repository, i token per i registri dei pacchetti e le credenziali per il cloud. Un attaccante che riesce a eseguire del codice all'interno di quel job non ha bisogno di elevare i propri privilegi di molto. pipeline lo ha già fatto per loro.
Questa guida spiega come appare una vulnerabilità di escalation dei privilegi in CI/CD pipelineIl video illustra i percorsi più comuni utilizzati dagli aggressori e mostra come chiudere ciascuno di essi.
In breve: vulnerabilità di escalation dei privilegi in CI/CD pipelines
In un pipeline, l'attaccante spesso non ha bisogno di elevare i privilegi. Il pipeline li ha già. Una vulnerabilità di escalation dei privilegi in CI/CD Si tratta in genere di un'autorizzazione più ampia di quanto necessario per il compito, che consente l'esecuzione di codice non attendibile al suo interno.
- Pipelinesono privilegiati per definizione. Leggono il codice sorgente, custodiscono segreti, pubblicano artefatti e li distribuiscono in produzione, il che li rende uno dei bersagli più preziosi per le escalation all'interno della vostra organizzazione.
- Nella maggior parte dei casi, i percorsi di escalation sono dovuti a configurazioni errate, non a exploit. Token Broaddefault,
pull_request_targetI flussi di lavoro che eseguono codice fork e le chiavi cloud a lunga durata causano danni maggiori di qualsiasi vulnerabilità zero-day. - L'escalation dei privilegi del container trasforma un singolo lavoro nell'intero processo di esecuzione. I container con privilegi elevati, gli utenti root e un socket Docker montato rendono il container di build una porta d'accesso, non un confine.
- Accade già su larga scala. Il worm CHAINDROP sfruttava i privilegi di accesso elevati sui runner di GitHub Actions per leggere le credenziali direttamente dalla memoria del runner.
- La soluzione è il principio del minimo privilegio, applicato in modo continuativo. Analizza ogni token, rafforza la sicurezza di ogni contenitore e rileva le modifiche ai permessi prima che un aggressore le scopra.
Che cos'è una vulnerabilità?
Una vulnerabilità di escalation dei privilegi è qualsiasi debolezza che consente a un utente, un processo o una parte di codice di ottenere autorizzazioni superiori a quelle che dovrebbe avere. MITRE ATT&CK la tiene traccia come una sua tattica, TA0004: Escalation dei privilegi, perché è il passo che trasforma un piccolo punto d'appoggio in un danno reale.
Esistono due forme classiche:
- Escalation verticale: Passare a un livello superiore, ad esempio da utente normale a root, oppure da un token di sola lettura a uno con permessi di scrittura.
- Escalation orizzontale: Spostarsi lateralmente, ad esempio utilizzando l'accesso di un lavoro per raggiungere il repository, i segreti o l'ambiente di un altro team.
Gli aggressori sfruttano una vulnerabilità di escalation dei privilegi attraverso tre tipi di debolezza: bug del software, configurazioni errate e permessi eccessivi. Sui server, i bug ricevono la maggior parte dell'attenzione. CI/CD pipelineLe configurazioni errate e le autorizzazioni eccessive sono quasi la causa principale del problema.
Perché è così pericoloso CI/CD pipelines
A pipeline Non è solo uno strumento di compilazione. È un'identità automatizzata con uno dei più ampi livelli di accesso all'interno della tua azienda. Un'attività tipica può:
- Esamina e modifica il codice sorgente
- Leggi i segreti dalle variabili d'ambiente, dai vault e dai servizi di metadati cloud.
- Pubblica pacchetti, immagini e artefatti di rilascio
- Distribuzione negli ambienti di staging e produzione
Migliori OWASP Top 10 CI/CD Rischi per la sicurezza nomina direttamente questo problema. Il suo rischio CICD-SEC-5: Insufficient Pipeline-Controlli di accesso basati descrive come gli aggressori che eseguono codice dannoso in un pipeline abusare dei permessi concessi per muoversi lateralmente, dentro o fuori dal CI/CD .
Questo non è teorico. Durante la campagna CHAINDROP nell'agosto 2026, il malware Credenziali temporanee estratte dalla memoria del runner di GitHub Actions e ha utilizzato token di pubblicazione rubati per infettare più pacchetti. Sui runner Linux, il payload ha eseguito il suo collettore attraverso sudo leggere la memoria del processo runner. Questa è l'escalation dei privilegi in CI/CD pipelines nella sua forma più pura: una dipendenza avvelenata, un accesso privilegiato al runner e ogni segreto che il lavoro potesse toccare. È lo stesso schema che vediamo nei nostri risultati settimanali su pacchetti npm dannosi.
Dove si nasconde una vulnerabilità di escalation dei privilegi in un pipeline?
Sei percorsi comuni, cosa ognuno di essi apre per un attaccante e il controllo che permette di bloccarli.
| Percorso di escalation | Come accade | Ciò che ottiene l'attaccante | Come chiuderlo |
|---|---|---|---|
| Privilegiati pipeline token | I flussi di lavoro vengono eseguiti con ampi ambiti di token predefiniti perché non permissions il blocco è impostato | Accesso in scrittura al codice, alle release e ad altri flussi di lavoro | Imposta le impostazioni predefinite di sola lettura e concedi l'accesso in scrittura per ogni singolo lavoro, solo dove necessario. |
| Avvelenato pipeline esecuzione | pull_request_target o trigger simili controllano ed eseguono codice da un fork non attendibile | Segreti del repository e un token di scrittura, da un singolo pull request | Non eseguire mai codice fork in un contesto privilegiato; separa i processi attendibili da quelli non attendibili. |
| Escalation dei privilegi del contenitore | I container di build vengono eseguiti come root, in modalità privilegiata o con il socket Docker montato | Accesso root all'host del runner e accesso a ogni job in esecuzione. | Esegui come utente non root, rimuovi le capacità e blocca l'escalation dei privilegi nelle specifiche del container. |
| Credenziali cloud di lunga durata | Chiavi cloud statiche memorizzate come segreti o variabili d'ambiente | Accesso persistente agli account cloud, anche molto tempo dopo la fine del lavoro. | Utilizzare credenziali federate di breve durata e revocare automaticamente i segreti esposti |
| Runner persistenti auto-ospitati | I runner vengono riutilizzati tra diversi job e repository senza essere ricostruiti. | Persistenza e capacità di manomettere le costruzioni di altre squadre | Utilizzare runner effimeri e isolarli per livello di fiducia |
| Account umani privilegiati | Amministratori inattivi, collaboratori esterni e modifiche di autorizzazione non verificate si accumulano | Un account valido che può cambiare pipelineprotezioni dei rami e dei rami | Monitora costantemente gli accessi e segnala eventuali modifiche anomale delle autorizzazioni. |
Escalation dei privilegi del container: quando il container di build non è un confine
I container danno la sensazione di isolamento, quindi i team spesso li trattano come un confine di sicurezza. CI/CDSpesso non lo sono. L'escalation dei privilegi del container si verifica quando il codice all'interno di un container di build ottiene il controllo dell'host e, con esso, di ogni altro job che vi viene eseguito.
Nella maggior parte dei casi, tre impostazioni sono sufficienti:
- Esecuzione come root. Se il processo all'interno del container è root, qualsiasi tentativo di evasione inizia dalla posizione più forte possibile.
- Modalità privilegiata. Un container con privilegi elevati ha quasi lo stesso livello di accesso all'host di un processo in esecuzione direttamente su di esso.
- Un socket Docker montato. Montaggio
/var/run/docker.sockin un lavoro in modo che possa creare immagini in modo efficace passa quel lavoro root sull'host, perché può avviare nuovi container privilegiati.
I ricercatori della sicurezza hanno mostrato come questo si manifesta nei sistemi CI reali. In un caso ben documentato, i ricercatori sono passati da script di build in esecuzione all'interno di un container CI a un fuga completa del container sugli host di build di Cloudflare Pages, percisely perché il container veniva considerato come confine di sicurezza.
Ecco come appare una specifica di lavoro Kubernetes rinforzata. L'impostazione chiave è allowPrivilegeEscalation: false, quale impedisce a un processo di ottenere più privilegi del suo genitore, ad esempio tramite binari setuid.
# Pod di build rinforzato: blocca i percorsi più comuni di escalation dei privilegi dei container apiVersione: v1 tipo: Baccello metadati: Nome: ci-build spec: contesto di sicurezza: runAsNonRoot: vero runAsUser: 10001 profilo seccomp: Digitare: RuntimeDefault contenitori: - Nome: costruire Immagine: registry.example.com/build-image@sha256: contesto di sicurezza: consentire l'escalation dei privilegi: falso privilegiato: falso File system di sola lettura: vero funzionalità:
Lo stesso principio si applica al Dockerfile stesso. Aggiungi un utente non root e passa a tale utente prima dell'entrypoint:
# Esegui il container come utente non root DA nodo:22-slim CORRERE useradd --uido 10001 --crea-casa costruttore DIR.LAVORO / app COPIA --chown=costruttore:costruttore . . UTENTE costruttore CMD ["nodi", "index.js"]
La documentazione di Kubernetes su configurazione di un contesto di sicurezza copre in dettaglio ciascuna di queste impostazioni.
GitHub Actions: una vulnerabilità di escalation nascosta in bella vista
GitHub Actions è il luogo in cui molti team incontrano per la prima volta l'escalation dei privilegi in CI/CD pipelineperché gli schemi pericolosi appaiono del tutto ordinari. Due di questi meritano di essere controllati in ogni archivio oggi.
Ambito del token. Ogni flusso di lavoro ha un GITHUB_TOKEN. Le linee guida di GitHub su autenticazione automatica del token È chiaro: un'azione può raggiungere quel token anche se non lo si passa esplicitamente, quindi è sempre consigliabile limitarne le autorizzazioni al minimo. Impostare le autorizzazioni di sola lettura all'inizio del flusso di lavoro e concedere l'accesso in scrittura per ogni singola attività elimina in un colpo solo il percorso di escalation più comune:
Nome: costruire on: [spingere] # Impostazione predefinita per ogni lavoro: sola lettura permessi: testuali: read posti di lavoro: test: gira su: ubuntu-latest passi: # Fissa le azioni di terze parti a un elenco completo commit SHA, un tag non modificabile - usa: azioni/checkout@commit-sha> - eseguire il: npm ci && npm test rilasciare: esigenze: test gira su: ubuntu-latest # Solo questo lavoro può scrivere, e solo ciò di cui ha bisogno permessi: testuali: scrivere passi: - usa: azioni/checkout@commit-sha> - eseguire il: ./scripts/release.sh
Trigger non attendibili. Flussi di lavoro attivati da pull_request_target esegui con i segreti del repository di destinazione e un token scrivibile, anche quando il pull request proviene da un fork. Se quel flusso di lavoro viene quindi controllato ed esegue il codice del fork, chiunque può aprire un pull request e eseguire codice con i tuoi privilegi. Questa è una vulnerabilità di escalation dei privilegi che non necessita di alcun exploit, solo di un pull request. Mantieni le fasi privilegiate sul codice affidabile ed esegui il codice non affidabile in un flusso di lavoro separato senza segreti.
Se vuoi vedere questi modelli in un luogo sicuro, il capra xygeni il repository raccoglie deliberatamente insicuri pipeline and IaC configurazioni per l'addestramento. Per una revisione più ampia della configurazione di GitHub, consulta la nostra guida su Come capire se un'app o un repository GitHub sono sicuri.
Come prevenire una vulnerabilità di escalation dei privilegi in CI/CD pipelines
Chiusura dell'escalation dei privilegi in CI/CD pipelineTutto si riduce a un principio: il minimo privilegio, applicato a ogni livello e verificato continuamente anziché una sola volta. Una pratica lista di controllo:
- Esamina ogni token. Impostazione predefinita: sola lettura, accesso in scrittura per singolo job e nessun token a livello di organizzazione nei flussi di lavoro del repository.
- Separare il codice attendibile da quello non attendibile. Non eseguire mai codice proveniente da fork o da collaboratori esterni in un lavoro che contiene informazioni riservate.
- Rafforza la sicurezza di ogni contenitore di build. Utenti non root, nessuna modalità privilegiata, nessun socket Docker, funzionalità eliminate,
allowPrivilegeEscalation: false. - Sostituisci i segreti di lunga data. Preferisci credenziali federate di breve durata e revoca immediatamente qualsiasi informazione esposta.
- Appunta ciò che corri. Riferimento ad azioni e immagini di terze parti commit SHA o digest, quindi un tag compromesso non può cambiare il tuo pipeline.
- Attenzione alla deriva. Le autorizzazioni si ampliano nel tempo. Ricevi notifiche in caso di nuovi amministratori, indebolimento delle protezioni dei rami e modifiche impreviste al flusso di lavoro.
- Porta il pipeline. Interrompi la build se viene rilevato un errore di configurazione critico, prima che venga unita.
La parte difficile non è conoscere queste regole. È farle rispettare in centinaia di repository e flussi di lavoro che cambiano ogni giorno.
Come fa Xygeni a bloccare una vulnerabilità di escalation dei privilegi in CI/CD?
Ciascun percorso di escalation, abbinato alla funzionalità Xygeni che lo rileva o lo blocca.
| Rischio | Cosa fa Xygeni |
|---|---|
| Pipeline configurazioni errate | Rilevatori di errata configurazione Analizza le definizioni dei job CI, gli script di build e i file di configurazione su GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI e Jenkins e segnala autorizzazioni più ampie di quelle consentite dalle best practice. |
| Escalation dei privilegi del contenitore | IaC e controlli dei container coprire Dockerfile, file docker-compose, manifest di Kubernetes e Helm chart, inclusi i container in esecuzione come root |
| Utenti privilegiati e inattivi | L'analisi del minimo privilegio identifica gli utenti inattivi e quelli con privilegi eccessivi, e Health Check trasforma ogni scoperta in un biglietto |
| Permesso di deriva | Il sistema di rilevamento delle anomalie segnala modifiche insolite delle autorizzazioni, fusioni anomale e installazioni di plugin impreviste. |
| Credenziali esposte | Il rilevamento dei segreti copre il codice, pipelinee immagini contenitore, con revoca automatica per i tipi di segreti supportati |
| Codice dannoso nel pipeline | Blocca le reverse shell e i download di malware in pipelinein tempo reale e MEW rileva i pacchetti dannosi prima che esista una firma |
| Rinforzo | Pre-commit hooks e CI guardrails Fallisci la build in caso di problemi critici, con policy YAML personalizzate per le tue regole |
I controlli sono allineati con OWASP Top 10 CI/CD Rischi per la sicurezza and standards come CIS, NIST e OpenSSFOgni scoperta confluisce in Xygeni ASPMdove viene classificata in ordine di priorità insieme alle vulnerabilità del codice, delle dipendenze e dei segreti, in modo che la vulnerabilità di escalation dei privilegi che effettivamente raggiunge l'ambiente di produzione venga corretta per prima.
La maggior parte dell'escalation dei privilegi in CI/CD pipelines è già presente nei file del flusso di lavoro, in attesa che venga eseguito codice non attendibile.
FAQ
Che cos'è una vulnerabilità di escalation dei privilegi in CI/CD?
È qualsiasi debolezza che permette al codice in esecuzione in un pipeline ottenere un livello di accesso superiore a quello richiesto dal lavoro, come ad esempio un token con privilegi eccessivi, un flusso di lavoro che esegue codice non attendibile contenente segreti o un container di build in grado di raggiungere l'host.
Che cos'è l'escalation dei privilegi dei container?
L'escalation dei privilegi nei container si verifica quando un processo all'interno di un container ottiene privilegi più elevati, spesso quelli di root sull'host. Le cause più comuni sono l'esecuzione come root, la modalità privilegiata e il montaggio di un socket Docker.
Le normative allowPrivilegeEscalation: false Come fermare le fughe dai container?
Blocca un percorso importante: quello che consente a un processo di ottenere privilegi superiori a quelli del processo padre, ad esempio tramite binari con setuid. Funziona al meglio se combinato con un utente non root, con funzionalità disabilitate e senza modalità privilegiata.
Is pull_request_target sempre pericoloso?
Non da solo. Diventa una vulnerabilità di escalation dei privilegi quando il flusso di lavoro effettua il checkout ed esegue il codice da pull request, perché quel codice viene quindi eseguito con i tuoi segreti e un token con permessi di scrittura.
Come posso individuare i percorsi di escalation dei privilegi tra diversi repository?
Le revisioni manuali non sono scalabili. Un sistema automatizzato CI/CD Lo strumento di sicurezza analizza continuamente ogni flusso di lavoro, specifica del container e set di autorizzazioni, e invia un avviso quando qualcosa si allarga.
