CI cache security: treat restored data as an input, not trusted code
Review cache writers and readers, keep secrets out and prevent a lower-trust job from supplying executable content to a privileged release.
In brief
Google’s CI/CD hardening report identifies cache poisoning as a supply-chain risk. A cache can speed up builds, but restoration does not certify who produced its contents or whether privileged execution should trust them.
The relevant check is whether a lower-trust source can influence a cache later consumed with more authority.
Map who influences the cache
Inspect events, branches, fork behaviour and runner permissions through the platform’s current documentation. An ordinary test and a release job may have different authority. Do not make an assumption about isolation based only on a human-readable cache name.
Keep secrets and critical outputs separate
Do not store credential files, private environment dumps or a trusted release artifact in a broadly accessible dependency cache. Treat dependency restoration as part of a controlled install/build process rather than directly executing unexplained cached programs.
Review a suspected poisoned state
Pause the affected release path, preserve relevant workflow records and invalidate/rebuild the suspect cache through supported controls. Investigate what ran and which credentials it could access. Clearing the cache alone does not revoke any secret already exposed.
Before you act
Cache scope and behaviour depend on the CI platform. A random key or a checksum based only on untrusted input is not automatically a security boundary.
What to do next
- Identify jobs that write and restore each cache and their trust levels.
- Exclude credentials and sensitive files and review executable restored content.
- Separate privileged release inputs from untrusted jobs and verify the intended dependency state.
