GitHub Actions-cachen: slik fungerer den, og dette skjuler den

Slik fungerer cachen

Actionen actions/cache lagrer et sett stier under en nøkkel på slutten av en jobb og gjenoppretter dem ved starten av en senere jobb. Et typisk npm-oppsett cacher nedlastingscachen til pakkebehandleren og baserer nøkkelen på lockfilen:

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

Ved gjenoppretting ser actionen først etter et nøyaktig treff på key, deretter et delvis treff og så hvert restore-keys-prefiks etter tur. Når flere cacher matcher et prefiks, gjenoppretter den den sist opprettede. Det er denne reserveløsningen som holder byggene raske etter at lockfilen er endret, og den betyr også at en jobb kan starte fra en cache som ble bygget for en eldre lockfile.

Ofte trenger du ikke actionen i det hele tatt. setup-node, setup-python, setup-java, setup-go, setup-ruby og setup-dotnet har innebygd caching. For Node.js cacher setup-node globale pakkedata for npm, Yarn og pnpm, ikke node_modules, og slår på npm-caching automatisk når package.json deklarerer npm som packageManager.

Omfang og grenser

Regel	Hva GitHub gjør
Hvilke cacher en kjøring kan gjenopprette	Fra sin egen gren og standardgrenen; pull requests også fra basisgrenen sin
Hva en pull request kan skrive	Bare cacher avgrenset til merge-refen sin, ikke til standardgrenen
Lagring	10 GB per repositorium som standard; organisasjons- og enterprise-eiere kan øke det
Fjerning	Oppføringer som ikke er brukt på over 7 dager, og de minst nylig brukte når lagringen er full
Hemmeligheter	Ikke cache dem: Alle med tilgang til pull requests kan lese innholdet i cachen

Dette skjuler cachen for SBOM-en din

En cache er en snarvei forbi pakkeregisteret. Det er hele poenget, og det er også derfor den forvirrer enhver registrering av hva et bygg brukte:

• Ingen nedlasting, ingen spor. Pakker gjenopprettet fra en cache installeres uten en forespørsel til registeret. En registrering basert på byggets nettverkstrafikk går glipp av dem hvis den ikke følger cachen.
• Gammelt innhold under en ny nøkkel. Et delvis restore-keys-treff gjenoppretter en cache bygget for en tidligere lockfile. Installasjonen legger så til eller erstatter det som er endret, men det jobben startet fra, er ikke det den gjeldende lockfilen beskriver.
• Mer enn avhengighetene dine. Cacher inneholder også byggeverktøy, kompilatorer og genererte filer, som ikke står i noe applikasjonsmanifest.
• En skanning kan ikke se det. En lockfile-basert SBOM beskriver det lockfilen sier, uansett om jobben installerte akkurat det fra cachen sin.

Hvordan dette passer inn i det større problemet, ser du i hvorfor en lockfile ikke viser hva som ble levert og transitive avhengigheter.

Cacheforgiftning

Cacher deles mellom workflows i et repositorium, og det gjør dem til en vei mellom dem. I mai 2024 viste sikkerhetsforskeren Adnan Khan at alle som kan kjøre kode i konteksten til standardgrenen, gjennom en sårbar pull_request_target-workflow eller en kompromittert avhengighet, kan overskrive filer i workflows som gjenoppretter cacher. Med cache-tokenet fra en kjørende jobb kan en angriper fylle repositoriets cache slik at GitHub fjerner legitime oppføringer, og deretter skrive forgiftede oppføringer under de samme nøklene. En release-workflow som gjenoppretter dem, kjører angriperens filer med sine egne hemmeligheter.

Slik reduserer du risikoen:

• Bygg utgivelser fra en ren tilstand, eller fra cacher som bare release-workflowen skriver.
• Kjør aldri upålitelig pull request-kode i konteksten til standardgrenen.
• Hold hemmeligheter og tokens utenfor cachede stier.
• Behandle det en cache gjenopprettet, som inndata til bygget som må granskes like nøye som en nedlasting.

Slik håndterer CRACI cacher

CRACI er en GitHub Actions-runner, så actions/cache og setup-*-cachene fungerer som de gjør i dag, sammen med caching av containerlag. Caching er også en del av grunnen til at CRACI kjører bygg omtrent dobbelt så raskt som GitHub-hostede runnere, med raskere maskinvare og kortere køtider.

Det som endrer seg, er registreringen. Den pakkebevisste proxyen i CRACI registrerer pakkene en jobb henter, og dokumentasjonen følger med cachene: Når en jobb gjenoppretter en cache, tar CRACI med seg avhengighetene det kjenner til, inn i SBOM-en til den jobben.

• Fullstendighet per cache. Hver cache har en fullstendighetsstatus, akkurat som hver jobb. En jobb som gjenoppretter en ufullstendig cache, får en ufullstendig SBOM, og en cache den produserer, tar med seg den statusen videre, så et hull aldri stille blir til en fullstendig registrering.
• Ingen gjetting ut fra arkivet. CRACI leser ikke pakkemanifester inne i cachearkivet. Det vet hva som er i en cache, fordi det registrerte jobben som produserte den.
• Én cache per produserende jobb holder den dokumentasjonen pålitelig, sammen med en egress-policy satt til default: deny i den produserende jobben. Detaljene finner du i guiden om cache og SBOM-fullstendighet.

Se SBOM-er fra bygget for hvordan registreringen fungerer, eller book en demo for å kjøre en av dine cachede workflows på CRACI.

GitHub Actions-cachen: ofte stilte spørsmål

Hvor lenge beholder GitHub en Actions-cache?

GitHub fjerner cacheoppføringer som ikke er brukt på over 7 dager. Når et repositorium går over lagringsgrensen, som er 10 GB som standard, fjerner den også cacher etter siste bruk, eldste først.

Cacher setup-node node_modules?

Nei. Input-en cache i actions/setup-node cacher pakkebehandlerens globale pakkedata for npm, Yarn eller pnpm, ikke node_modules. Installasjonssteget kjører fortsatt, men det leser pakker fra den gjenopprettede cachen i stedet for å laste dem ned.

Kan en pull request lese cacher fra main-grenen?

Ja. En workflow-kjøring kan gjenopprette cacher fra sin egen gren og standardgrenen, og en pull request kan også gjenopprette cacher fra basisgrenen sin. Cacher opprettet i en pull request er avgrenset til merge-refen, så de kan ikke skrives inn i standardgrenens omfang.

Er det trygt å bruke Actions-cachen i release-workflows?

Det er en avveining. Forskning publisert i 2024 viste at alle som kan kjøre kode i en workflow på standardgrenen, kan forgifte cacher som andre workflows gjenoppretter, også release-workflows. Workflows som publiserer utgivelser eller har hemmeligheter for utrulling, er tryggere når de bygger fra en ren tilstand eller fra cacher bare de selv skriver.

Endrer en gjenopprettet cache SBOM-en min?

Det kan den. Pakker gjenopprettet fra en cache installeres uten å bli lastet ned, så en registrering basert på nettverkstrafikk går glipp av dem hvis den ikke sporer cachen. Og en skanning av lockfilen forteller deg ikke om cachen inneholdt akkurat de versjonene.