July 8, 2026

StevenBlack and UT1 blocklists in the enterprise: provenance, cadence, and safe operations

Most enterprise filtering stacks lean on two community-maintained lists: StevenBlack hosts and the Université Toulouse Capitole (UT1) categorized lists. Both are publicly maintained and widely cited, but they behave very differently. StevenBlack is a unified hosts file; UT1 is granular by category. Using either safely at scale comes down to provenance, refresh cadence, and whether what you run is provably what the maintainers published.

StevenBlack: one curated hosts file

StevenBlack hosts is a publicly maintained project on GitHub that aggregates several sources into a single hosts file, with optional extra variants for gambling, social, or adult content. It is simple to consume — entries map domains to a sinkhole address — but it is flat: a domain is either listed or it is not, with no category attached. That makes it strong for broad blocking of ads, trackers, and known-bad hosts, but weak when an auditor asks which policy category a given block falls under. Link provenance back to the repository commit so you can show exactly which version you are running.

UT1: category granularity

The UT1 lists, maintained at Université Toulouse Capitole, sort domains into named categories. That granularity is what lets you phase a rollout — block malware and phishing first, defer social or streaming — and lets a block event carry a category label that maps to your acceptable-use policy. The trade-off is volume and curation effort: category lists need review, and some categories over-block shared infrastructure such as CDNs. Run them per policy group rather than fleet-wide on day one, and keep an exception workflow ready.

Provenance and cadence matter more than size

A list is only as trustworthy as its update path. Pulling raw hosts over plain HTTPS on every query ties enforcement to network availability and gives you no integrity guarantee against a tampered or truncated fetch. Prefer a distribution that signs the bundle and verifies it on the agent before applying, then retains the last good copy on disk. ed25519-signed bundles do this cheaply: the agent verifies the signature, applies the update, and keeps blocking when the next fetch fails. Whatever cadence you choose, record it and the maximum staleness your risk appetite accepts in the risk register.

Version tracking is the other half of provenance. Pin the commit or release you are running and surface it in block events and in your monthly attestation. When a domain owner disputes a block, the first question is which list version said what — an answer that points to a specific StevenBlack commit or a dated UT1 category file ends the debate, where "the current list" starts one. Treat list versions as configuration items: reviewable, exportable, and retained for as long as your audit window requires.

There is a separation-of-duties angle here too. Whoever curates a list is not the party that signs and ships it, and neither is the party that sets your category policy. Keep those boundaries visible in your documentation so a reviewer can trace a block from the end user back through your policy, through the signed bundle, to the upstream maintainer — without any step relying on trust in a single team or vendor. That traceability is what turns a community list into something defensible in an enterprise risk register.

Combine with real-time threat feeds

Neither StevenBlack nor UT1 is a real-time threat feed. Layer URLhaus, OpenPhish, and PhishTank on top for active phishing and malware infrastructure that category lists lag behind. Each feed has its own scope and update rhythm; treat them as complementary, not redundant, and tag every block event with its source feed so false-positive review routes to the right maintainer. Our write-up on signed offline bundles covers how that layering holds up during an outage.

ClearScreen ships StevenBlack and UT1 alongside URLhaus, OpenPhish, and PhishTank in signed bundles verified on the endpoint, with block events tagged by category and feed. See the feature overview for how lists and feeds map to your policy groups.