Wazuh system inventory for IT hygiene

The inventory follows a fixed path through the Wazuh components, and knowing that path tells you where to look when data is missing. A Wazuh agent installed on each endpoint collects system inventory data and sends it to the Wazuh server. The server analyzes the incoming data with decoders, which parse and normalize the records, and with rules, which decide what the records mean. The Wazuh indexer, a full-text search and analytics engine, stores the results, and the Wazuh dashboard reads from the indexer to show them. Each hop is a separate place to check when a host appears to have no inventory.

Because the server manages agent configuration remotely, inventory collection is controlled centrally rather than edited on each machine by hand. Agents run on Linux, Windows and macOS, among other platforms, so one policy model can cover a mixed fleet. A server can also run as a cluster to scale horizontally, which matters once the number of agents grows. Confirm the exact inventory fields each agent version reports and the collection intervals in the documentation for the version you install. Field names and timing can change between releases, and your alerting and dashboard filters depend on them.

IT hygiene teams usually start with a short list of questions the inventory should answer. They look for unexpected software on endpoints, services that should not be running, local users or groups that nobody recognizes, and browser extensions that are not on the approved list. In the dashboard, these become saved views filtered by host group, with each view compared against a baseline your team maintains. The baseline is your responsibility. Wazuh shows what the agents report, but someone must decide which entries are approved, who owns each exception, and how a new item gets reviewed.

Before you roll the inventory out widely, run it on a small test group that includes Windows, Linux and macOS hosts, and check each item on your list against what the dashboard shows. Confirm that browser extensions and local accounts appear for the browsers and platforms you use. Also note that vulnerability detection correlates the same software inventory with vulnerability data from the Wazuh Cyber Threat Intelligence platform or an offline repository, so an inventory gap also becomes a gap in vulnerability findings. Document who triages new items and how often, because the inventory produces data only your team can act on.

Vulnerability detection in Wazuh is a correlation step. Agents collect the software inventory from each endpoint, and the Wazuh server matches those package records against vulnerability data from either the Wazuh Cyber Threat Intelligence (CTI) platform or an offline vulnerability repository. The inventory is only half of the input, so the detection result depends on which vulnerability source you choose and how current it stays. Before you tune anything, decide which feed is authoritative for your environment. Hosts that can reach the CTI platform have a different option set from air-gapped segments, which need the offline repository described in the Wazuh offline installation guide. Mixed estates often need both. Document which hosts rely on which source so that anyone asking where a finding came from gets a traceable answer.

The age of the vulnerability data matters as much as the age of the inventory. Confirm with Wazuh how often the CTI data is updated. For an offline repository, assign an owner for fetching, transferring and loading each update into the disconnected server, and agree on how often that happens. Write down the staleness you will accept before a feed counts as a control gap. Also check that the inventory collection interval on agents matches your patch cycle. A vulnerability database that updates daily, paired with an inventory that refreshes weekly, will report packages that were already removed or upgraded, and those stale findings will consume triage time without reducing risk.

The inventory records everything installed, including libraries that nothing calls, build tools left on production servers and packages on hosts scheduled for decommissioning. These packages can generate findings that look like exposure but may not be reachable in practice. Decide the triage rule before the first full scan. Define which packages or host groups can be exempted, who approves each exemption, where the reasoning is recorded and whether exemptions expire. Avoid blanket suppression, because it removes the evidence an auditor will ask for. Test the rule on a small host group first (illustratively, a set of servers whose package list you already know), then confirm that the dashboard reflects the change after the next inventory and detection cycle.

Naming differences between the inventory and the vulnerability data create false positives and false negatives. Linux distributions, Windows applications and macOS applications identify the same software in different ways, and distribution maintainers often ship security fixes under an unchanged upstream version number. Correlation can therefore match the wrong product or flag a patched build. After the first full run, review the highest-volume findings for each operating system family and sample a few hosts by hand. Confirm with Wazuh how it handles backported fixes on your distributions. Also confirm the supported operating systems and package managers for vulnerability detection in the current documentation, because coverage differs by platform and that determines the review effort. Keep a log of suppressed matches and recheck them after each feed update.

Systems without internet connectivity can still use Wazuh system inventory, but vulnerability detection changes shape. The Wazuh offline installation guide covers installing the platform on networks with no internet access, and vulnerability detection can draw on an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Before the build starts, decide who owns the repository, where it is staged, and how it reaches the server. Confirm the exact installation and update steps in the offline guide for the Wazuh release you plan to run, because the procedure is tied to the release and is the authority for your environment.

The repository becomes an operational artifact that someone must move on a schedule. A workable model has a designated operator retrieve the current repository on a connected staging system, pass it through your approved transfer path, and import it into the Wazuh server according to the offline guide. Your media handling rules, malware scanning of transferred files and approval steps all apply to this file just as they do to software packages. Agree on the update cadence in advance. Wazuh 4.14 patch releases have arrived roughly every one to two months, so plan at least that frequency for repository refreshes and check whether your release needs a matching repository version.

Confirming that the data is current is the control that makes offline detection meaningful. Vulnerability detection matches the software inventory that agents collect against vulnerability data, so an outdated repository can leave newly published issues unreported without any visible error. After each import, record the date of the repository and confirm the server reports the new data, then check the vulnerability views in the Wazuh dashboard. As an illustrative test, install a package version known to carry a published vulnerability on a lab endpoint, confirm that the expected finding appears after the import, and keep the result with the update record.

Change records keep the offline process auditable. For every repository update, log the Wazuh release, the repository version and date, the source system, the transfer media identifier, any checksum or signature the process provides, the operator and approver, the import time and the verification result. Store these records alongside your inventory evidence so an assessor can trace which vulnerability data was in force on a given date. Review the log whenever the Wazuh release changes, because the offline guide and repository format may change with it. Ask your partner or internal team to document this procedure as a runbook before go-live.