Rafforzamento pratico della sicurezza per le azioni GitHub

Casa » Python » Rafforzamento pratico della sicurezza per le azioni GitHub

GitHub Actions è diventato il motore CI/CD de facto per i repository ospitati su GitHub, alimentando tutto, dai test unitari alle distribuzioni di produzione e alle modifiche all'infrastruttura. Questa praticità comporta un serio compromesso: i flussi di lavoro spesso vengono eseguiti con ampi privilegi, gestiscono token e segreti potenti e possono raggiungere direttamente i sistemi di produzione. Se non li si rafforza deliberatamente, si sta di fatto dando a ogni errore di configurazione, bug di dipendenza o account compromesso una corsia preferenziale per l'accesso alle pipeline e agli account cloud.

Questa guida illustra un ampio elenco di controllo basato su opinioni per proteggere GitHub Actions end-to-end: come gestire correttamente i segreti, evitare l'iniezione di script, bloccare token e trigger, valutare le azioni di terze parti, gestire i runner e sfruttare le funzionalità di sicurezza integrate come la scansione del codice, OIDC, Dependabot e i log di audit. L'obiettivo è riunire le best practice sparse, le lezioni apprese a fatica da incidenti recenti e le linee guida di GitHub per la sicurezza in un unico riferimento pratico da applicare a progetti reali.

Il vero profilo di rischio di GitHub Actions

Ad alto livello, un flusso di lavoro di GitHub Actions è semplicemente un file YAML sotto .github/workflows che definisce uno o più processi, ciascuno composto da passaggi. I passaggi possono eseguire comandi shell o richiamare azioni riutilizzabili pubblicate da GitHub o dalla community. I flussi di lavoro vengono attivati ​​da eventi come push, pull request, attività di issue, pianificazioni o invii manuali.

Dal punto di vista della sicurezza, questi flussi di lavoro si trovano proprio in cima alla catena di fornitura del softwareCreano e firmano artefatti di rilascio, inviano immagini Docker, distribuiscono in ambienti cloud, forniscono infrastrutture, eseguono migrazioni e altro ancora. Se un aggressore riesce a controllare il codice, la configurazione o l'ambiente in cui viene eseguito un flusso di lavoro privilegiato, spesso può:

• Artefatti compilati backdoor (binari, contenitori, pacchetti) che in seguito spedirai ai clienti.
• Esfiltra potenti token e segreti di lunga durata dalla memoria, dai registri, dalle cache o dagli artefatti.
• Abusare dei ruoli cloud privilegiati concesso a CI per distribuire servizi extra, modificare la rete o accedere ai dati.
• Progetti avvelenati a valle compromettendo le pipeline di rilascio open source e distribuendo versioni trojanizzate.

Recenti incidenti nel mondo reale hanno sottolineato quanto GitHub Actions sia attraente come superficie di attaccoGli aggressori hanno abusato di flussi di lavoro vulnerabili per iniettare cryptominer nei pacchetti pubblicati e il popolare tj-actions/changed-files L'azione è stata compromessa in un attacco multifase che ha tentato di raggiungere Coinbase. Il codice dannoso ha estratto segreti dai flussi di lavoro e li ha scritti nei log di build, creando una potenziale cascata di successive compromissioni della supply chain.

L'idea chiave da tenere a mente è che la maggior parte degli attacchi GitHub Actions riguardano "probabilità × impatto"Si desidera ridurre la probabilità di adottare componenti dannosi o difettosi (azioni di terze parti, runner non sicuri, trigger rischiosi) e, allo stesso tempo, limitare drasticamente il raggio di esplosione nel caso in cui un singolo componente venga compromesso.

Blocco dei segreti in GitHub Actions

I segreti sono solitamente l'obiettivo più attraente in qualsiasi sistema CI/CDIn GitHub Actions vengono visualizzati come segreti di repository, organizzazione o ambiente e come valori ad hoc che potresti accidentalmente inserire in configurazioni, log, cache o artefatti.

La prima cosa da interiorizzare è il modello di accesso: chiunque abbia accesso in scrittura a un repository può effettivamente leggere tutti i segreti a livello di repositoryPossono semplicemente modificare un flusso di lavoro esistente su un ramo non protetto, iniettare codice di logging o esfiltrazione ed eseguire quel flusso di lavoro per stampare o divulgare segreti. Il mascheramento nei log di GitHub è una difesa basata sul massimo sforzo, non una garanzia infallibile.

