This is probably a naive question, but could this be mitigated by fencing a part of code by some “frequency fence” of some sorts? This is of course a long-term mitigation as it may require compiler support, may affect performance and other threads and whatnot, but I wonder what a proper solution would look like.
I'm curious whether this type of thing would work as well. It sounds like you're suggesting to be able to wrap sections of code in compiler-specific declarations (e.g., UNSAFE blocks in C#) that force the underlying hardware to operate at a constant frequency.
I have PRECISELY no idea whether that is coherent or makes sense. It's just interesting at a glance.
The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is:
1. An attacker had write access to the tj-actions/changed-files repo
2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate
3. Important: this spoofing of commits wasn't done to "trick" a maintainer into accepting any PR, instead it was just to obfuscate it a little. It was an orphan commit and not on top of main or any other branch
4. As you'd expect, the commit showed up as Unverified, although if we're being realistic, most people don't look at that or enforce signed commits only (the real bot signs its commits)
5. Kind of unrelated, but the "real" Renovate Bot - just like Dependabot presumably - then started proposing PRs to update the action, like it does any other outdated dependency
6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds
7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design