Update posture
The v0.4.0 patch-posture collector: what Scout reports on Windows and Linux, the strict cached-metadata-only guarantee, its remote switch and 6-hour refresh cadence, and why older agents read Unknown.
What the module does
Scout v0.4.0 adds a collection module called patch posture. It reports this machine's OS update state — how long since it was updated, whether it is waiting on a reboot, how many updates are pending — so that VerOps can tell you which machines in your estate are behind and raise an alert when too many are.
The Machine Agent gained the same module in v0.3.0, with identical fields and identical semantics, so a mixed fleet of servers and workstations is measured the same way.
This article covers what the agent collects and how to control it. How the platform turns these facts into a current / behind / critical / unknown bucket, and where that appears, is documented in Patch posture.
The hard rule: read-only, cache-only
This module reads cached metadata and local logs only. It never refreshes package indexes over the network, never installs or changes anything, and needs no privileges beyond those Scout already has. That is a design constraint of the collector, not a configuration option you could accidentally turn off.
Concretely, and in both agents:
| Platform | How the guarantee is enforced |
|---|---|
| Debian / Ubuntu | Upgrade counts come from a simulated upgrade, which resolves entirely against the already-downloaded package lists. No mirror is contacted. |
| RHEL / Fedora | Every dnf and yum invocation runs strictly cache-only, which makes a network fetch impossible rather than merely unlikely. |
| SUSE | zypper is always invoked with refresh disabled. |
| Windows | Build, reboot flags and service state are read from the registry and the service manager; update history comes from the local update-history store. The network-touching update search is never called. |
Nothing is installed, nothing is elevated beyond what existing collectors already use, and every external command runs under a hard timeout (roughly 5–25 seconds depending on the probe) so a wedged package manager can never hang the agent.
What is collected
Windows
| Field | Meaning |
|---|---|
| Full OS build | The build number including the update build revision (UBR) — e.g. 22621.3007. |
| Last update installed | When an update most recently installed successfully, from the local update history (which covers feature updates, not just hotfixes). |
| Pending reboot | Whether a restart is outstanding, from the standard flags: servicing-stack reboot pending, Windows Update reboot required, and pending file-rename operations. |
| Windows Update service state | running, stopped, disabled or unknown. |
| Installed hotfix count | How many hotfixes are installed, with their identifiers. Informational — it is not an input to the posture bucket. |
Linux
| Field | Meaning |
|---|---|
| Package manager | apt, dnf, yum, zypper or unknown, detected by probing for the binaries. |
| Upgradable count | How many packages have a newer version available in the cached indexes. |
| Security-upgradable count | How many of those are security updates. Omitted entirely — not sent as zero — when the package manager cannot tell the difference (see below). |
| Reboot required | Whether the system needs restarting, from the distribution's own reboot marker or its standard reboot-check tool. |
| Last package activity | When packages were last installed or upgraded, from the package manager's log. Informational. |
Zero and "cannot tell" are never conflated. When a package manager genuinely reports no pending security updates, the agent sends zero. When it cannot distinguish security updates — for example when the advisory metadata is not in the local cache — the agent sends nothing for that field, and the platform falls back to the total upgradable count. Reporting zero in that case would score an unmeasured machine as clean.
Switching it and its cadence
Patch posture behaves exactly like Scout's other collection modules: it is remotely switchable from Inventory → Policy — organization-wide or per group — and takes effect on the agent's next config poll, about a minute later, with no reinstall and no file editing on the endpoint. It is on by default.
It also has its own refresh cadence, defaulting to every 6 hours and tunable from the same policy. Six hours is a deliberate trade: a posture scan spawns a package manager or a PowerShell process, and update state moves on the order of days, so scanning more often costs real endpoint resources for information that will not have changed.
The local default can also be set in the agent's configuration file, though a central policy overrides it whenever central config is active:
[modules]
patch_posture = true
On the Machine Agent the equivalent key lives under [inventory.modules].
Upgrading, and older agents
- Agents older than Scout 0.4.0 / Machine Agent 0.3.0 keep working against the platform unchanged — the section is optional, and its absence is expected rather than an error.
- A machine running an older agent, or one with the module switched off, reads posture Unknown. It is never scored as Current on missing evidence.
- Upgrading needs no re-enrollment: the device credential survives, and posture facts simply start appearing on the asset you already have.
- macOS is not supported in this release and always reads Unknown; a macOS host is never scored using Windows or Linux rules.
Verifying it works
- Confirm the agent version — the binary self-reports it (
verops-scout --version); the module needs 0.4.0 or newer. - Wait for one refresh cycle (up to 6 hours by default, or restart the service to scan at startup).
- Open the machine's asset detail page and look at the Update posture card in the Hardware/OS area — it shows the raw reported facts, the bucket and how long the bucket has held, rendering only the fields relevant to that machine's OS.
- If it still reads Unknown, check that the module is enabled in the policy that applies to that machine's group.
To confirm the read-only guarantee for yourself, watch the endpoint while the module runs: you will see no apt update, no dnf makecache, and no Windows Update network search.
Version history
The full changelog for both agents is available in the product: Inventory → Agents → Release notes, and in the drawer for each agent artifact under Resources → Downloads. It lists every release with its date, its highlights, and which version is current.