Per mantenere i segreti sopravviventi secondo quel modello, segui queste regole di base:

• Applicare il principio del privilegio minimo: qualsiasi credenziale utilizzata in un flusso di lavoro deve disporre solo delle autorizzazioni minime di cui ha assolutamente bisogno. Evitare di condividere token di amministrazione generici come segreti del flusso di lavoro.
• Preferisci i segreti dell'ambiente rispetto ai segreti del repository o dell'organizzazione per i valori sensibiliI segreti dell'ambiente sono disponibili solo per i lavori che dichiarano tale ambiente e possono essere integrati con protezioni aggiuntive, come revisori obbligatori e restrizioni di branch.
• Non memorizzare mai i segreti in testo normale nei file YAML del flusso di lavoro o nel codice archiviato nel repository. Tutto ciò che è sensibile dovrebbe passare attraverso il meccanismo GitHub Secrets o un gestore di segreti esterno.
• Evitare di utilizzare blob strutturati (JSON, YAML, XML) come singolo valore segretoIl mascheramento si basa in gran parte sulla corrispondenza esatta delle stringhe; i blob multicampo sono molto più difficili da redigere in modo affidabile. In alternativa, suddividete i dati sensibili in più voci segrete dedicate.
• Registrare esplicitamente tutti i segreti derivatiSe trasformi un segreto (Base64, codifica URL, firma JWT, ecc.) e il risultato potrebbe mai comparire nei log, registra il valore trasformato come segreto a sé stante in modo che GitHub possa tentare di mascherarlo.

La rotazione e l'igiene sono importanti tanto quanto la configurazione iniziale. Verificare periodicamente quali segreti esistono, chi e cosa ne ha effettivamente ancora bisogno, e rimuovere o ruotare quelli obsoleti. Dopo qualsiasi sospetta esposizione (ad esempio, un segreto stampato senza censura nei log o utilizzato in un'azione compromessa), eliminare immediatamente i log interessati, revocare le credenziali e crearne di nuovi.

Evitare l'iniezione di script e l'interpolazione non sicura

Una delle classi più comuni, ma sottili, di bug di GitHub Actions è l'iniezione di script tramite espressioniGitHub fornisce ricchi "contesti" come github, env, secrets e payload di eventi, a cui fai riferimento nei flussi di lavoro utilizzando ${{ ... }} sintassi. Queste espressioni vengono valutate da GitHub prima il tuo passo di shell corre.

Quando si incorpora un contesto non attendibile direttamente in un comando shell, si invita l'iniezione di comandiAd esempio, se fai:

run: echo "new issue ${{ github.event.issue.title }} created"

e un aggressore può controllare il titolo del problema, possono inviare un titolo come $(id)Dopo la valutazione dell'espressione il passaggio diventa:

echo "new issue $(id) created"

che esegue id sul corridoreNessuna modifica delle virgolette o aggiunta di una semplice convalida nella shell ti salverà in modo affidabile da questo schema.

Il modello sicuro consigliato da GitHub è quello di utilizzare una variabile di ambiente intermedia:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Qui il valore potenzialmente ostile rimane nella memoria come variabile d'ambiente, e la shell vede solo $TITLE, non una riga di comando costruita dinamicamente. È comunque necessaria la normale igiene della shell (virgolette per le variabili, evitare eval non necessari, ecc.), ma il pericoloso passaggio di interpolazione è stato rimosso.

Ogni volta che sei tentato di incorporare ${{ github.* }} o altri dati controllati dall'utente direttamente in run: blocchi, fermati e spingilo attraverso env: inveceQuesta abitudine elimina un'intera categoria di problemi di iniezione di script nei flussi di lavoro.

Configurazione sicura di permessi e token

. GITHUB_TOKEN che GitHub inserisce in ogni esecuzione del flusso di lavoro è incredibilmente potente se lasciato con i valori predefinitiPuò leggere e scrivere contenuti, aprire e aggiornare richieste pull e interagire con il repository in molti modi. Storicamente, molte organizzazioni lo avevano impostato di default in lettura e scrittura senza rendersene conto.

Il primo passaggio di rafforzamento dovrebbe essere quello di impostare le autorizzazioni predefinite del token del flusso di lavoro su sola lettura A livello di organizzazione e/o repository. Esiste un'impostazione dedicata a questo scopo nella configurazione delle Azioni. Da lì, è possibile concedere selettivamente autorizzazioni aggiuntive per flusso di lavoro o per attività, ad esempio:

