123% di CVE segnalate in più al giorno nel 2026 rispetto all'anno scorso.

Sicurezza CI/CD

Fermare l'esfiltrazione da GitHub Actions con una policy di egress

Un job CI custodisce secret ed esegue codice scaricato un minuto prima: action, pacchetti e i loro script di installazione. Se una parte di quel codice è malevola, il modo più semplice per rubare i secret è inviarli a un server. Una policy di egress decide quali server un job può raggiungere e blocca gli altri.

Aggiornato il

Come i secret escono da un job CI

Un job ha accesso al token del repository, ai secret che gli vengono passati e alle credenziali cloud che assume. Il codice eseguito nel job può leggerli. Può poi farli uscire in alcuni modi:

  • Attraverso la rete. Una richiesta a un server controllato dall'attaccante. È il canale che una policy di egress chiude.
  • Attraverso i log. Stampando i secret, spesso codificati, nel log del job. Nel marzo 2025 CISA ha riferito che l'action compromessa tj-actions/changed-files ha esposto secret in questo modo.
  • Attraverso gli output. Artefatti, cache o commit inviati con il token del job.

Il codice non deve per forza essere un pacchetto malevolo. Un agente IA nel workflow può essere manipolato tramite una prompt injection nascosta in una issue o in una pull request, e usare poi gli stessi canali.

Che cosa fa una policy di egress

La maggior parte dei job deve raggiungere un breve elenco di destinazioni: registry di pacchetti, registry di container, host di sorgenti e pochi servizi. Una policy di egress consente quell'elenco e blocca tutto il resto. Con una policy deny predefinita, una richiesta verso un host sconosciuto fallisce e i secret restano nel job.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

Non chiude ogni porta:

  • Non impedisce che i secret vengano stampati nei log. Mantenga privati i log e fissi le action ai commit SHA.
  • Una destinazione consentita può comunque portare fuori dati, quindi mantenga ristretta l'allowlist.
  • Non Le dice quali pacchetti erano malevoli. Quello è il compito dello screening dei pacchetti e di una SBOM.

Tre modi per applicarne una

  • Un agente sul runner. StepSecurity Harden-Runner viene aggiunto come primo step di un job. Associa ogni connessione allo step che l'ha effettuata, costruisce una baseline in modalità audit e blocca l'egress verso tutto ciò che non è in un'allowlist.
  • Un runner con una policy integrata. CRACI applica la policy come runner stesso. Anche altri fornitori di runner offrono controlli di rete, come il filtraggio dell'egress sui runner Linux di Depot e le policy di egress di blocco o advisory su Namespace.
  • La Sua rete. Runner self-hosted dietro un firewall o un proxy che Lei configura e gestisce.

Introdurla senza far fallire le build

  1. Osservare. Registri ogni connessione effettuata da un job nel corso di alcune esecuzioni.
  2. Consentire. Costruisca l'allowlist in base a ciò di cui il job ha effettivamente bisogno.
  3. Bloccare. Passi al deny predefinito e tenga d'occhio le violazioni.
  4. Esaminare. Tratti ogni nuova violazione come una sorgente mancante o come un incidente.

Come lo fa CRACI

Su CRACI la policy di egress fa parte del runner. Viene convalidata prima dell'avvio del job, i campi sconosciuti vengono rifiutati e la policy opera in modalità fail-closed. I preset integrati coprono le sorgenti di pacchetti comuni, mentre sorgenti e connessioni personalizzate aggiungono il resto. La traccia del job elenca ogni connessione, e ognuna di quelle bloccate come violazione con il relativo motivo. Poiché il proxy riconosce i pacchetti, la stessa registrazione diventa la SBOM del job. L'API restituisce SBOM, tracce di rete e provenance.

CRACI non ha ancora una modalità audit dedicata; è in roadmap. Senza una policy di rete, il traffico di un job è consentito e registrato nella traccia, così Lei può vedere di che cosa ha bisogno una policy prima di applicarla. CRACI esegue job GitHub Actions su Linux. Veda gli strumenti per la sicurezza CI/CD a confronto e CRACI vs StepSecurity.

Policy di egress in CI: domande frequenti

Che cos'è una policy di egress in CI?

Un insieme di regole per le connessioni di rete in uscita che un job CI può effettuare. Il job può raggiungere i registry dei pacchetti e i servizi di cui ha bisogno, e ogni altra destinazione viene bloccata.

Una policy di egress avrebbe fermato la compromissione di tj-actions?

Non da sola. In quel caso CISA ha riferito che i secret sono stati esposti attraverso i log dei workflow, non inviati a un server esterno. Una policy di egress chiude il canale di rete; fissare le action ai commit SHA e mantenere privati i log interviene sul canale dei log.

Bloccare l'egress fa fallire le build?

Può succedere, se la policy tralascia una sorgente di cui la build ha bisogno. Inizi registrando a che cosa si connette il job, costruisca l'allowlist da lì, poi blocchi. Su CRACI i preset integrati coprono le sorgenti di pacchetti comuni, e una connessione bloccata compare nella traccia del job con il motivo.

Posso usare una policy di egress sui runner ospitati da GitHub?

Sì, con un agente aggiunto al job, come StepSecurity Harden-Runner. Oppure sposti il job su un runner che applica la policy da sé, come CRACI.

Metta un job dietro una policy di egress

Esegua un workflow su CRACI e veda ogni connessione effettuata, quali bloccherebbe una policy deny predefinita e la SBOM di ciò che ha scaricato.

Prenota una demo