Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
varunsh-coder opened this issue Mar 17, 2022 · 7 comments
Open

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

varunsh-coder opened this issue Mar 17, 2022 · 7 comments

Comments

@varunsh-coder
Copy link
Member

varunsh-coder commented Mar 17, 2022 •
edited
Loading

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
Copy link
Member Author

varunsh-coder commented Apr 5, 2022 •
edited
Loading

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

@varunsh-coder varunsh-coder mentioned this issue Apr 27, 2022
Closed
@varunsh-coder varunsh-coder pinned this issue May 10, 2022
@varunsh-coder varunsh-coder mentioned this issue Aug 23, 2022
Merged
8 tasks
@ashishkurmi ashishkurmi changed the title Fix token permissions for 100 critical projects Fix token permissions for 100 critical open-source projects Sep 8, 2022
@danielroe
Copy link

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 davidism mentioned this issue Oct 3, 2022
Closed
@davidism
Copy link

davidism commented Oct 3, 2022 •
edited
Loading

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.

@davidism davidism mentioned this issue Oct 3, 2022
Closed
@ashishkurmi
Copy link
Member

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
Copy link

davidism commented Oct 3, 2022 •
edited
Loading

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
Copy link

davidism commented Oct 3, 2022 •
edited
Loading

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
Copy link
Member

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.

CleanShot 2022-10-03 at 10 15 21

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

@oliviertassinari oliviertassinari mentioned this issue Oct 5, 2022
Merged
@varunsh-coder varunsh-coder unpinned this issue Nov 1, 2022
@evverx evverx mentioned this issue Jun 17, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@davidism @varunsh-coder @danielroe @ashishkurmi