Cache GitHub Actions: jak funguje a co skrývá před SBOM

Jak cache funguje

Akce actions/cache na konci jobu uloží sadu cest pod klíčem a na začátku pozdějšího jobu je obnoví. Typické nastavení pro npm ukládá do cache stahovací cache správce balíčků a jako klíč používá lockfile:

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

Při obnovení akce nejprve hledá přesnou shodu s key, pak částečnou shodu a pak postupně každý prefix restore-keys. Když prefixu odpovídá více cache, obnoví tu naposledy vytvořenou. Právě tento záložní postup udržuje buildy rychlé i po změně lockfilu, a zároveň znamená, že job může začít z cache, která vznikla pro starší lockfile.

Často akci vůbec nepotřebujete. setup-node, setup-python, setup-java, setup-go, setup-ruby a setup-dotnet mají cache vestavěnou. Pro Node.js setup-node ukládá do cache globální data balíčků pro npm, Yarn a pnpm, ne node_modules, a cache pro npm zapne automaticky, když package.json deklaruje npm jako svůj packageManager.

Rozsah a limity

Pravidlo	Co dělá GitHub
Které cache může běh obnovit	Ze své vlastní větve a z výchozí větve; pull requesty také ze své cílové větve
Co může pull request zapsat	Jen cache vázané na jeho merge ref, ne na výchozí větev
Úložiště	Ve výchozím stavu 10 GB na repozitář; vlastníci organizace a enterprise ho mohou navýšit
Vyřazování	Položky, ke kterým nikdo nepřistoupil déle než 7 dní, a při plném úložišti ty nejdéle nepoužité
Tajné klíče	Neukládejte je do cache: kdokoli s přístupem k pull requestům může obsah cache číst

Co cache skrývá před vaší SBOM

Cache je zkratka, která obchází registr balíčků. V tom je její smysl, a právě proto mate každý záznam o tom, co build použil:

Žádné stažení, žádná stopa. Balíčky obnovené z cache se instalují bez požadavku na registr. Záznam sestavený ze síťového provozu buildu je přehlédne, pokud cache nesleduje.
Starý obsah pod novým klíčem. Částečná shoda restore-keys obnoví cache vytvořenou pro dřívější lockfile. Instalace pak přidá nebo nahradí, co se změnilo, ale to, z čeho job začínal, neodpovídá tomu, co popisuje aktuální lockfile.
Víc než vaše závislosti. Cache obsahují také nástroje pro build, kompilátory a generované soubory, které žádný manifest aplikace neuvádí.
Sken to nepozná. SBOM založená na lockfilu popisuje, co říká lockfile, bez ohledu na to, zda job z cache nainstaloval přesně to.

Jak to zapadá do širšího problému, popisují články proč lockfile není záznamem toho, co bylo vydáno a tranzitivní závislosti.

Otrávení cache

Cache jsou sdílené mezi workflow v repozitáři, a tím mezi nimi vytvářejí cestu. V květnu 2024 bezpečnostní výzkumník Adnan Khan ukázal, že kdokoli, kdo dokáže spustit kód v kontextu výchozí větve, ať už přes zranitelný workflow pull_request_target, nebo přes kompromitovanou závislost, může přepsat soubory ve workflow, které cache obnovují. S tokenem cache z běžícího jobu může útočník zaplnit cache repozitáře tak, že GitHub vyřadí legitimní položky, a pak pod stejnými klíči zapsat otrávené. Workflow pro vydání, který je obnoví, spustí soubory útočníka se svými vlastními tajnými klíči.

Jak riziko snížit:

Sestavujte vydání z čistého stavu nebo z cache, do kterých zapisuje jen workflow pro vydání.
Nikdy nespouštějte nedůvěryhodný kód z pull requestů v kontextu výchozí větve.
Nedávejte tajné klíče a tokeny do cest ukládaných do cache.
Berte to, co cache obnovila, jako vstup buildu, který si zaslouží stejnou kontrolu jako stažený soubor.

Jak CRACI pracuje s cache

CRACI je runner pro GitHub Actions, takže actions/cache a cache akcí setup-* fungují stejně jako dnes, spolu s cache vrstev kontejnerů. Cache je také jedním z důvodů, proč CRACI spouští buildy zhruba dvakrát rychleji než runnery hostované na GitHubu, vedle rychlejšího hardwaru a kratších front.

Mění se záznam. Proxy CRACI, který rozumí balíčkům, zaznamenává balíčky, které job stáhne, a důkazy putují spolu s cache: když job obnoví cache, CRACI přenese závislosti, o kterých ví, do SBOM tohoto jobu.

Úplnost pro každou cache. Každá cache má stav úplnosti, stejně jako každý job. Job, který obnoví neúplnou cache, dostane neúplnou SBOM a cache, kterou vytvoří, tento stav přenáší dál, takže mezera se nikdy potichu nezmění v úplný záznam.
Žádné hádání z archivu. CRACI nečte manifesty balíčků uvnitř archivu cache. Ví, co cache obsahuje, protože zaznamenal job, který ji vytvořil.
Jedna cache na každý vytvářející job udržuje tyto důkazy spolehlivé, spolu s egress policy nastavenou na default: deny ve vytvářejícím jobu. Podrobnosti najdete v průvodci úplností cache a SBOM.

Jak zaznamenávání funguje, popisují SBOM z doby buildu, nebo si rezervujte demo a spusťte jeden ze svých workflow s cache na CRACI.

Cache GitHub Actions: časté dotazy

Jak dlouho GitHub uchovává cache Actions?

GitHub odstraňuje položky cache, ke kterým nikdo nepřistoupil déle než 7 dní. Když repozitář překročí svůj limit úložiště, ve výchozím stavu 10 GB, vyřazuje také cache podle posledního přístupu, od nejstarších.

Ukládá setup-node do cache node_modules?

Ne. Vstup cache akce actions/setup-node ukládá globální data balíčků správce balíčků pro npm, Yarn nebo pnpm, ne node_modules. Krok instalace stále proběhne, ale balíčky čte z obnovené cache, místo aby je stahoval.

Může pull request číst cache z hlavní větve?

Ano. Běh workflow může obnovit cache ze své vlastní větve a z výchozí větve a pull request může obnovit také cache ze své cílové větve. Cache vytvořené v pull requestu jsou vázané na jeho merge ref, takže je nelze zapsat do rozsahu výchozí větve.

Je bezpečné používat cache Actions ve workflow pro vydání?

Je to kompromis. Výzkum zveřejněný v roce 2024 ukázal, že kdokoli, kdo dokáže spustit kód ve workflow výchozí větve, může otrávit cache, které obnovují jiné workflow, včetně workflow pro vydání. Workflow, které publikují vydání nebo drží tajné klíče pro nasazení, jsou bezpečnější, když sestavují z čistého stavu nebo z cache, do kterých zapisují jen ony.

Změní obnovená cache moji SBOM?

Může. Balíčky obnovené z cache se instalují, aniž by byly staženy, takže záznam sestavený ze síťového provozu je přehlédne, pokud cache nesleduje. A sken lockfilu vám neřekne, zda cache obsahovala přesně tyto verze.