Automatically create PRs with security enhancements

[trueberryless]

I recently stumbled upon this awesome security improvement project and after running the GH action I wondered where I can now find the output.

After finding it in the Security sector, I thought that this made total sense, but at the same time I wondered if it would be possible that simple fixes, like scoping permissions to jobs instead of the whole workflow would be possible automatically by creating PRs to the repo.

I am aware that this is a huge process and also kinda a visionary decision of the project. My vision would be a similar tool like Renovate, but for managing security on GH actions specifically instead of dependency management.

Feel free to share useful thoughts or just use emoji reactions for disagreement or agreement 🤝

[woodruffw]

Hi @trueberryless, thanks for opening an issue!

This is something I'm interested in, but you're right that it's a pretty big task 🙂 -- there are a couple of interlocking considerations here that I think would need to be addressed (or at least thought through and deemed acceptable) before extending this action to allow for PR generation as well:

• Creating PRs requires that this action be granted additional permissions, which means (1) more sources of user error/support load when users don't configure the permissions correctly, and (2) a larger security footprint for the action itself (i.e. the action itself becomes a juicy target, whereas currently it only needs read permissions). Neither of these is a hard blocker, but I'm curious to hear ideas about how to make this minimally confusing to users (e.g. ensuring they know that they don't need to grant write permissions unless they're enabling the PR functionality).
• On the zizmor side itself: zizmor can create auto-fixes for a few of its audits, and it would be pretty easy (IMO) to hook this up so that an action creates PRs from it. However, I'm not 100% sure this is a good idea at the moment: most of the current auto-fixes are "unsafe" in the sense that they can't be proven to maintain the original intended semantics. This is OK for local use since we expect users to manually triage the auto-fixes, but with automatic PR submission I'd imagine a lot of users feeling tempted to just merge zizmor's suggestions without looking at them closely. This in turn would (I suspect) lead to a lot of user anger/confusion when zizmor inevitably breaks some of their workflows/actions. This could maybe be mitigated by only including "safe" auto-fixes by default, although these are currently a much smaller subset of all available fixes.

TL;DR I'm concerned about introducing more sources of user error + making it too easy for people to automatically break their workflows/actions through zizmor's autofixes. But perhaps I'm being too conservative in those concerns; I would be curious to hear what you and others think.

[trueberryless]

Awesome, perfectly valid reasoning! Thank you very much for not only considering but also encouraging such a feature.

📨 I completely agree that the PRs would have to be safe, otherwise users would probably quickly revert the wonderful addition of this action.

🎖️ And yes, I also think that this action itself needs to be a role model and should therefore not need write permissions if the user chooses not to opt-on for the PR creation.

💡 One idea could be to provide two example setups, one with PR creation, the other just as it currently is. But I think time will tell how such an integration could be developed and optimally and safely communicated to the user.

[woodruffw]

(Note: I'm going to convert this into a discussion topic, since it has a pretty large design space that I think would benefit from larger community feedback.)