chore(ci): harden workflow permissions for security compliance #4898
Conversation
|
leandrodamascena
left a comment
There was a problem hiding this comment.
The trick now is to set global permissions to an empty dict? Super weird.
I think so (we'll need to merge to see if it works & solves the findings), but this is happening because we have two sets of SAST. As far as the OpenSSF Scorecard is concerned, having a top-level default read permission is enough to get a 10/10 score, this was the guidance we've been following for a while now. The new finding comes from SonarCloud that wants a per-job least principle configuration. With this empty top-level config I'm trying to please both - unsure if it'll work, I might have to revert the PR if the finding is not resolved, and in that case we might want to just dismiss them. |
Summary
Changes
Harden GitHub Actions workflow permissions to satisfy both OSSF Scorecard and SonarCloud security requirements. This addresses 6 open code scanning alerts related to token permissions.
Strategy applied:
permissions: {}at workflow level (disables all permissions by default)Files updated:
reusable-run-linting-check-and-unit-tests.yml- addedcontents: readto 5 jobsossf_scorecard.yml- addedcontents: readtoanalysisjobquality_check.yml- addedcontents: readto 5 jobspublish_layer.yml- addedcontents: readtobuild-layerjoblayers_partitions.yml- addedid-token: write, contents: readto deploy jobslayers_partitions_deploy.yml- added top-levelpermissions: {}Issue number: closes #4897
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.