ci: update Testing workflow with harden-runner recommendations #4114
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit updates the Testing workflow (testing.yml) using recommendations from Step Security's harden-runner action. Recommendations were taken from the most recent Testing workflow run (6232, see links below) where all jobs ran with only the 'Get Yesterday's cached database if today's is not available' step not running on relevant jobs. As harden-runner only runs on Ubuntu VMs, a job-level permission was added to the 'Windows long test' job to account for the removal of the top-level workflow permission. As the Build job has only recently been added, the `egress-policy` key has been left with the value `audit`. The harden-runner recommendations suggest changing the value to `block` after 10+ runs of the job. Reference issue intel#4111 Testing workflow run 6232: https://github.com/intel/cve-bin-tool/actions/runs/8976788790/job/24654326627 harden-runner recommendations: https://app.stepsecurity.io/github/intel/cve-bin-tool/actions/runs/ 8976788790?jobid=24654326273&tab=recommendations
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4114 +/- ##
==========================================
+ Coverage 75.41% 81.36% +5.94%
==========================================
Files 808 820 +12
Lines 11983 12533 +550
Branches 1598 1941 +343
==========================================
+ Hits 9037 10197 +1160
+ Misses 2593 1908 -685
- Partials 353 428 +75
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
As the 'Build wheel (3.12)' job requires write permissions in the 'id-token' and 'attestations' scopes I'm assuming that the job should fail as the workflow was run from my pull request branch (thereby setting all permissions to a maximum of 'read'. Permissions for the previous test run and the current test run can be seen below. 
|
terriko
approved these changes
May 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the Testing workflow (testing.yml) using recommendations from Step Security's harden-runner action. Recommendations were taken from the most recent Testing workflow run (6232, see links below) where all jobs ran with only the 'Get Yesterday's cached database if today's is not available' step not running on relevant jobs.
As harden-runner only runs on Ubuntu VMs, a job-level permission was added to the 'Windows long test' job to account for the removal of the top-level workflow permission.
As the Build job has only recently been added, the
egress-policykey has been left with the valueaudit. The harden-runner recommendations suggest changing the value toblockafter 10+ runs of the job.@terriko your input on the following would be appreciated:
I believe the permissions are set correctly for each job. I followed the harden-runner recommendations and checked the actions and commands within each job to the best of my knowledge. Are we ok to track the logs to see if the permissions are too restrictive and amend from there or would you prefer another approach?From the test logs it seems the workflow is used from my pull request branch.Reference issue #4111
Testing workflow run 6232: https://github.com/intel/cve-bin-tool/actions/runs/8976788790/job/24654326627
harden-runner recommendations: https://app.stepsecurity.io/github/intel/cve-bin-tool/actions/runs/8976788790?jobid=24654326273&tab=recommendations