Most scanner-defence advice ends at blocking. The layer we would not give up is the last one: writing down what happened, with definitions, where anyone can read it.

Closing the loop means publishing what you measure, so the numbers can be checked.

What this layer is

  • Publish the counts and the definitions together, so a number cannot be read as something it is not.
  • Freeze dated records - a daily digest and a weekly report - so the history cannot quietly change after the fact.
  • Publish a machine-readable health file, so a reader can tell whether the data is current before trusting it.
  • Feed findings back: a path family that appears in the log becomes a rule in the layers above.

What our own loop looks like

Requests, refusals, crawler counts and scan-path counts are aggregated every five minutes from our own access log; the daily digest and the weekly report are frozen once published, with the definitions attached. In our own window: 71,191 requests, of which 40,263 were refused and 33,133 matched known scan paths; the top five probe paths were /v1/graphql (857), /api/graphql (845), /graphql (831), /api/config (814) and /actuator/loggers (533).

Where we disagree with the textbook

The usual closing step is to add captured addresses to a blocklist. We keep the loop open at the path level instead, for the reason covered in part three: our crawler and scanner traffic share address ranges. A list of blocked addresses would be a list we could not safely act on; a list of refused paths is one we can.

How to verify

Sources: our own log pipeline and published data files; RFC 9309 for the policy layer this reporting sits beside (rfc-editor.org).

Why publish refusal numbers at all?

Because they are otherwise unfalsifiable marketing. A reader who can see the definitions can also see when a claim does not hold.

What stops you from editing a report later?

Nothing technical - so we freeze dated pages once published and treat a change as a correction, dated and visible.

Is publishing scan counts a security risk?

It reveals volumes, not weaknesses. We keep addresses masked and never publish a rule we would not want tried.

Related reading: Five Layers of Scanner Defence, Tested on Our Own Site · Layer 4: Honeypots as Early Warning (and Their Limits)

More on this site: live signals · dated reports · how to verify us