The scanner does one thing now

We removed something from Wegweiser this week. This post is the honest account of what went, why, and what you get instead.

What was removed

The endpoint scanner used to read public vulnerability feeds every night, CISA KEV, NVD and GitHub advisories, and write a YARA detection rule for each one worth writing. It is a good-sounding feature. It is on the scanner page. It produced 3,096 rules.

Not one of them ever ran.

Every generated rule was written into a scan profile called threat_intel, and no scan could ask for that profile. The agent picks its ruleset from the scan mode it is given, no mode was ever mapped to that profile, and the server never sent one. So the pack was compiled every night, published, and requested by nothing. It had been that way since the feature shipped.

Nobody noticed because nothing was wrong in a way that shows up. There was no error. The rules validated, the pack built, the counter went up. What there was not, anywhere, was a number that said how many of these rules had ever fired. When we finally asked, the answer was zero, and it had always been zero.

Why we are not simply fixing it

The obvious response is to wire the profile in and let the rules run. We decided not to, because the feature was also the wrong tool.

YARA matches file contents. It is built for finding known-bad files: malware, webshells, exploit kits. A vulnerability is usually something else entirely. It is a property of legitimate software you installed on purpose, and most advisories describe it in prose with no byte pattern in it. There is nothing in "heap overflow in the RTSP request parser via an oversized Transport header" for a content scanner to match, so a rule written from that sentence is guessing at strings.

The question that sentence actually asks is "am I running a vulnerable version of this product", and Wegweiser already answers it three better ways: installed software analysis, patch compliance, and binary inventory. We were using a malware tool to do patch management, badly, alongside three things doing it properly.

What the scanner is for

It finds software nobody sanctioned, and it complements your antivirus rather than competing with it.

Your AV is good at malware. It is also deliberately silent about a developer installing an AI coding assistant on a client machine, a technician leaving a remote-access tool behind after a job, or a miner running quietly under a user profile. None of those are malware. All of them are things you get asked about, and none of them are in anybody's malware ruleset, because they are not malware.

That is the gap, and it is the part of our scanner that has always worked. Seven hand-written rules, looking for unsanctioned AI tooling, account for 42% of every detection Wegweiser has ever made. The other 58% comes from 41,227 imported community rules.

We are not dropping malware detection. The scanner still carries a core of named, high-severity detections chosen to complement AV rather than duplicate it, and the full community corpus is still there for deep scans. But the headline is the unsanctioned-software half, because that is the half that tells you something your other tools will not.

What changed underneath

While we were counting, we found the catalogue in a worse state than the one retired feature.

Of 50,240 rules, only 2,844 could run on a normal day. 37,010 had been imported and never assigned to any scan at all. Another 4,857, the freshest material we have and refreshed weekly, sat in a profile that ran once in the last thirty days. The set of rules actually reaching your endpoints had not changed since April.

So rule selection is now one policy in one place, re-applied every day instead of decided once at import:

• The daily sweep now selects about 800 rules: the unsanctioned software packs, every rule that has ever caught something, and named high-severity detections. Nothing that has ever produced a detection was dropped.
• Because a rule file is what the scanner compiles, and a file can hold several rules, the pack that actually ships contains 1,807 rules rather than 800: a selected rule brings its file-mates with it. So the honest number is that the daily pack went from 2,844 rules to 1,807, not to 800. We would rather give you the number that is true than the one that sounds better.
• The deep scan went from 9,076 rules to 30,233. That is where the 37,000 orphans rejoined the product.

A smaller daily sweep is the point, not a compromise. The cost of a detection ruleset is not the scanning, it is the false positives: a noisy rule buries the real findings and teaches people to click past them. A rule that runs on every machine every day should have to earn it.

What this means for you

Nothing you were receiving stops. The retired rules had never executed on any endpoint, so no detection you have ever had came from them, and none will stop arriving. Your scan results, your health scores and your detection history are unchanged.

What improves is signal. Fewer rules run daily, the ones that do have a reason to be there, and the ones that never ran now at least run on a deep scan.

The part we are less comfortable about

A feature that does nothing is worse than no feature, because it occupies the place where a working one would go. This one sat there for months with a page describing it and a counter going up.

The reason it lasted is that we measured the wrong thing. We counted rules generated. We never counted rules fired. Those numbers are one query apart and we did not run it until an unrelated question about an API bill made us look.

We have added the number we were missing. If a class of rule is producing nothing, we would now rather know early and say so than find out in a year.