A CI/CD cache reduces repeated work, but a cache hit establishes a lookup match, not that restored files are trustworthy release inputs. Review its writers and consumers alongside the key. This is technical guidance, not a delivered XIVTech project or a measured performance result.
Identify what the job restores
Distinguish a package-manager download cache from an installed dependency tree, executable output or release artifact. List the restored paths and whether they influence code that the job executes. A cache that supplies executable inputs needs a different trust review from disposable downloads.
Record each consumer's trigger, source revision, permissions and branch or repository scope. The CI provider determines actual access rules. A branch name alone does not establish that lower-trust code cannot influence a privileged job.
Establish who can write the entry
For each save operation, identify which code ran before the cache was written and whose input it processed. Review the boundary before a later job restores that content and receives deployment credentials. Keep tokens, credentials and sensitive configuration out of cached paths; log redaction does not make stored files private.
Make restore fallbacks intentional
A key may include a lockfile and relevant runtime or platform inputs. Broader fallback keys improve reuse but can restore older content. Document why that content is acceptable and which later step reconciles it with the current dependency definition. A matching key is not a signature of the restored bytes.
Use a bounded clean-build check
When investigating an unexplained dependency difference, compare a cache-hit run with a controlled cache-miss run. Keep the source revision, lockfile, runtime and relevant configuration comparable. Record changed inputs rather than attributing every failure to caching. A clean build removes retained state but may still retrieve an unsafe dependency or run an unsafe workflow.