joycebrum
commented
1 year ago Hi! This issue has been idle for quite some time. Do you plan on considering these changes? If so just let me know and I'll be happy to submit a PR. Otherwise I will wait up to 2 more months to close the issue. Let me know if you rather keep it open as "not planned" for later. Thanks!
Hi I'm working on behalf of Google and the OpenSSF to help Open Source Projects to improve Supply-Chain Security by following some security practices checked by OpenSSF Scorecard.
Description
Github Workflows, when not specified, always have the most permissive permission: write-all.
This brings lots of possible vulnerabilities that can be exploit such as:
statuses- May allow an attacker to change the result of pre-submit checks and get a PR merged.checks- May allow an attacker to remove pre-submit checks and introduce a bug.security-events- May allow an attacker to read vulnerability reports before a patch is available. Should only be granted to recognized actions for uploading SARIF results.deployments- May allow an attacker to charge repo owner by triggering VM runs, and tiny chance an attacker can trigger a remote service with code they own if server accepts code/location variables unsanitized.contents- Allows an attacker to commit unreviewed code. Should only be granted to recognized packaging actions or commands.packages- Allows an attacker to publish packages. Should only be granted to recognized packaging actions or commands.actions- May allow an attacker to steal GitHub secrets by approving to run an action that needs approval.See some additional content about this issue at:
Use credentials that are minimally scopedat GitHub Security GuidesSolution
To solve this vulnerability one approach is always set top level permission as read only and grant any write permissions needed on the run level.
If it is ok for you, I can suggest the PR with the changes described above.