Do I need an OpenWAF account?
No. The action runs entirely on the runner and keeps its report in the run. An account is only needed to send events to OpenWAF.
Does the action send my data anywhere?
Not by default. It reads GitHub's list of Actions endpoints from api.github.com/meta and nothing else leaves because of it. With send-events: on it sends each destination's name, port, decision, reason, detection ids and counts to your OpenWAF organization; never bodies, headers or URLs.
Which runners does it support?
Linux on x64 and arm64: GitHub-hosted Ubuntu runners, and self-hosted runners where the job's user has passwordless sudo or access to Docker. See self-hosted runners. macOS and Windows runners are not supported.
Does it work with pull requests from forks?
Yes, the policy applies to them like to any other run. send-events does not, because GitHub does not give fork pull requests id-token: write; the summary says so and the job goes on.
Will the Actions cache and artifacts still work?
Yes, with the github-actions preset. It lists GitHub's storage accounts by exact name. With the lock on, the action puts .blob.core.windows.net in NO_PROXY so the cache client does not open one proxy tunnel per chunk; those connections still go through the transparent proxy and only reach GitHub's accounts.
My tool ignores HTTPS_PROXY. Is it covered?
Yes, when the lock is on: its TCP connections go to the transparent proxy, which names them by TLS SNI or HTTP Host, and its DNS to the forwarder. Without root (no lock), only proxy-aware tools are covered.
Are docker build and docker compose covered?
Yes, with containers: track (the default). docker build runs in a job builder that is one of the job's containers, and Compose networks enter the lock when they are created. See Docker and builds.
Can I allow a whole domain?
Yes: *.example.com allows every name below example.com (add example.com too if you need it). Prefer exact names: the summary lists them for you.
Why is a secret sent over HTTPS not detected?
The proxies see the name of an HTTPS destination, not its content. Content is scanned for plain HTTP and for the hosts under inspect. See Inspection and DLP.
How does it compare with StepSecurity Harden-Runner?
Both are GitHub Actions that monitor a job's outbound traffic and can restrict it to an allowlist, in an audit and a blocking mode. Some differences, from Harden-Runner's documentation (external link):
| OpenWAF Egress CI | StepSecurity Harden-Runner | |
|---|---|---|
| Where results go | The job summary and the run's log; optionally your OpenWAF organization | StepSecurity's insights page and console |
| Runner operating systems | Linux | Linux, macOS and Windows |
| Self-hosted runners | The same action in the workflow, with sudo or Docker | An agent in the runner image or a service; a DaemonSet for Actions Runner Controller |
| Beyond the network | Secrets in plain HTTP and inspected requests (DLP), per-container attribution through the job's Docker socket | Process and file-write monitoring, source code overwrite detection, a global block list maintained by StepSecurity |
| Licence and plans | Apache 2.0; no account needed | See StepSecurity's plans: the Community Tier covers public repositories |
Pick by what you need: Harden-Runner covers more of the runner (processes, files, more operating systems) with StepSecurity's service; Egress CI keeps its report in the run and adds DLP and per-container policy on Linux runners.
Is it ready for production?
It is an early-access beta. Start in audit, read the limits, and write to support@openwaf.dev with what you find.