GitHub Actions-cachen: så fungerar den och vad den döljer

Så fungerar cachen

Actionen actions/cache sparar en uppsättning sökvägar under en nyckel i slutet av ett jobb och återställer dem i början av ett senare. En typisk npm-konfiguration cachar pakethanterarens nedladdningscache och baserar nyckeln 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

Vid återställning letar actionen först efter en exakt träff på key, sedan efter en partiell träff och sedan efter varje prefix i restore-keys i tur och ordning. När flera cachar matchar ett prefix återställs den senast skapade. Den reservvägen håller byggena snabba efter att lockfilen ändrats, och den betyder också att ett jobb kan starta från en cache som byggdes för en äldre lockfile.

Ofta behöver du inte actionen alls. setup-node, setup-python, setup-java, setup-go, setup-ruby och setup-dotnet har inbyggd cachning. För Node.js cachar setup-node global paketdata för npm, Yarn och pnpm, inte node_modules, och slår på cachning för npm automatiskt när package.json anger npm som sin packageManager.

Omfång och gränser

Regel	Vad GitHub gör
Vilka cachar en körning kan återställa	Sin egen grens och standardgrenens; pull requests även sin basgrens
Vad en pull request kan skriva	Bara cachar avgränsade till dess merge-ref, inte till standardgrenen
Lagring	10 GB per repo som standard; ägare av organisationer och företagskonton kan höja gränsen
Rensning	Poster som inte använts på över 7 dagar, och de minst nyligen använda när lagringen är full
Hemligheter	Cacha dem inte: alla med åtkomst till pull requests kan läsa cacheinnehållet

Vad cachen döljer för din SBOM

En cache är en genväg förbi paketregistret. Det är hela poängen med den, och det är också därför den ställer till det för varje registrering av vad ett bygge använde:

Ingen nedladdning, inga spår. Paket som återställs från en cache installeras utan någon begäran till registret. En registrering som bygger på byggets nätverkstrafik missar dem om den inte följer cachen.
Gammalt innehåll under en ny nyckel. En partiell träff på restore-keys återställer en cache som byggts för en tidigare lockfile. Installationen lägger sedan till eller ersätter det som ändrats, men det jobbet startade från är inte det som den aktuella lockfilen beskriver.
Mer än dina beroenden. Cachar innehåller också byggverktyg, kompilatorer och genererade filer, som inget applikationsmanifest listar.
En skanning kan inte avgöra det. En lockfile-baserad SBOM beskriver vad lockfilen säger, oavsett om jobbet installerade exakt det från sin cache.

Läs mer om hur detta hänger ihop med det större problemet i varför en lockfile inte är en registrering av vad som levererades och transitiva beroenden.

Cacheförgiftning

Cachar delas mellan arbetsflöden i ett repo, vilket gör dem till en väg mellan arbetsflödena. I maj 2024 visade säkerhetsforskaren Adnan Khan att den som kan köra kod i standardgrenens kontext, via ett sårbart pull_request_target-arbetsflöde eller ett komprometterat beroende, kan skriva över filer i arbetsflöden som återställer cachar. Med cachetoken från ett körande jobb kan en angripare fylla repots cache så att GitHub rensar bort legitima poster, och sedan skriva förgiftade poster under samma nycklar. Ett release-arbetsflöde som återställer dem kör angriparens filer med sina egna hemligheter.

Så minskar du risken:

Bygg releaser från ett rent läge, eller från cachar som bara release-arbetsflödet skriver.
Kör aldrig opålitlig kod från pull requests i standardgrenens kontext.
Håll hemligheter och tokens borta från cachade sökvägar.
Behandla det som en cache återställde som indata till bygget, som behöver samma granskning som en nedladdning.

Så hanterar CRACI cachar

CRACI är en GitHub Actions-runner, så actions/cache och setup-*-cacharna fungerar som de gör i dag, tillsammans med cachning av containerlager. Cachning är också en del av förklaringen till att CRACI kör byggen ungefär dubbelt så snabbt som GitHub-hostade runners, med snabbare hårdvara och kortare kötider.

Det som ändras är registreringen. CRACI:s paketmedvetna proxy registrerar paketen som ett jobb hämtar, och bevisen följer med cacharna: när ett jobb återställer en cache för CRACI de beroenden den känner till vidare in i det jobbets SBOM.

Fullständighet per cache. Varje cache har en fullständighetsstatus, precis som varje jobb. Ett jobb som återställer en ofullständig cache får en ofullständig SBOM, och en cache som jobbet producerar för den statusen vidare, så att en lucka aldrig i tysthet blir en komplett registrering.
Inga gissningar utifrån arkivet. CRACI läser inte paketmanifest inne i cachearkivet. Den vet vad som finns i en cache eftersom den registrerade jobbet som producerade den.
En cache per producerande jobb håller bevisen tillförlitliga, tillsammans med en egress-policy satt till default: deny i det producerande jobbet. Guiden om cachar och SBOM-fullständighet har detaljerna.

Se SBOM:er från bygget för hur registreringen fungerar, eller boka en demo för att köra ett av dina cachade arbetsflöden på CRACI.

GitHub Actions-cachen: vanliga frågor

Hur länge sparar GitHub en Actions-cache?

GitHub tar bort cacheposter som inte har använts på över 7 dagar. När ett repo går över sin lagringsgräns, 10 GB som standard, rensar GitHub också cachar efter senaste användning, äldst först.

Cachar setup-node node_modules?

Nej. Inställningen cache i actions/setup-node cachar pakethanterarens globala paketdata för npm, Yarn eller pnpm, inte node_modules. Installationssteget körs fortfarande, men det läser paket från den återställda cachen i stället för att ladda ner dem.

Kan en pull request läsa cachar från huvudgrenen?

Ja. En arbetsflödeskörning kan återställa cachar från sin egen gren och standardgrenen, och en pull request kan även återställa cachar från sin basgren. Cachar som skapas i en pull request är avgränsade till dess merge-ref, så de kan inte skrivas in i standardgrenens omfång.

Är det säkert att använda Actions-cachen i release-arbetsflöden?

Det är en avvägning. Forskning som publicerades 2024 visade att den som kan köra kod i ett arbetsflöde på standardgrenen kan förgifta cachar som andra arbetsflöden återställer, inklusive release-arbetsflöden. Arbetsflöden som publicerar releaser eller har tillgång till hemligheter för driftsättning är säkrare om de bygger från ett rent läge eller från cachar som bara de själva skriver.

Ändrar en återställd cache min SBOM?

Det kan den. Paket som återställs från en cache installeras utan att laddas ner, så en registrering som bygger på nätverkstrafik missar dem om den inte spårar cachen. Och en skanning av lockfilen säger inte om cachen innehöll exakt de versionerna.