permissions:
contents: read
pull-requests: write

Questo modello "nega per impostazione predefinita, consenti dove necessario" riduce drasticamente ciò che un aggressore può fare con un flusso di lavoro compromessoCostringe inoltre gli autori a riflettere sulle capacità effettivamente richieste dal loro lavoro, invece di ereditare un token generico.

Se la tua organizzazione è stata creata prima dell'inizio del 2023, dovresti verificare esplicitamente queste impostazioni predefiniteMolte organizzazioni più vecchie hanno ancora token di flusso di lavoro abilitati alla scrittura perché sono precedenti all'impostazione predefinita più sicura e non hanno mai aderito alla modifica.

Oltre agli ambiti dei token, fai molta attenzione alle impostazioni che consentono a GitHub Actions di approvare o creare richieste pullConsentire ai flussi di lavoro di convalidare automaticamente le richieste di modifica (PR) espone a percorsi di abuso in cui i processi compromessi uniscono codice dannoso senza revisione umana. A meno che non si disponga di un caso d'uso solido e di rigide misure di sicurezza, è consigliabile disattivare questa funzionalità.

Scelta e blocco delle azioni di terze parti

Ogni azione esterna che utilizzi è un pezzo di codice remoto che viene eseguito con gli stessi privilegi del resto del tuo lavoroSe tale azione diventa dannosa, viene compromessa o abbandonata con dipendenze vulnerabili, diventa un punto d'appoggio già pronto all'interno della pipeline.

Esistono diversi livelli di difesa che puoi applicare quando utilizzi azioni di terze parti:

• Inizia da una piccola lista consentita affidabileAzioni gestite da GitHub (come actions/checkout, actions/setup-node) e le azioni sul marketplace da parte di creatori verificati rappresentano solitamente una base di partenza più sicura rispetto ai repository casuali. Molte organizzazioni impongono questa opzione tramite l'opzione "Consenti azioni specifiche e flussi di lavoro riutilizzabili" a livello di organizzazione.
• Favorire azioni popolari e attivamente mantenuteLe ricerche mostrano che molte azioni del marketplace hanno punteggi OpenSSF Scorecard bassi, un solo responsabile della manutenzione e account proprietari di breve durata o molto giovani. Le azioni più diffuse tendono ad accumulare più controlli e soluzioni più rapide.
• Fai attenzione al gran numero di PR Dependabot aperti nel repository dell'azioneSpesso questo è un segnale che il manutentore non sta applicando gli aggiornamenti di sicurezza, lasciando le vulnerabilità transitive non corrette.
• Preferisci azioni con più di un manutentore e una base di codice attiva e non archiviataCentinaia di azioni sul marketplace sono archiviate, il che significa che non ci sono nuove correzioni o aggiornamenti di compatibilità e che il rischio aumenta nel tempo.

Il version pinning è un altro argomento criticoSe si specifica un'azione solo tramite tag, come some-org/some-action@v2, puoi essere certo che il tag non si sposti mai verso codice dannoso. I tag possono essere reindirizzati se l'account del responsabile o il repository vengono compromessi.

L'approccio più difensivo oggi è quello di agganciarsi a un SHA full commit:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Il pinning su un SHA rende il codice effettivamente immutabile dal tuo punto di vista (a parte un attacco di collisione SHA-1 sugli oggetti Git). Lo svantaggio è operativo: è necessario aggiornare l'SHA quando si desiderano nuove funzionalità o correzioni, e flussi di lavoro diversi possono spostarsi su SHA diversi se non si presta attenzione.

Per alleviare questo problema, alcuni team centralizzano l'utilizzo di azioni di terze parti in flussi di lavoro condivisi o compositiI singoli repository fanno riferimento a tali flussi di lavoro condivisi tramite tag, mentre i flussi di lavoro condivisi associano le azioni sottostanti agli SHA verificati e vengono aggiornati con una cadenza controllata, a volte con strumenti che aprono PR per nuovi SHA.

Qualunque strategia tu scelga, ricorda che il pinning non è un firewall magicoUn'azione può ancora recuperare dinamicamente il codice in fase di esecuzione (ad esempio tramite curl | bash pattern) e bypassare il pin. È comunque necessario esaminare attentamente la fonte per individuare pattern palesemente non sicuri prima di affidare un'azione con segreti o token scrivibili.

