-
Notifications
You must be signed in to change notification settings - Fork 439
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.
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
ci: improve usage of harden-runner #4111
Labels
CI
Related to our continuous integration service (GitHub Actions)
Comments
terriko
added
the
CI
Related to our continuous integration service (GitHub Actions)
label
May 6, 2024
Hi @terriko I'd like to help out on this one. I'll put a pull request together for the |
michaelwknott
added a commit
to michaelwknott/cve-bin-tool
that referenced
this issue
May 7, 2024
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
terriko
pushed a commit
that referenced
this issue
May 10, 2024
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 #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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just watched this interesting video from the folk who make the harden-runner action we use:
https://www.youtube.com/watch?v=Yz72qAOrN9s
We're currently using harden-runner in audit mode, but I've had it enabled long enough that it should be possible to take their recommended policy and put it into action. For example, here's what they recommend for our test runners. You can see the fairly significant number of network addresses we contact in a normal test run!
Link to the full set of info for that run: https://app.stepsecurity.io/github/intel/cve-bin-tool/actions/runs/8971218459?jobid=24636478919&tab=recommendations (not sure if I'm the only one who can see this or if anyone can?)
Link to repo with the README file explaining stuff: https://github.com/step-security/harden-runner
We need to go through their recommendations for the various workflows and probably just make pull requests for each, then monitor to see if they cause any issues. The one above is probably the most complicated of the lot since it's a full test run but I haven't actually looked at them all yet myself.
Incidentally, our mirror is not showing up on the list above, which means we don't have any tests directly for it, and we should change that, so I'll file a separate issue for that.
The text was updated successfully, but these errors were encountered: