¿Necesito una cuenta de OpenWAF?
No. La acción funciona entera en el runner y guarda su informe en la ejecución. Solo hace falta cuenta para enviar los eventos a OpenWAF.
¿La acción envía mis datos a algún sitio?
No por defecto. Lee de api.github.com/meta la lista de endpoints de Actions de GitHub y nada más sale por su causa. Con send-events: on envía a tu organización de OpenWAF el nombre, el puerto, la decisión, el motivo, los ids de detección y los contadores de cada destino; nunca cuerpos, cabeceras ni URLs.
¿Qué runners admite?
Linux en x64 y arm64: los runners Ubuntu de GitHub y los runners self-hosted donde el usuario del job tiene sudo sin contraseña o acceso a Docker. Ver runners self-hosted. Los runners macOS y Windows no están soportados.
¿Funciona con pull requests de forks?
Sí, la política se les aplica como a cualquier otra ejecución. send-events no, porque GitHub no da id-token: write a las pull requests de forks; el resumen lo dice y el job sigue.
¿Siguen funcionando la caché y los artefactos de Actions?
Sí, con el preset github-actions, que lista las cuentas de almacenamiento de GitHub por nombre exacto. Con el bloqueo activo, la acción pone .blob.core.windows.net en NO_PROXY para que el cliente de la caché no abra un túnel de proxy por fragmento; esas conexiones pasan igualmente por el proxy transparente y solo llegan a las cuentas de GitHub.
Mi herramienta ignora HTTPS_PROXY. ¿Está cubierta?
Sí, con el bloqueo activo: sus conexiones TCP van al proxy transparente, que les pone nombre por el SNI de TLS o el Host de HTTP, y su DNS al forwarder. Sin root (sin bloqueo), solo se cubren las herramientas que usan el proxy.
¿Se cubren docker build y docker compose?
Sí, con containers: track (el valor por defecto). docker build se ejecuta en un builder que es uno de los contenedores del job, y las redes de Compose entran en el bloqueo al crearse. Ver Docker y builds.
¿Puedo permitir un dominio entero?
Sí: *.example.com permite cualquier nombre por debajo de example.com (añade también example.com si lo necesitas). Mejor nombres exactos: el resumen te los da.
¿Por qué no se detecta un secreto enviado por HTTPS?
Los proxies ven el nombre de un destino HTTPS, no su contenido. El contenido se revisa en el HTTP en claro y en los hosts de inspect. Ver Inspección y DLP.
¿En qué se diferencia de StepSecurity Harden-Runner?
Las dos son GitHub Actions que vigilan el tráfico de salida de un job y pueden limitarlo a una lista de permitidos, con un modo de auditoría y otro de bloqueo. Algunas diferencias, según la documentación de Harden-Runner (enlace externo):
| OpenWAF Egress CI | StepSecurity Harden-Runner | |
|---|---|---|
| Dónde van los resultados | El resumen del job y el log de la ejecución; opcionalmente tu organización de OpenWAF | La página de insights y la consola de StepSecurity |
| Sistemas operativos del runner | Linux | Linux, macOS y Windows |
| Runners self-hosted | La misma acción en el workflow, con sudo o Docker | Un agente en la imagen del runner o un servicio; un DaemonSet para Actions Runner Controller |
| Más allá de la red | Secretos en HTTP en claro y en peticiones inspeccionadas (DLP), atribución por contenedor con el socket de Docker del job | Vigilancia de procesos y de escrituras de ficheros, detección de sobrescritura del código fuente, una lista de bloqueo global que mantiene StepSecurity |
| Licencia y planes | Apache 2.0; sin cuenta | Ver los planes de StepSecurity: el Community Tier cubre los repositorios públicos |
Elige según lo que necesites: Harden-Runner cubre más del runner (procesos, ficheros, más sistemas operativos) con el servicio de StepSecurity; Egress CI guarda su informe en la ejecución y añade DLP y política por contenedor en runners Linux.
¿Está lista para producción?
Es una beta en acceso anticipado. Empieza en audit, lee los límites y escribe a support@openwaf.dev con lo que encuentres.