Progettare flussi di lavoro e lavori più sicuri

Il modo in cui si strutturano i flussi di lavoro e i lavori influenza fortemente il raggio di esplosione di un compromessoUn anti-pattern comune è un singolo lavoro di grandi dimensioni che verifica il codice, lo compila, lo testa, lo impacchetta e lo distribuisce, il tutto con ampie autorizzazioni e accesso ai segreti di produzione.

La suddivisione del lavoro in lavori separati e persino flussi di lavoro separati fornisce sia isolamento che chiarezzaAd esempio, potresti avere:

• A lavoro di compilazione e test che funziona con autorizzazioni minime e senza segreti di distribuzione.
• A lavoro di pacchetto che produce artefatti firmati ma non comunica ancora con la produzione.
• A distribuire il lavoro che dipende dagli altri ed è l'unico autorizzato ad accedere ai segreti dell'ambiente e ad assumere ruoli nel cloud.

Sui runner ospitati su GitHub, ogni processo in un flusso di lavoro viene eseguito in una nuova VM, che garantisce un certo grado di isolamento tra i processi. Non è equivalente a una sandbox rinforzata, ed esistono vettori cross-job noti (come le cache di branch condivise), ma suddividere i processi costringe comunque gli aggressori a lavorare di più e riduce la perdita accidentale di segreti in fasi non correlate.

Utilizzare ambienti per collegare i passaggi sensibili alle protezioniUn processo di distribuzione potrebbe dichiarare:

environment: production

e la production l'ambiente può quindi essere configurato per accettare solo distribuzioni da un ramo protetto, eventualmente con approvazioni manuali obbligatorie. Combinando questo con rigide regole di protezione delle filiali (revisioni obbligatorie, nessun avanzamento rapido, rigetto di approvazioni obsolete) si arriva quasi a un principio di controllo a quattro occhi per le modifiche in produzione.

Infine, fai attenzione agli artefatti, alle cache e ai registriSono modi convenienti per condividere dati tra lavori e flussi di lavoro, ma:

• Non raggruppare i segreti nelle cache, soprattutto luoghi poco conosciuti come ~/.docker/config.json che potrebbe contenere semplici credenziali Docker.
• Evitare di registrare segreti o di scaricare interi contesti nei log, poiché ciò potrebbe vanificare il mascheramento o rivelare valori derivati ​​che GitHub non sa come redigere.
• Ricorda che chiunque abbia accesso in lettura al repository può solitamente scaricare artefatti ed esplorare i log, compresi i collaboratori esterni se concedi loro l'accesso.

OIDC e credenziali cloud di breve durata

Uno dei cambiamenti più significativi che puoi apportare è smettere del tutto di archiviare le credenziali di lunga durata del provider cloud come segreti GitHubIn alternativa, utilizzare OpenID Connect (OIDC) per ottenere token di breve durata e ben definiti, associati a un'identità di flusso di lavoro specifica.

Il flusso di alto livello è semplice:

• Il tuo provider cloud (AWS, Azure, GCP, ecc.) è configurato per fidarsi del provider OIDC di GitHub.
• Definisci una policy di identità che stabilisce "accetta token solo da questa organizzazione/repository/ramo o ambiente".
• Durante un lavoro, GitHub può richiedere un token OIDC e il flusso di lavoro utilizza un'azione specifica del cloud (ad esempio aws-actions/configure-aws-credentials) per scambiarlo con un ruolo di breve durata o un token di account di servizio.

La condizione di fiducia è dove puoi ottenere informazioni molto granulariPer AWS, una policy tipica potrebbe includere:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Ciò garantisce che solo i flussi di lavoro provenienti da un repository e da un ramo specifici possano assumere il ruoloSe si desidera un ambito ancora più ristretto, è possibile associare il ruolo a un ambiente specifico anziché a un ramo e quindi richiedere tale ambiente solo per il job di distribuzione. Un'azione di terze parti compromessa in un job non di distribuzione determinerà il fallimento delle chiamate OIDC.

L'utilizzo di OIDC non elimina la necessità di policy sui ruoli con privilegi minimi nel cloud, ma elimina le chiavi di accesso statiche presenti in GitHub Secrets, dove potrebbero essere rubate e riutilizzate indefinitamente dall'esterno di GitHub.

Protezione delle filiali, set di regole e ambienti che lavorano insieme

