Edge WAF: A New Front Door
tl;dr: Traffic now has a real front door — an edge firewall with OWASP rulesets and per-IP rate limiting, tuned so your pull request text doesn't trip it.
Until now, requests went from the open internet straight to our application servers. No filtering layer, no documented firewall policy, nothing between a scanner and the door. That's changed: every environment now sits behind a global load balancer carrying a dedicated security policy — seven OWASP Core Rule Set rulesets, per-IP rate limiting, a TLS 1.2 floor, IPv4 and IPv6, and an automatic redirect from HTTP to HTTPS.
The internal control-plane schema — the document that enumerates every internal route and webhook handler — is now blocked outright. The public API docs are untouched, deliberately: the deny rule matches one exact path and never a prefix, precisely so integrators building against our API don't get caught in the blast radius. That distinction was the difference between a security control and an outage.
Then staging found the interesting problem. A perfectly legitimate GitHub webhook — carrying pull request text — matched a SQL-injection signature and got flagged. Which makes sense the moment you say it out loud: people paste SQL, shell and scripts into pull requests constantly, and content-inspection rules can't tell the difference between a threat and a Tuesday. Left alone, that would have produced intermittent, unexplained gaps in PR ingestion, the kind of bug that gets misdiagnosed for weeks.
So the content-inspecting rulesets now skip two paths: webhook delivery and agent chat queries. Both accept arbitrary user-authored text by design — that's their job. Neither loses meaningful protection: webhooks already verify an HMAC signature before anything is processed, so a payload can't land there without the signing secret, and scanner-detection and protocol-attack rules still apply everywhere, including those paths. No ruleset was disabled; five of them got narrower on two routes.
The practical upshot: opportunistic scanners and bot floods get filtered at the edge, our compliance posture has an actual documented policy behind it, and your webhooks keep flowing while it all happens. Rules are running in preview mode first — logged, not blocked — so anything unexpected shows up in a dashboard instead of a support ticket.
Nothing to configure on your end. The firewall is running in log-only mode while we watch the traffic, and enforcement follows once the logs are boring.