Fix token permissions for 100 critical open-source projects

varunsh-coder commented 2 years ago

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

varunsh-coder commented 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

danielroe commented 1 year ago

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.

See https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization.

CleanShot 2022-10-03 at 10 15 21

With the more restrictive permissions, the token only has access to read contents and metadata.

davidism commented 1 year ago

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.

ashishkurmi commented 1 year ago

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?

davidism commented 1 year ago

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.

davidism commented 1 year ago

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.

ashishkurmi commented 1 year ago

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.

See https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization.

With the more restrictive permissions, the token only has access to read contents and metadata.

step-security / secure-repo

Fix token permissions for 100 critical open-source projects #462