Molti dei percorsi di attacco più spaventosi in GitHub Actions si riducono a "l'aggressore inietta modifiche dannose in un ramo protetto"La protezione dei rami e i set di regole rappresentano la tua principale linea di difesa.

Su rami come main or production, di solito vuoi almeno:

• Richiedi una richiesta pull prima di unire – non consentire spinte dirette.
• Richiedere almeno una (spesso più) revisione di approvazione da qualcuno diverso dall'ultimo pusher.
• Ignora le approvazioni obsolete quando vengono aggiunti nuovi commit – in modo che gli aggressori non possano introdurre di nascosto il codice dopo la revisione.
• Richiedi l'approvazione della spinta revisionabile più recente – impedisce a un aggressore di dirottare le pubbliche relazioni di qualcun altro, di inserire codice dannoso e di autoapprovare.

È quindi possibile collegare queste protezioni agli ambienti. Ad esempio, a production l'ambiente potrebbe accettare solo distribuzioni da main branch, e forse anche richiedere l'approvazione manuale da parte di un piccolo gruppo di revisori (con l'opzione "impedisci auto-revisione" abilitata). In questo modo, un singolo account di un collaboratore compromesso non può inviare codice arbitrario in produzione senza il coinvolgimento esplicito di qualcun altro.

Fare attenzione alle regole ambientali che dipendono dalle distribuzioni stesse (ad esempio "richiedi che le distribuzioni vadano a buon fine prima di consentire gli aggiornamenti dei tag"). Se strutturato male, si possono creare dipendenze circolari o pseudo-controlli che un collaboratore può aggirare modificando i flussi di lavoro. Il modello più sicuro rimane: forte protezione dei rami → ambienti con ambito ristretto → utilizzo esplicito di tali ambienti solo nei processi minimi che ne hanno realmente bisogno.

Gestione dei runner: ospitato su GitHub vs. ospitato autonomamente

I runner sono le macchine che eseguono effettivamente i tuoi flussi di lavoroI runner ospitati su GitHub sono VM effimere gestite da GitHub; i runner auto-ospitati sono macchine o contenitori di cui esegui il provisioning e che controlli.

I runner ospitati su GitHub sono generalmente molto più sicuri per impostazione predefinita:

• Sono effimeri e vengono ripristinati per ogni lavoro, quindi non ci sono compromessi persistenti tra le esecuzioni.
• GitHub pubblica SBOM per immagini standard (Ubuntu, Windows, macOS), consentendo di analizzare il software preinstallato alla ricerca di vulnerabilità.
• Alcuni host dannosi vengono bloccati immediatamente (ad esempio noti pool di cryptomining) tramite il /etc/hosts configurazione.

I runner auto-ospitati sono potenti ma pericolosi se non li tratti come server di produzione:

• Di solito non sono effimeri a meno che non li costruisci tu stesso, quindi qualsiasi flusso di lavoro dannoso può tentare la persistenza, lo spostamento laterale o il furto di dati.
• Spesso hanno un accesso di rete più ampio e segreti locali (chiavi SSH, CLI cloud, servizi di metadati), che aumentano la posta in gioco di qualsiasi compromesso.
• I repository pubblici non dovrebbero quasi mai utilizzare runner auto-ospitati, perché chiunque può aprire una richiesta pull che finisce per eseguire codice sulla tua infrastruttura.

Se devi utilizzare runner auto-ospitati, suddividili in base ai limiti di fiduciaUtilizzare gruppi di corridori e restrizioni in modo che:

• I progetti pubblici e privati ​​non condividono mai lo stesso pool di runner.
• I repository ad alta sensibilità (ad esempio le infrastrutture di produzione) dispongono di propri runner strettamente controllati.
• Solo repository o organizzazioni specifici possono inviare lavori a un determinato gruppo.

È possibile ridurre ulteriormente il rischio con i runner just-in-time (JIT) forniti tramite l'API RESTQuesti runner si registrano dinamicamente, eseguono al massimo un job e poi vengono rimossi automaticamente. È comunque necessario assicurarsi che l'host sottostante venga ripulito o distrutto, ma ciò riduce la finestra temporale in cui un job compromesso può influire su quelli successivi.

Tratta i runner auto-ospitati come qualsiasi altro sistema di produzione: monitorare l'attività dei processi, bloccare i percorsi di rete in uscita, mantenere aggiornati il ​​sistema operativo e gli strumenti e presumere che qualsiasi utente con l'autorizzazione ad attivare flussi di lavoro abbia effettivamente l'esecuzione del codice su quella macchina.

Funzionalità di sicurezza integrate: scansione del codice, Scorecard e Dependabot

GitHub fornisce una serie di funzionalità di prima classe specificamente mirate a far emergere il flusso di lavoro e il rischio di dipendenzae valgono il piccolo costo di installazione.

La scansione del codice (ad esempio con CodeQL) ora può analizzare autonomamente i flussi di lavoro di GitHub Actions, non solo la fonte dell'applicazione. Regole come "Esposizione eccessiva di segreti" possono rilevare schemi in cui GitHub non riesce a determinare quali segreti sono richiesti (ad esempio, dinamici secrets[myKey] utilizzo nelle build di matrice), che porta a caricare più segreti del necessario nella memoria del lavoro.

Le scorecard OpenSSF e l'azione Scorecard aggiungono un ulteriore livello valutando la posizione di sicurezza delle tue dipendenzePer le azioni sul mercato, le Scorecard possono segnalare pratiche non sicure nella catena di fornitura, come:

• Non bloccare le dipendenze.
• Mancano protezioni di diramazione o requisiti di revisione del codice.
• Mancanza di policy di sicurezza o di processi di risposta alle vulnerabilità.

Dependabot svolge due ruoli qui:

• Avvisi Dependabot avvisarti quando una dipendenza delle tue azioni o dei tuoi flussi di lavoro presenta una vulnerabilità nota, in base al database consultivo di GitHub.
• Aggiornamenti di versione e sicurezza di Dependabot può aprire automaticamente le PR per aumentare le versioni di azione e correggere le versioni vulnerabili.

Il grafico delle dipendenze per i flussi di lavoro è un'altra funzionalità sottovalutataGitHub tratta i file del flusso di lavoro come manifesti e può mostrarti:

• Da quali azioni e flussi di lavoro riutilizzabili dipendi.
• Quali account o organizzazioni ne sono proprietari.
• Quali versioni o SHA hai aggiunto.

Ciò semplifica la risposta a domande come "Dove stiamo utilizzando questa azione compromessa?" quando vengono emessi nuovi avvisi e per pianificare interventi di bonifica su larga scala.

Monitoraggio, audit e governance

La sicurezza non finisce con la configurazione; è necessaria anche la visibilità di ciò che accade nel tempoGitHub fornisce registri di controllo e registri di sicurezza sia a livello di utente che di organizzazione.

Dal punto di vista delle azioni, ci sono diverse cose che vale la pena monitorare:

• Eventi legati ai segreti, come org.update_actions_secret o modifiche ai segreti del repository. Indicano la creazione, l'aggiornamento o l'eliminazione di credenziali sensibili.
• Modifiche al flusso di lavoro e al set di regole: chi ha modificato le regole di protezione, chi ha modificato i flussi di lavoro di distribuzione, chi ha cambiato le protezioni dell'ambiente.
• Nuove o modificate azioni del marketplace e app GitHub installati nell'organizzazione, in particolare quelli a cui sono concessi ampi ambiti di repository o di organizzazione.

È possibile integrare i controlli di GitHub con app di applicazione delle policy come Allstar di OpenSSF, che verifica costantemente che i repository siano conformi ai requisiti di sicurezza di base della tua organizzazione (protezioni delle filiali, scansione del codice abilitata, revisioni obbligatorie, ecc.).

Per quanto riguarda i flussi di lavoro in esecuzione, tieni d’occhio i modelli che potrebbero suggerire un abuso: picchi insoliti nei tempi di esecuzione dei job, traffico in uscita inaspettato dai runner o job che falliscono frequentemente in corrispondenza di passaggi che gestiscono segreti o token OIDC. Questi non sono sempre dannosi, ma rappresentano un buon punto di partenza per le indagini.

Mettere tutto questo insieme significa pensare a GitHub Actions come parte della tua superficie di produzione principale, non solo "script di colla". Con segreti e token attentamente definiti, rigide protezioni di branch e ambienti, un uso conservativo di azioni di terze parti, runner rinforzati e un monitoraggio continuo con strumenti come CodeQL, Scorecard e Dependabot, offri alla tua organizzazione una possibilità di combattere la crescente classe di attacchi CI/CD e alla supply chain che prendono di mira esplicitamente i flussi di lavoro di GitHub.