GitHub Actions CI/CD OIDC SLSA
GitHub Actions è al centro delle moderne supply chain del software — ogni commit, ogni rilascio e ogni aggiornamento delle dipendenze vi transita. Se mal configurato, fa trapelare segreti, spedisce artefatti non firmati e collassa con la scala del monorepo. Progettiamo e rafforzamo le pipeline GitHub Actions per team di prodotto statunitensi ed europei: deploy keyless OIDC, provenance SLSA, librerie di workflow riutilizzabili, matrix build e cicli di feedback in meno di un minuto di cui i team di ingegneria si fidano davvero.
GitHub Actions è al centro delle moderne supply chain del software — ogni commit, ogni rilascio e ogni aggiornamento delle dipendenze vi transita. Se mal configurato, fa trapelare segreti, spedisce artefatti non firmati e collassa con la scala del monorepo. Progettiamo e rafforzamo le pipeline GitHub Actions per team di prodotto statunitensi ed europei: deploy keyless OIDC, provenance SLSA, librerie di workflow riutilizzabili, matrix build e cicli di feedback in meno di un minuto di cui i team di ingegneria si fidano davvero.
Challenges
Le variabili d'ambiente e gli output di action di terze parti possono stampare segreti nel log in testo normale. Verifichiamo ogni workflow per step echo e run che possano esporre segreti, aggiungiamo chiamate ::add-mask:: e applichiamo un'action composita di log-scrubbing su tutti i repository.
Usare action con un tag mutabile (v3, main) significa che un repository upstream compromesso può iniettare codice malevolo in ogni pipeline silenziosamente. Fissiamo tutte le action per SHA completo del commit, automatizziamo gli aggiornamenti SHA tramite Dependabot e condizioniamo i merge alla revisione obbligatoria.
I runner self-hosted non effimeri mantengono lo stato tra un job e l'altro — artefatti di build, credenziali e codice sorgente persistono su disco. Effettuiamo il provisioning di runner effimeri (GitHub Actions Runner Controller o Buildjet) che terminano dopo ogni job e non condividono mai lo stato del filesystem.
Installazioni di dipendenze non in cache, build ridondanti dei layer Docker e job sequenziali rendono le pipeline così lente che gli ingegneri smettono di aspettarle. Ristrutturiamo i job per l'esecuzione parallela, aggiungiamo caching a strati (npm/pip/Gradle/layer Docker) e utilizziamo l'analisi degli affected di Turborepo o Nx per saltare i pacchetti invariati.
Test non deterministici e asserzioni sensibili all'ambiente causano build fallite spurie che erodono la fiducia nella CI e aumentano la latenza della merge queue. Mettiamo in quarantena i test instabili in un workflow separato, aggiungiamo logica di retry con rilevamento instabilità jUnit e affrontiamo le cause radice sistematicamente.
Eseguire l'intera test suite a ogni commit in un monorepo grande spreca minuti per ogni PR e satura la capacità dei runner. Integriamo l'analisi del grafo affected di Turborepo o Nx con i filtri di path di GitHub Actions per eseguire solo le pipeline interessate da ogni modifica.
Solutions
Sostituite le credenziali cloud a lunga vita con token OIDC a breve durata per AWS, GCP e Azure. Ogni job riceve un token con scope limitato all'esatto repository, branch e ambiente — credenziali che scadono in minuti e non possono essere esfiltrate.
Estraete la logica CI in un repository centralizzato di workflow riutilizzabili. I team chiamano un singolo riferimento di workflow e ricevono step coerenti di linting, testing, security scanning e deployment — nessun drift per copia-incolla tra decine di repository.
Generate attestazioni di provenance SLSA Level 3 per ogni build di rilascio. Firmate immagini container e binari con cosign (keyless tramite Sigstore). Fissate tutte le action di terze parti per SHA e automatizzate gli aggiornamenti tramite Dependabot.
Analizzate i grafi delle dipendenze dei job per step sequenziali non necessari, aggiungete caching delle dipendenze a strati, passate al caching dei layer Docker buildx tramite GHCR e integrate Turborepo o Nx per costruire solo ciò che è cambiato.
Generazione dinamica di matrix dal grafo dei pacchetti affected — ogni servizio riceve il proprio job di test e build isolato, i risultati confluiscono in un singolo status check di merge-gate e i pacchetti invariati vengono saltati interamente.
Versionamento semantico automatizzato, generazione del changelog, creazione di GitHub Release, tagging delle immagini container e promozione degli ambienti dallo staging alla produzione — tutto condizionato da regole di protezione dell'ambiente e workflow di approvazione.
Stack
GitHub Actions, workflow riutilizzabili, action composite, OIDC, runner ospitati da GitHub, runner self-hosted, Dependabot, CodeQL, secret scanning, ambienti e regole di protezione, matrix build, cosign, provenance SLSA, Docker buildx, GHCR, cache Turborepo, Nx affected, GitHub Packages.
Compliance
Provenance SLSA Level 3 · Firma keyless OIDC · Secret scanning ad ogni push · Audit trail SOC 2
Cases
App iOS e Android native per firma digitale con CRM Symfony + React per uno studio legale transfrontaliero — onboarding KYC e pista probante per pratiche USA e UE.
App cross-platform per dieta e pianificazione pasti su Flutter — motore calorie, libreria ricette, piano pasti settimanale, ordinazione della spesa.
App companion POS retail per una catena di boutique multi-brand — ricerca inventario cross-store con ElasticSearch, integrazione sistema 1C.
Why YuSMP
Trattiamo la pipeline CI/CD stessa come una superficie di attacco. Ogni progetto inizia con un audit di sicurezza del workflow — esposizione dei segreti, igiene del pinning, isolamento dei runner e configurazione OIDC — prima di qualsiasi sviluppo di funzionalità.
Una CI lenta è una CI ignorata. Misuriamo la durata baseline della pipeline, ristrutturiamo i grafi dei job per il parallelismo e aggiungiamo caching a ogni livello finché il ciclo di feedback è abbastanza veloce da essere atteso prima del merge.
Le soluzioni puntuali che funzionano per un repository cedono a 50. Costruiamo librerie centralizzate di workflow riutilizzabili, registri di action composite e policy Dependabot che i team di governance possono applicare a tutto il parco repository senza overhead per singolo repository.
FAQ
GitHub Actions è la scelta predefinita corretta quando il codice sorgente è già su GitHub — zero infrastruttura da mantenere, integrazione nativa con le pull request, Dependabot e il security graph GitHub. Jenkins si adatta ai team con infrastruttura on-premises complessa e librerie condivise mature. GitLab CI è la scelta naturale quando l'intera piattaforma DevSecOps vive in GitLab. La migrazione da Jenkins o GitLab CI a GitHub Actions richiede tipicamente da una a due settimane per un parco pipeline di medie dimensioni.
Il deploy keyless OIDC sostituisce le credenziali cloud a lunga vita (chiavi di accesso AWS, JSON del service account GCP) memorizzate come segreti GitHub con token a breve durata emessi dall'identity provider di GitHub. Ogni job richiede un token valido per l'esatto repository, branch e ambiente, con scope limitato ai permessi IAM minimi. Il token scade al termine del job — nulla da ruotare, nulla da far trapelare e nulla da revocare dopo una violazione.
Utilizzate i runner ospitati da GitHub per la maggior parte dei workload — zero manutenzione e stato pulito ad ogni job. I runner self-hosted sono giustificati quando le build richiedono hardware specifico (GPU, ARM, alta memoria), accesso a risorse di rete private non esponibili pubblicamente, o ottimizzazione dei costi con volumi di build molto elevati. Quando si utilizzano runner self-hosted, devono essere effimeri — provisioning per ogni job tramite GitHub Actions Runner Controller o un gruppo di auto-scaling cloud.
La provenance SLSA (Supply-chain Levels for Software Artefacts) è una dichiarazione firmata che registra esattamente quale commit sorgente, toolchain di build e ambiente di build ha prodotto un dato artefatto. GitHub Actions la genera tramite l'action slsa-framework/slsa-github-generator, che gira in un workflow riutilizzabile isolato e firma l'attestazione con cosign usando il protocollo keyless di Sigstore. I consumatori possono verificare la provenance in modo indipendente usando la CLI cosign prima del deployment.
Seguiamo un approccio a quattro livelli: parallelizziamo i job indipendenti nel grafo del workflow, aggiungiamo cache delle dipendenze (actions/cache per npm, pip, Maven, Gradle), passiamo a Docker buildx con cache dei layer GHCR per evitare di ricostruire i layer invariati, e integriamo l'analisi degli affected di Turborepo o Nx per saltare i pacchetti invariati nei monorepo. Un audit iniziale tipico recupera il 40-70% della durata della pipeline senza modificare alcun codice applicativo.
I segreti cifrati di GitHub sono la baseline corretta — vengono mascherati nei log e non esposti mai alle fork pull request. Per i deployment in produzione, sostituite i segreti statici con token OIDC (nessun segreto del tutto). Per i segreti che devono esistere (chiavi API, certificati di firma), usate segreti con scope ambiente con regole di protezione che richiedono approvazione manuale prima che un job possa accedervi. Il secret scanning ad ogni push intercetta i commit accidentali prima che raggiungano il remote.
Integriamo Turborepo o Nx con GitHub Actions usando la generazione dinamica di matrix. Un job di setup esegue l'analisi del grafo degli affected e emette una matrix JSON dei pacchetti modificati. I job successivi si distribuiscono sulla matrix in parallelo — ogni pacchetto riceve un job di test e build isolato. I pacchetti non modificati vengono saltati interamente. I risultati confluiscono in un singolo status check obbligatorio che presidia i merge, così la merge queue vede un unico segnale verde indipendentemente dalla dimensione del monorepo.
Risposta entro 1 giorno lavorativo. NDA su richiesta.
Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.