How to harden GitHub Actions

These suggestions make a lot of sense.

At Namespace (namespace.so), we also take things one step further: GitHub jobs run under a cgroup with a subset of privileges by default.

Running a job with full capabilities, requires an explicit opt-in, you need to enable "privileged" mode.

Building a secure system requires many layers of protection, and we believe that the runtime should provide more of these layers out of the box (while managing the impact to the user experience).

(Disclaimer: I'm a founder at Namespace)

Timely article... I recently learned about self-hosted runners and set one up on a Hetzner instance. Pretty smooth experience overall. If your action contains any SSH commands and you'd like to avoid setting up a firewall with 5000+ rules[0], I would recommend self-hosting a runner to help secure your target server's SSH port.

[0] https://api.github.com/meta

Can't speak for everyone, but workflows can get pretty crazy in my personal experience.

For example the last place I worked had a mono repo that contained ~80 micro services spread across three separate languages. It also contained ~200 shared libraries used by different subsets of the services. Running the entire unit-test suite took about 1.5 hours. Running the integration tests for everything took about 8 hours and the burn-in behavioral QA tests took 3-4 days. Waiting for the entire test suite to run for every PR is untenable so you start adding complexity to trim down what gets run only to what is relevant to the changes.

A PR would run the unit tests only for the services that had changes included in it. Library changes would also trigger the unit tests in any of the services that depended on them. Some sets of unit tests still required services, some didn't. We used an in-house action that mapped the files changed to relevant sets of tests to run.

When we updated a software dependency, we had a separate in-house action that would locate all the services that use that dependency and attempt to set them attempt to set them to the same value, running the subsequent tests.

Dependency caching is a big one and frankly Github's built-in cacheing is so incredibly buggy and inconsistent it can't be relied on... So third party there. It keeps going on:

- Associating bug reports to recent changes

- Ensuring PRs and issues meet your compliance obligations around change management

- Ensuring changes touching specific lines of code have specific reviewers (CODEOWNERS is not always sufficiently granular)

- Running vulnerability scans

- Running a suite of different static and lint checkers

- Building, tagging, and uploading container artifacts for testing and review

- Building and publishing documentation and initial set of release notes for editing and review

- Notifying out to slack when new releases are available

- Validating certain kinds of changes are backported to supported versions

Special branches might trigger additional processes like running a set of upgrade and regression tests from previously deployed versions (especially if you're supporting long-term support releases).

That was a bit off the top of my head. Splitting that from a mono-repo doesn't simplify the problem unfortunately it just moves it.

your article inspired me https://github.com/seanwevans/Ghast still a WIP

Yep, and there's an opt-in to disable sudo which prevents circumvention. However this can break some actions especially ones deployed as Docker images. It also doesn't work with macos.