If that action is "./run_tests.sh", which is a top use case, the attacker just changes "./run_tests.sh", so while I agree that's useful, it doesn't secure the typical case, and makes for a hard cost/value stance.

The threat models are probably more like 1. "make sure only the right people run actions" and separately, 2. "make sure authorized events/actions only use the expected capabilities." Both largely fail today.

Well the idea is that a person submits a PR, and the action runs to verify that the tests pass BEFORE the PR is accepted. You don’t want to wait until after the code is merged in order to see if tests still pass.

The issue is that even if you don’t allow changes to the actual action workflow, running tests gives an attacker the ability to run arbitrary code. They just need to add the code they want to run to the tests (e.g. have the tests mine crypto)

That makes it really hard to debug actions, and ensure that they’re working prior to merging.