[MAJC-130] Restrict permissions for github actions workflows

[mashalifshin]

References

MAJC-130

Problem Statement

Address CodeQL scan results results that noticed we have unrestricted workflow permissions.

Proposed Changes

"Practice the Principle of Least Privilege" and give the github action's token the least possible permissions in the repo when running actions. It's also recommended generally in the guide to hardening Github actions, and we got 0/10 on this metric from the OSSF scorecard.

Verification Steps

• Take a look at the diff and actions runs and make sure everything looks good there

[cyptm]

@mashalifshin I'm not clear how the read permissions we've added are "restricting" permissions.

  contents: read
  pull-requests: write

Were the permissions by default "write permissions" or what am I missing?

[mashalifshin]

@mashalifshin I'm not clear how the read permissions we've added are "restricting" permissions.

  contents: read
  pull-requests: write

Were the permissions by default "write permissions" or what am I missing?

Thank you for the speedy reviews @cyptm! 🙌

Great question! So this was flagged by an automated code scanning tool, CodeQL, and if you go to this link and click on "Show More" it will give a really good explanation, but TLDR is that if you don't specify this on jobs/workflows, then permissions are inherited from the repo, and if repo doesn't have them, then permissions come from the org. And until about 2 years ago, orgs were created with default read-write permissions ... so here we are. :-)

More great details about why this matters and how it can be a security risk from the security audit tool OSSF

[cyptm]

@mashalifshin I'm not clear how the read permissions we've added are "restricting" permissions.

  contents: read
  pull-requests: write

Were the permissions by default "write permissions" or what am I missing?

Thank you for the speedy reviews @cyptm! 🙌

Great question! So this was flagged by an automated code scanning tool, CodeQL, and if you go to this link and click on "Show More" it will give a really good explanation, but TLDR is that if you don't specify this on jobs/workflows, then permissions are inherited from the repo, and if repo doesn't have them, then permissions come from the org. And until about 2 years ago, orgs were created with default read-write permissions ... so here we are. :-)

More great details about why this matters and how it can be a security risk from the security audit tool OSSF

Makes total sense, thanks for the clarification @mashalifshin