harden-runner VS runner-images

Fortunately there is a great free online tool that help you by doing all the hard work (it will open a pull-request and automatically fix issues).

If using GitHub Actions for CI/ CD, Harden Runner (https://github.com/step-security/harden-runner) can be used to audit and block DNS exfiltration. Outbound calls from CI are predictable (to source repo, artifact registry, etc.) and don't change often.

As part of writing tests for Harden Runner GitHub Action, which prevents such attacks, there was a need to write attack simulator for these attacks.

I am not too familiar with GitLab, to be honest, but: - Commit/PR linting (to be in tandem with semantic versioning) is implemented via third-party GitHub Actions (https://github.com/amannn/action-semantic-pull-request and https://github.com/wagoid/commitlint-github-action), these might be hard to transfer - Blocking egress to mitigate supply chain attacks is performed by step security’s Harden Runner (https://github.com/step-security/harden-runner), you may raise a question there about GitLab support - CodeQL support is GitHub only AFAIK (but you would have to verify it)

I've found StepSecurity's tooling helpful in getting my repos secured.

* https://app.stepsecurity.io/securerepo

I agree. There are projects such as https://github.com/ossf/package-analysis and https://github.com/step-security/harden-runner that do behavior analysis. Disclaimer: I’m maintainer of the second one.

So if you are concerned about this, I'd suggest looking at the following:

* OpenSSF Scorecard Action - https://github.com/ossf/scorecard#scorecards-github-action

* Step Security Harden Action - https://github.com/step-security/harden-runner

I realize that this means trusting these providers but they seem at least tacitly blessed by GitHub. https://docs.github.com/en/actions/security-guides/security-...

Few hours back several malicious packages were released on npm registry. This video shows how some of these packages are making outbound calls as part of the preinstall step when executed in a GitHub Actions workflow. DNS Exfiltration and network calls detected by Harden-Runner GitHub Action https://github.com/step-security/harden-runner

Yeah this is a good option if you'd like something to deploy yourself! You can also build an AMI from GitHub's upstream image definition (https://github.com/actions/runner-images/tree/main/images/ub...) if you'd like it to match what's available in GitHub-hosted Actions.

With Depot, we're moving towards deeper performance optimizations and observability than vanilla GitHub runners - we've integrated the runners with a cache storage cluster for instance, and we're working on deeper integration with the compute platform that we built for distributed container image builds - as well as expanding the types of builds we can process beyond Actions and Docker, for instance.

But different options will be better for different folks, and the `philips-labs` project is good at what it does.

Whoa, there's a lot of stuff in there [1] that gets installed straight from vendors, without pinning content checksums to a value known-good to Github.

I get it, they want to have the latest versions instead of depending on how long Ubuntu (or, worse, Debian) package maintainers take to package stuff into their mainline repositories... but this attack surface is nuts.

[1] https://github.com/actions/runner-images/tree/main/images/ub...

I had a similar experience with ARC (actions-runner-controller).

One of the machines in the fleet failed to sync its clock via NTP. Once a job X got scheduled to it, the runner pod failed authentication due to incorrect clock time, and then the whole ARC system started to behave incorrectly: job X was stuck without runners, until another workflow job Y was created, and then X got run but Y became stuck. There were also other wierd behaviors like this so I eventually rebuilt everything based on VMs and stopped using ARC.

Using VMs also allowed me to support the use of the official runner images [0], which is good for compatibility.

I feel more people would benefit from managed "self-hosted" runners, so I started DimeRun [1] to provide cheaper GHA runners for people who don't have the time/willingness to troubleshoot low-level infra issues.

[0]: https://github.com/actions/runner-images

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631

Used https://github.com/actions/runner-images to get the packages needed for Ubuntu 22.04 As the packer requires a builder, I used "null" builder to set it as localhost ref: https://developer.hashicorp.com/packer/docs/builders/null (It was way difficult to figure it out the 1st time) I had to modify the .pkr.hcl file to pick my provisioners. I could not understand the use of /opt/hostedtoolcache folder (which I did later)