Cache di GitHub Actions: come funziona e che cosa nasconde

Come funziona la cache

L'action actions/cache salva un insieme di percorsi sotto una chiave alla fine di un job e li ripristina all'inizio di un job successivo. Una tipica configurazione npm mette in cache la cache di download del package manager e ne basa la chiave sul lockfile:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      npm-${{ runner.os }}-
- run: npm ci

Al ripristino, l'action cerca prima una corrispondenza esatta con key, poi una corrispondenza parziale, poi ciascun prefisso di restore-keys a turno. Quando più cache corrispondono a un prefisso, ripristina quella creata più di recente. Questo ripiego è ciò che mantiene veloci le build dopo una modifica del lockfile, e significa anche che un job può partire da una cache creata per un lockfile più vecchio.

Spesso l'action non serve affatto. setup-node, setup-python, setup-java, setup-go, setup-ruby e setup-dotnet hanno il caching integrato. Per Node.js, setup-node mette in cache i dati globali dei pacchetti per npm, Yarn e pnpm, non node_modules, e attiva automaticamente il caching npm quando package.json dichiara npm come suo packageManager.

Ambito e limiti

Regola	Che cosa fa GitHub
Quali cache può ripristinare un'esecuzione	Quelle del proprio branch e del branch predefinito; le pull request anche quelle del branch di base
Che cosa può scrivere una pull request	Solo cache limitate al suo merge ref, non al branch predefinito
Spazio di archiviazione	10 GB per repository per impostazione predefinita; i proprietari di organizzazioni ed enterprise possono aumentarlo
Rimozione	Le voci a cui non si accede da oltre 7 giorni e, quando lo spazio è pieno, quelle usate meno di recente
Secret	Non li metta in cache: chiunque abbia accesso alle pull request può leggere il contenuto delle cache

Che cosa la cache nasconde alla Sua SBOM

Una cache è una scorciatoia che aggira il registry dei pacchetti. È il suo scopo, ed è anche il motivo per cui confonde qualsiasi registro di ciò che una build ha usato:

• Nessun download, nessuna traccia. I pacchetti ripristinati da una cache vengono installati senza alcuna richiesta al registry. Un registro costruito dal traffico di rete della build non li vede, a meno che non segua la cache.
• Vecchi contenuti sotto una nuova chiave. Una corrispondenza parziale di restore-keys ripristina una cache creata per un lockfile precedente. L'installazione aggiunge o sostituisce poi ciò che è cambiato, ma il punto di partenza del job non è ciò che descrive il lockfile attuale.
• Più delle Sue dipendenze. Le cache contengono anche strumenti di build, compilatori e file generati, che nessun manifest applicativo elenca.
• Una scansione non può saperlo. Una SBOM basata sul lockfile descrive ciò che dice il lockfile, che il job abbia installato esattamente quello dalla sua cache oppure no.

Per capire come si inserisce nel problema più ampio, veda perché un lockfile non è un registro di ciò che è stato distribuito e le dipendenze transitive.

Avvelenamento della cache

Le cache sono condivise tra i workflow di un repository, e questo le rende un canale tra di essi. Nel maggio 2024 il ricercatore di sicurezza Adnan Khan ha dimostrato che chiunque possa eseguire codice nel contesto del branch predefinito, tramite un workflow pull_request_target vulnerabile o una dipendenza compromessa, può sovrascrivere file nei workflow che ripristinano le cache. Con il token della cache di un job in esecuzione, un attaccante può riempire la cache del repository in modo che GitHub rimuova le voci legittime, per poi scriverne di avvelenate sotto le stesse chiavi. Un workflow di release che le ripristina esegue i file dell'attaccante con i propri secret.

Per ridurre il rischio:

• Compili le release da uno stato pulito, oppure da cache scritte solo dal workflow di release.
• Non esegua mai codice non attendibile di una pull request nel contesto del branch predefinito.
• Tenga secret e token fuori dai percorsi in cache.
• Tratti ciò che una cache ha ripristinato come un input della build che richiede la stessa attenzione di un download.

Come CRACI gestisce le cache

CRACI è un runner GitHub Actions, quindi actions/cache e le cache setup-* funzionano come oggi, insieme al caching dei layer dei container. Il caching è anche uno dei motivi per cui CRACI esegue le build a una velocità circa doppia rispetto ai runner ospitati da GitHub, con hardware più veloce e tempi di coda più brevi.

Ciò che cambia è il registro. Il proxy di CRACI che riconosce i pacchetti registra i pacchetti scaricati da un job, e le evidenze viaggiano con le cache: quando un job ripristina una cache, CRACI riporta le dipendenze che conosce nella SBOM di quel job.

• Completezza per cache. Ogni cache ha uno stato di completezza, come ogni job. Un job che ripristina una cache incompleta ottiene una SBOM incompleta, e una cache da esso prodotta porta con sé quello stato, così una lacuna non diventa mai silenziosamente un registro completo.
• Nessuna congettura dall'archivio. CRACI non legge i manifest dei pacchetti all'interno dell'archivio della cache. Sa che cosa c'è in una cache perché ha registrato il job che l'ha prodotta.
• Una cache per ogni job produttore mantiene affidabili queste evidenze, insieme a una policy di egress impostata su default: deny nel job produttore. La guida su cache e completezza della SBOM riporta i dettagli.

Veda le SBOM in fase di build per capire come funziona la registrazione, oppure prenoti una demo per eseguire uno dei Suoi workflow con cache su CRACI.

Cache di GitHub Actions: domande frequenti

Per quanto tempo GitHub conserva una cache di Actions?

GitHub rimuove le voci della cache a cui non si accede da oltre 7 giorni. Quando un repository supera il limite di spazio, 10 GB per impostazione predefinita, rimuove anche le cache in ordine di ultimo accesso, a partire dalle più vecchie.

setup-node mette in cache node_modules?

No. L'input cache di actions/setup-node mette in cache i dati globali dei pacchetti del package manager per npm, Yarn o pnpm, non node_modules. Il passaggio di installazione viene comunque eseguito, ma legge i pacchetti dalla cache ripristinata invece di scaricarli.

Una pull request può leggere le cache del branch principale?

Sì. Un'esecuzione di workflow può ripristinare le cache del proprio branch e del branch predefinito, e una pull request può ripristinare anche quelle del suo branch di base. Le cache create in una pull request sono limitate al suo merge ref, quindi non possono essere scritte nell'ambito del branch predefinito.

È sicuro usare la cache di Actions nei workflow di release?

È un compromesso. Una ricerca pubblicata nel 2024 ha dimostrato che chiunque possa eseguire codice in un workflow del branch predefinito può avvelenare le cache ripristinate da altri workflow, compresi quelli di release. I workflow che pubblicano release o detengono secret di deployment sono più sicuri se compilano da uno stato pulito o da cache scritte solo da loro.

Una cache ripristinata modifica la mia SBOM?

Può farlo. I pacchetti ripristinati da una cache vengono installati senza essere scaricati, quindi un registro costruito dal traffico di rete non li vede, a meno che non tenga traccia della cache. E una scansione del lockfile non Le dice se la cache conteneva esattamente quelle versioni.