All work

Security & Response

The Edge Guardian

Every Cloudflare zone is checked against one security baseline every 30 minutes, and a new zone gets the safe settings without anyone remembering to apply them.

Designed, built, and operateBashCloudflare APIOpenBaoPrometheussystemd timersOpenSSL
  • 38 zones across more than one Cloudflare account, all at the baseline today: TLS 1.2 minimum, HTTPS forced, TLS 1.3 on.
  • A zone counts as fixed only when Cloudflare reads the new setting back. A write the API refuses is reported as refused, with the permission it needs.
  • The baseline check has an offline self-test with six cases, run without touching Cloudflare.

The problem

A new site goes live in an afternoon, and its DNS zone starts with Cloudflare's defaults. From the outside, a zone that allows TLS 1.0 and has no web application firewall looks exactly like a protected one.

A checklist only works on the days someone runs it. So the baseline is a property the guardian asserts on every zone, every half hour, and fixes when it can.

What the baseline is, and what it won't touch

Three settings: minimum TLS version 1.2 or 1.3, always-use-HTTPS on, and TLS 1.3 on. The guardian reads all three on every active zone. If any is wrong it writes the fix, then reads the values again and believes those, not the write. It also deploys Cloudflare's free managed WAF ruleset to any zone without it, keeping whatever rules the zone already has.

It only auto-applies settings that can't break a working site. The SSL mode is reported and never changed, because strict mode can take a site down. Proxy status on sensitive hostnames is alerted on and never flipped, since that can break the origin's certificate renewal. No blocking rules are applied on their own.

Fixes that never happened

The guardian used to send its fixes and throw the response away.

[2026-08-24 01:41:36] ALERT zone <zone>: baseline write did NOT take (still min_tls=1.0 always_https=off) ... the CF token for this zone can read settings but not edit them. Grant Zone Settings:Edit.
[2026-09-10 03:17:16] AUTO-PROTECTED zone <zone> -> baseline applied and VERIFIED (min_tls=1.2 always_https=on)
Two lines from the guardian's log for the same zone, before and after the token change. The zone name is replaced and the first line is cut where it says ...

Five zones the guardian said it had fixed

Five zones lived in a second Cloudflare account. The token for that account could read zone settings but not change them.

  1. Through Aug 23The guardian sent the fix, discarded Cloudflare's refusal, and logged "baseline applied" about 40 times per zone while all five sat at TLS 1.0 with no HTTPS redirect.
  2. Aug 24The write became a write-then-read. The next run saw nothing had changed and said the token could read settings but not edit them.
  3. AfterA zone the guardian can't fix now gets its own metric, separate from one it hasn't fixed, and the alert names the missing permission.
  4. Sep 10A token proven writable on both settings replaced the read-only one. The guardian applied and verified the baseline on all five zones within 13 seconds.

Seventeen days passed between finding the problem and getting the permission, and the guardian reported the zones as below baseline for all of them instead of claiming a fix. A zone counts as protected only when Cloudflare's own answer says so.

TLS 1.3 joined after a miss

The baseline used to be two settings. On October 16 a vulnerability assessment found that the most sensitive zone we run was the only one with TLS 1.3 off. The guardian had reported it protected the whole time, because it never read that setting.

So TLS 1.3 went into the baseline, defined in one function, and the function got an offline self-test. Another job counts its PASS and FAIL lines, so a script gutted to an empty success exit reads as broken.

PASS  min_tls=1.2  always_https=on   tls_1_3=on    -> pass
PASS  min_tls=1.3  always_https=on   tls_1_3=zrt   -> pass
PASS  min_tls=1.2  always_https=on   tls_1_3=off   -> FLAG
PASS  min_tls=1.2  always_https=on   tls_1_3=null  -> FLAG
PASS  min_tls=1.0  always_https=on   tls_1_3=on    -> FLAG
PASS  min_tls=1.2  always_https=off  tls_1_3=on    -> FLAG
guardian zone-baseline selftest: 6 passed, 0 FAILED
The self-test output. The last four cases are zones the guardian must flag.

Is it looking at everything?

None of the checks above answers "is this zone being checked at all." A zone in an account the token can't see isn't an error: the API returns success with zero rows. One zone sat like that, with no audit, no WAF and no alert.

Now the guardian loads every Cloudflare token it holds, audits each zone with the token that can manage it, and checks the result against a list of zones it must audit. An accepted shortfall goes in a register with a reason and a review date, and the date is checked too, so an exception can't become permanent by being forgotten.

The WAF, and names we don't proxy

A sweep of 31 zones in August found two with no managed WAF: one serving live traffic, one about to. The guardian now deploys the ruleset on every run, a daily sweep checks again, and a zone where the deploy fails reads zero until someone fixes it.

Some sites are hosted on a site-builder's own Cloudflare edge, where our zone settings never apply. An hourly probe checks a rotating sample of those names: TLS 1.0 must be refused and plain HTTP must redirect.

What it doesn't do

The managed WAF is a baseline, not full application-layer protection. File integrity monitoring on the origin covers what it misses.

Logins to the admin surfaces reach the SIEM within a minute. Configuration-change auditing at the edge is a known gap, stated on the security page, and the guardian works the same way: when a check fails or can't run, it reports the gap instead of a green.

Engineering decisions

The calls I made, and what each one cost.

Believe the read-back, never the write.

It costs three extra API calls per fixed zone. The alternative was 17 days of a tool reporting fixes that never happened.

Auto-apply only what can't break a site, and report the rest.

SSL mode and proxy status are the settings most likely to be wrong, and also the ones most likely to cause an outage if flipped blind. I accept that a person makes those changes, and the guardian makes sure they know about it.

Separate "we didn't fix it" from "we can't fix it."

An alert that fires on every run with no action possible teaches people to scroll past it. One that names the missing permission gets acted on.

More systems

I'm looking for Incident Commander, SRE and AIOps roles.

If your team is drowning in toil, alert noise, or incidents that never quite close. That is the work I do.

Get in touch