By Yair Knijn · May 14, 2025

The CISO who couldn't tell the board where the blocklist came from, or whether it had been tampered with

The CISO had a clean answer ready for every board question except one. An audit committee member asked where the malware blocklist enforced on every endpoint came from, and how he knew it had not been altered between the vendor's intent and what his agents loaded. He started to say "the vendor signs an SOC 2," then stopped, because that was not the question. The question was about the bytes, and he had no cryptographic basis for an answer.

That gap is more common than people admit. A blocklist fetched over HTTPS feels verified because the transport was encrypted, but TLS only authenticates the server for one connection. It says nothing about who produced the list, or whether it was modified at the origin, on a mirror, or in the bucket.

Feed tampering versus feed poisoning

Two failure modes get conflated. Tampering is modification after the producer signed off: a compromised CDN edge, a malicious mirror, a stale cache, a write to an S3 bucket whose policy drifted open. Poisoning is contamination at the source, where bad entries enter through the producer's own ingestion. Flooding a community blocklist with the IP of your payroll SaaS is poisoning; a man-in-the-middle stripping the malware category before it reaches your agents is tampering.

Signatures kill tampering and dent poisoning. A valid signature proves the bytes you loaded are the bytes the producer published, so a swapped or truncated list fails before it reaches policy. It cannot vouch for editorial judgment, so you still need source reputation and a fast exception path for the false positive that signs perfectly and is wrong.

Signing, verification, and rotation

Treat a blocklist the way you treat a third-party library: external code that runs inside your stack and decides allow-or-deny on live traffic. You would not ship a dependency with no checksum and no pinned version, and an unsigned feed is exactly that. The fix is plain. The producer holds an ed25519 key and signs each published feed; you ship the public key with the agent and verify the signature before the list is parsed, at load time rather than as a nightly cron that notices yesterday's problem.

Rotation is the part people skip and then regret. Pin the public key, keep an overlap window where two keys are trusted so a rotation does not blackhole every endpoint, and log which key verified which feed version. Once you can name the fingerprint, the version, and the timestamp behind any decision, you have provenance, not a vendor's assurance.

What an auditor can actually sample

Attestation is the deliverable a board wants, and it is not a screenshot of a block count. For any given day you should be able to produce four things, mapping onto the integrity-of-processing language in ISO 27001 and NIS2:

• Source: which feeds, from which producers, under which public keys
• Verification: the signature checked at load, with the result logged per fetch
• Failure handling: the documented behavior when a signature does not validate
• Rotation: key fingerprints, overlap windows, and the dates they changed

Fail-open versus fail-closed

This is the decision that separates a control from theater. On a verification miss, fail-open keeps the last known-good list and raises an alert; fail-closed refuses to enforce an unverifiable list at all. Most endpoint deployments want fail-open with loud alerting, because a feed-server hiccup should not strand your filtering. What you never want is the silent third option, where a tampered list loads because nobody wired verification in.

ClearScreen signs its threat feeds with ed25519 and verifies every fetch at the agent before a domain is blocked, so each policy group enforces a list whose origin you can name to an auditor, and the verification record is yours to sample. If you would rather answer "where did this come from, and was it tampered with" with a key fingerprint than a shrug, the mechanics are on the security page.