Half a year of green

A scan that runs and finds nothing looks like a clean device. A scan that runs and never received its configuration looks exactly the same. Both report their run, both return an empty list of findings, and the dashboard says the same thing in both cases: nothing to do.

This is not an observation from consulting work. It is our own mistake, and it ran for half a year.

What had happened

On every poll our agent fetches its tasks and, for some of them, a configuration block: the paths it should search, the hardening profile it checks against, the registry keys it watches.

Up to agent 1.88.0, one place in the agent failed to pass five of those blocks on to the scans that needed them. The server delivered them, the agent received them, the scans ran. And they ran without the very thing they were built for.

None of that was visible on the server side. The tasks reported their runs on time, the error list stayed empty, and so did the findings list. From every perspective we had, it looked like a well-kept fleet.

Why this stays hidden for so long

Because the absence of a finding is not a signal. It is the normal case.

A device with no missing updates rightly has no patch entry. A server nobody changed rightly has no integrity alert. Treat an empty list as an error and you generate alarms about machines where everything is fine. So nobody does, and so the one case where the empty list is a defect slips through every filter.

The question missing from a monitoring tool is therefore not is the scan running. It is: when did this device last return a result?

Three statements side by side

The device page has a new Configuration tab. For each of the ten blocks it recalculates what would go to this particular device right now. Only the third statement makes the error visible.

Is it delivered? Module active, agent version sufficient, task created and enabled. Where the answer is no, the row names the reason, and for an outdated agent both the actual and the required version.

Is the task running? The time of the last run.

Is anything coming back? The time and number of results, counted in the table where this scan actually files its findings. Not in a log, not in a status message. Where the result ends up.

Exactly one combination is highlighted: the configuration goes out, the task runs, and no result has arrived for more than a week. That is the fingerprint of the error we had.

The row is deliberately not an alarm but a question with a time span, because it can be harmless and often is. For the same reason, blocks with no results table say not measurable in so many words: a green tick where nobody can check the arithmetic would be precisely the kind of reassurance that cost us half a year. And to keep the view itself from going stale, a test compares it against the real delivery path, in both directions.

What carries over

The error is not confined to agents. It occurs wherever a check reports its own run and the result is never reconciled: vulnerability scans that skip a segment because the credentials expired and still count as complete. A log collection whose source has delivered nothing since the last server move. A backup that runs through cleanly but has been backing up an empty directory for weeks.

In all three cases the display is green, and in all three it only says that something ran.

Checking this in your own organisation needs no tooling: take three systems you are confident are well maintained and find the time of the last result, not the last run. If you cannot find it, you have the same gap.

More about the module on the Agent Management module page.