La Sua app è a basso rischio. La Sua pipeline di build no.

Il ragionamento è valido, fino a un certo punto

Lo sentiamo spesso, e di solito nasce da una premessa sensata. L'app è una dashboard interna, una pipeline di dati o un piccolo servizio con pochi utenti. Non contiene nulla che interessi a un attaccante. Il budget per la sicurezza va prima al prodotto rivolto ai clienti.

Questa logica vale per l'applicazione. Non vale per il modo in cui l'applicazione viene compilata. Ogni team, qualunque cosa distribuisca, ha una pipeline CI con delle credenziali e un albero di dipendenze che non ha scritto. Sono obiettivi interessanti proprio perché condivisi, e una compromissione a quel livello raggiunge tutto il resto a cui quelle credenziali hanno accesso: i Suoi registry, i Suoi account cloud e gli altri Suoi repository.

Attacchi a cui non importava che cosa facesse l'app

Nessuno di questi incidenti ha preso di mira un particolare tipo di applicazione. Ciascuno ha raggiunto i team attraverso uno strumento o un pacchetto che usavano per compilare software.

tj-actions/changed-files, 2025

Una GitHub Action molto diffusa che rileva i file modificati è stata compromessa. Secondo CISA, le versioni malevole sono rimaste attive tra il 12 e il 15 marzo 2025 e la compromissione ha esposto secret tra cui chiavi di accesso, personal access token di GitHub, token npm e chiavi RSA private. Wiz ha riferito che il codice eseguiva il dump della memoria del runner CI, quindi nei repository pubblici i secret finivano nei log dei workflow. I workflow che facevano riferimento all'action tramite un tag di versione hanno eseguito il codice malevolo, qualunque fosse il contenuto del repository.

Worm npm Shai-Hulud, 2025

A settembre 2025, CISA ha segnalato un worm autoreplicante che aveva compromesso più di 500 pacchetti npm. Raccoglieva personal access token di GitHub e chiavi API cloud per AWS, Google Cloud e Azure. Palo Alto Networks Unit 42 ha descritto come usava i token npm rubati per pubblicare versioni infette degli altri pacchetti della vittima e come un'ondata successiva venisse eseguita durante il pre-install, ampliando la sua portata nelle pipeline CI/CD.

3:27

Codecov Bash Uploader, 2021

Un attaccante ha estratto una credenziale sfruttando un errore nel processo di build dell'immagine Docker di Codecov e ha modificato lo script Bash Uploader che molti team eseguivano in CI. Dal 31 gennaio al 1° aprile 2021, lo script alterato poteva inviare a terzi le variabili d'ambiente, comprese credenziali, token e chiavi disponibili nell'ambiente CI. È stato scoperto quando un cliente ha notato che il checksum dello script non corrispondeva.

xz utils, 2024

Codice malevolo è stato inserito nelle versioni 5.6.0 e 5.6.1 di XZ Utils, una libreria di compressione dati che può essere presente nelle distribuzioni Linux. CISA ha consigliato di tornare a una versione non compromessa come la 5.4.6 e di cercare attività malevole. Una libreria di compressione è quanto di meno affascinante possa esistere tra le dipendenze, eppure è stata un bersaglio.

event-stream, 2018

Una persona spacciatasi per un maintainer disponibile ha preso il controllo del popolare pacchetto npm event-stream e ha aggiunto una dipendenza malevola, flatmap-stream, nella versione 3.3.6. Il team di npm ha riferito che il payload prendeva di mira una specifica applicazione, il wallet bitcoin Copay. Anche tutti gli altri che hanno installato event-stream hanno ricevuto il codice malevolo.

Che cosa hanno in comune questi incidenti

• Sono avvenuti durante la build o l'installazione. Il codice malevolo è stato eseguito sulle macchine degli sviluppatori e sui runner CI, non nell'app in produzione.
• Puntavano alle credenziali. Il bottino erano i token e le chiavi nella pipeline, perché aprono porte oltre il progetto in fase di build.
• Sono arrivati attraverso nomi fidati. Un'action familiare, un pacchetto familiare, uno script familiare. Nessuno ha scelto di installare malware.
• La prima domanda successiva è stata la stessa. Una delle nostre build ha scaricato la versione compromessa, e che cosa poteva raggiungere? I team senza un registro di ciò che ogni build ha usato hanno dovuto ricostruirlo.

Che cosa significa impegno minimo

Non serve un team di sicurezza per coprire le basi. La maggior parte dei consigli di GitHub e CISA sta in un breve elenco:

1. Fissi le GitHub Actions di terze parti a un SHA di commit completo anziché a un tag, così un tag spostato non può cambiare ciò che viene eseguito.
2. Esegua il commit dei lockfile e fissi le versioni delle dipendenze a release affidabili note.
3. Dia ai token CI i permessi più ristretti possibili e li ruoti quando un incidente tocca qualcosa che usa.
4. Richieda un'autenticazione a più fattori resistente al phishing per gli account di sviluppo e di pubblicazione.
5. Conservi un registro di ciò che ogni build ha installato, così può rispondere a "siamo stati colpiti?" partendo dai dati e non dalla memoria.

I primi quattro sono configurazione. Il quinto è quello che la maggior parte dei piccoli team salta, perché richiede strumenti.

Il ruolo di CRACI con poco sforzo

CRACI si occupa della registrazione e aggiunge un confine di rete, senza chiederLe di modificare la Sua app o i Suoi workflow.

• Una riga per job. Cambi runs-on in craci. I Suoi workflow GitHub Actions restano come sono e le esecuzioni continuano a comparire in GitHub.
• Una SBOM da ogni build. CRACI registra i pacchetti che ogni job scarica effettivamente, compresi quelli ripristinati dalle cache, ed esporta il risultato in CycloneDX o SPDX.
• Una traccia di rete per job. Quando viene annunciato un incidente, può verificare quali build hanno scaricato il pacchetto interessato e a che cosa si è connesso ogni job.
• Una policy di egress che può passare a default deny. Autorizzi le fonti di pacchetti di cui un job ha bisogno, e uno step compromesso avrà meno destinazioni a cui inviare ciò che trova. Le policy sono fail closed e le violazioni fanno scattare un alert.
• Rivalutazione continua. Le SBOM monitorate vengono ricontrollate man mano che vengono pubblicate nuove vulnerabilità, così una vecchia build non resta "pulita" solo perché nessuno ha guardato.

Per essere chiari sui limiti: una policy di egress non avrebbe impedito alla compromissione di tj-actions di stampare i secret in un log pubblico, e nessuno strumento annulla un token trapelato. Il pinning e la rotazione restano importanti. Ciò che CRACI cambia è la rapidità con cui può stabilire se è stato esposto e fin dove può arrivare uno step compromesso.

Per avviare un primo workflow basta installare la GitHub App e cambiare una riga in runs-on: craci.

Quanto costa

CRACI addebita solo i minuti di build: $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile e senza costi per SBOM. Veda i prezzi per le condizioni complete. Le startup idonee possono candidarsi al programma per startup per ottenere almeno 100k minuti di build gratuiti e un onboarding assistito.

Se vende software nell'UE, vale anche la pena verificare se il Cyber Resilience Act si applica a Lei. La nostra guida al CRA spiega ambito e scadenze.