# Egress CI FAQ

> Common questions about OpenWAF Egress CI: accounts, data, runners, Docker, caching, and how it compares with StepSecurity Harden-Runner.

**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](https://developers.openwaf.dev/egress/ci/send-events/).


**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](https://developers.openwaf.dev/egress/ci/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](https://developers.openwaf.dev/egress/ci/docker/).


**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](https://developers.openwaf.dev/egress/ci/inspect-and-dlp/#the-tls-trade-off).


**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](https://docs.stepsecurity.io/github-actions/harden-runner):

| | 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](https://developers.openwaf.dev/egress/ci/limits/), and write to support@openwaf.dev with what you find.