Open varunsh-coder opened 2 years ago
Adding list of PRs:
1-10
11-20
21-30
31-40
41 - 50
51 - 60
61 - 70
71 - 80
81 - 90
91 - 100
101 - 110
111- 120
Closed PRs
This is a helpful prompt but I think you should instead be recommending enabling restrictive permissions by default for the entire organisation rather than adding these lines to every repo workflow file. I feel this is more secure and better practice.
With the more restrictive permissions, the token only has access to read contents
and metadata
.
Stop spamming repositories. Ask before running automated tools. https://twitter.com/di_codes/status/1567559370078052353, https://twitter.com/jacobian/status/1570188260592463872
Also agree with the comment above, push for better defaults, not changes to every single workflow file.
Thanks @davidism for the feedback. We have been working with maintainers of critical open-source projects since April (the first PR on this issue) to address security issues related to elevated GitHub token permissions. Our fix acceptance rate is quite high as you can see from the list of PRs above and many critical open-source projects have benefited from these fixes. We had not heard of this concern before. Going forward, would it be better if we create an issue first to discuss such security remediations with project maintainers?
What you're doing is not "working with maintainers", it's "spamming maintainers then hoping they go along with it so we can point at the acceptance rate." Yes, you should ask first, in a non-spammy, non-automated way, if maintainers want to participate in your automated PRs. You don't even need to make PRs, just use your team to open issues discussing the concern, as any non-company open source user would.
Your PRs aren't really fixing anything long term, as soon as maintainers create a new workflow they'll have the same permission issue. You should be telling them to enable better defaults, then opt in to more permissions, so they don't need the PRs in the first place.
This is a good idea. The problem is that if workflows that need write access are not fixed by adding explicit permissions, and this change it made at the repo/org level, those workflows will not work as intended.
We can clarify this as part of future issues/ PRs - to first add explicit permissions to workflows that need write access, and after that turn on the setting at the repo/org level, so future workflows are secure by default.
Otherwise, one might follow the recommendation to only turn this on at the repo/ org level, and it might break some of the workflows
This is a helpful prompt but I think you should instead be recommending enabling restrictive permissions by default for the entire organisation rather than adding these lines to every repo workflow file. I feel this is more secure and better practice.
With the more restrictive permissions, the token only has access to read
contents
andmetadata
.
This issue is to track progress on adding GitHub token permissions to workflows for critical open source projects.
OSSF has a working group to identify critical projects and calculate criticality score: https://github.com/ossf/wg-securing-critical-projects
The list of top 100 projects is here: https://docs.google.com/spreadsheets/d/1ONZ4qeMq8xmeCHX03lIgIYE4MEXVfVL6oj05lbuXTDM/edit#gid=1024997528