GitHub Actions-cache: sådan virker den, og hvad den skjuler

Sådan virker cachen

Actionen actions/cache gemmer et sæt stier under en nøgle ved slutningen af et job og gendanner dem ved starten af et senere job. En typisk npm-opsætning cacher pakkehåndteringens download-cache og bruger lockfilen som nøgle:

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

Ved gendannelse leder actionen først efter et eksakt match på key, derefter et delvist match og så hvert restore-keys-præfiks efter tur. Når flere caches matcher et præfiks, gendanner den den senest oprettede. Den reserveløsning holder builds hurtige, efter at lockfilen er ændret, og den betyder også, at et job kan starte fra en cache, der blev bygget til en ældre lockfile.

Ofte har du slet ikke brug for actionen. setup-node, setup-python, setup-java, setup-go, setup-ruby og setup-dotnet har indbygget caching. For Node.js cacher setup-node globale pakkedata for npm, Yarn og pnpm, ikke node_modules, og slår automatisk npm-caching til, når package.json deklarerer npm som sin packageManager.

Omfang og grænser

Regel	Hvad GitHub gør
Hvilke caches en kørsel kan gendanne	Sin egen branch og default-branchen; pull requests også deres base-branch
Hvad en pull request kan skrive	Kun caches afgrænset til dens merge-ref, ikke til default-branchen
Lagerplads	10 GB pr. repository som standard; ejere af organisationer og enterprises kan hæve grænsen
Fjernelse	Poster, der ikke er brugt i over 7 dage, og dem, der har ligget længst ubrugt, når lagerpladsen er fuld
Secrets	Cache dem ikke: Alle med adgang til pull requests kan læse cacheindholdet

Hvad cachen skjuler for din SBOM

En cache er en genvej uden om pakkeregistryet. Det er hele pointen, og det er også derfor, den forvirrer enhver registrering af, hvad et build brugte:

Ingen download, intet spor. Pakker gendannet fra en cache installeres uden en forespørgsel til registryet. En registrering bygget på buildets netværkstrafik overser dem, medmindre den følger cachen.
Gammelt indhold under en ny nøgle. Et delvist restore-keys-match gendanner en cache bygget til en tidligere lockfile. Installationen tilføjer eller erstatter derefter det, der er ændret, men det, jobbet startede fra, er ikke det, den aktuelle lockfile beskriver.
Mere end dine afhængigheder. Caches indeholder også build-værktøjer, compilere og genererede filer, som intet applikationsmanifest angiver.
En scanning kan ikke se forskellen. En lockfile-baseret SBOM beskriver, hvad lockfilen siger, uanset om jobbet installerede præcis det fra sin cache.

Hvordan det hænger sammen med det større problem, kan du se i hvorfor en lockfile ikke er en registrering af det leverede og transitive afhængigheder.

Cacheforgiftning

Caches deles på tværs af workflows i et repository, og det gør dem til en vej mellem dem. I maj 2024 viste sikkerhedsforskeren Adnan Khan, at enhver, der kan køre kode i default-branchens kontekst, gennem et sårbart pull_request_target-workflow eller en kompromitteret afhængighed, kan overskrive filer i workflows, der gendanner caches. Med cache-tokenet fra et kørende job kan en angriber fylde repositoryets cache, så GitHub fjerner legitime poster, og derefter skrive forgiftede poster under de samme nøgler. Et release-workflow, der gendanner dem, kører angriberens filer med sine egne secrets.

Sådan mindsker du risikoen:

Byg releases fra en ren tilstand eller fra caches, som kun release-workflowet skriver.
Kør aldrig pull request-kode, du ikke stoler på, i en default-branch-kontekst.
Hold secrets og tokens ude af cachede stier.
Behandl det, en cache har gendannet, som input til buildet, der kræver samme granskning som en download.

Sådan håndterer CRACI caches

CRACI er en GitHub Actions-runner, så actions/cache og setup-*-cachene virker, som de gør i dag, side om side med caching af containerlag. Caching er også en del af grunden til, at CRACI kører builds omkring dobbelt så hurtigt som GitHub-hostede runnere, med hurtigere hardware og kortere køtider.

Det, der ændrer sig, er registreringen. CRACI's pakkebevidste proxy registrerer de pakker, et job henter, og dokumentationen følger med cachen: Når et job gendanner en cache, fører CRACI de afhængigheder, det kender til, videre ind i jobbets SBOM.

Fuldstændighed pr. cache. Hver cache har en fuldstændighedsstatus, ligesom hvert job. Et job, der gendanner en ufuldstændig cache, får en ufuldstændig SBOM, og en cache, jobbet producerer, fører den status videre, så et hul aldrig stille og roligt bliver til en komplet registrering.
Intet gætteri ud fra arkivet. CRACI læser ikke pakkemanifester inde i cachearkivet. Det ved, hvad der er i en cache, fordi det registrerede det job, der producerede den.
Én cache pr. producerende job holder dokumentationen pålidelig, sammen med en egress-politik sat til default: deny i det producerende job. Du finder detaljerne i guiden til cache og SBOM-fuldstændighed.

Se SBOM'er fra buildet for, hvordan registreringen virker, eller book en demo for at køre et af dine cachede workflows på CRACI.

GitHub Actions-cache: ofte stillede spørgsmål

Hvor længe gemmer GitHub en Actions-cache?

GitHub fjerner cacheposter, der ikke er brugt i over 7 dage. Når et repository overskrider sin lagergrænse, som standard 10 GB, fjerner det også caches efter seneste brug, de ældste først.

Cacher setup-node node_modules?

Nej. Cache-inputtet i actions/setup-node cacher pakkehåndteringens globale pakkedata for npm, Yarn eller pnpm, ikke node_modules. Installationstrinnet kører stadig, men det læser pakker fra den gendannede cache i stedet for at downloade dem.

Kan en pull request læse caches fra main-branchen?

Ja. En workflow-kørsel kan gendanne caches fra sin egen branch og default-branchen, og en pull request kan også gendanne caches fra sin base-branch. Caches oprettet i en pull request er afgrænset til dens merge-ref, så de kan ikke skrives ind i default-branchens område.

Er det sikkert at bruge Actions-cachen i release-workflows?

Det er en afvejning. Forskning offentliggjort i 2024 viste, at enhver, der kan køre kode i et default-branch-workflow, kan forgifte caches, som andre workflows gendanner, inklusive release-workflows. Workflows, der udgiver releases eller har adgang til deployment-secrets, er mere sikre, når de bygger fra en ren tilstand eller fra caches, kun de selv skriver.

Ændrer en gendannet cache min SBOM?

Det kan den. Pakker gendannet fra en cache installeres uden at blive downloadet, så en registrering bygget på netværkstrafik overser dem, medmindre den sporer cachen. Og en scanning af lockfilen fortæller dig ikke, om cachen indeholdt præcis de versioner.