Wazuh vulnerability detection

Before you rely on Wazuh vulnerability detection, prove that it finds a known weakness, clears it after a fix, keeps working without internet access, and reports its own gaps. The test is not complete when the dashboard loads. It is complete when you can show, with dated evidence, that each path behaves as designed. Run these checks on a non-production test host and a test server first, then repeat the offline and failure checks in the environment you will operate. Seed a known outdated package. Choose a test host with a Wazuh agent enrolled, and install an older version of a common package from your distribution's repository, one that you know has published vulnerabilities. Record the package name, version and the date of installation. Then confirm the package appears in the agent's software inventory on the Wazuh server, and that a corresponding finding appears in the vulnerability views after the detection cycle runs. If the package appears in inventory but no finding is created, the problem lies in the vulnerability data source or the matching step, not in the agent. Do not assume the cycle timing; check the documented evaluation behavior for your release line on the Wazuh vulnerability detection page.

Confirm a patched package clears the finding. Update the same package to a fixed version through your normal patch tool, then wait for the next inventory scan and vulnerability evaluation. The finding should move to resolved or disappear, and the inventory should show the new version. Test this on at least two hosts, because a single success can hide a problem with one agent's inventory collection. Note how long the clearance took and compare it with the scan interval you configured. A finding that never clears is as serious as one that never appears, since it trains analysts to ignore the queue. Test the offline path. If your network restricts internet access, the server must generate findings from the local vulnerability repository rather than from the Wazuh Cyber Threat Intelligence platform. Disconnect the test server from the internet, keep the agents connected to it, and run the same seeded-package test. Confirm that findings still generate and that the repository version and its update date are visible to the operator. Also confirm what happens when the repository is older than your expected refresh cycle. Confirm with your own network team and the offline installation guide how the repository is updated and transferred into the restricted zone.

Verify that failures are visible. The most dangerous outcome is a silent zero. Simulate a failed data source by blocking or misconfiguring the path to the vulnerability feed or local repository, then run an evaluation. Check that the platform raises an error in the logs, the dashboard or your monitoring tool, rather than showing an empty findings list. Repeat with a stale repository, using a copy whose date you have deliberately set back, and confirm the staleness is surfaced. Decide in advance who receives these alerts and how quickly they must be acted on. Check that inventory gaps are reported. Zero findings for a host means little if the host was not evaluated. Stop the agent on one test host and confirm that it is reported as disconnected or stale and is not silently dropped from coverage. Install a software type that the agent does not inventory, or review the documented list of supported package managers and software types for your operating systems, and confirm that the gap is listed as unevaluated rather than clean. Your coverage report should show total enrolled agents, agents evaluated in the window, and unsupported or excluded items. Record the evidence. Keep a dated test record with the Wazuh server, indexer and dashboard versions, the agent versions, the repository or feed version, the seeded package and its versions, and the screenshots or log extracts for each step. Repeat the tests after each patch release on the 4.14 line and after any change to the repository refresh process. Auditors and security reviewers will ask how you know detection works, and a record that names versions and dates answers that question far better than a verbal assurance.

Monitoring starts with the inputs. Vulnerability detection only matches what agents report, so an endpoint that stops sending its software inventory drops out of coverage without any visible error. Compare the number of enrolled agents with the number that have reported inventory recently, and treat any gap as an operational issue. Next, confirm the freshness of the vulnerability data source. If the Wazuh Cyber Threat Intelligence (CTI) platform feeds the detector, check the date of the last successful update. If you use an offline repository, check when it was last refreshed from the source you copy from, because a repository that is weeks old will miss recent disclosures. Record both checks in your dashboard or ticketing system so drift is visible to the people who own them.

Second, watch the platform components that the detector depends on. The Wazuh server analyzes agent data and the Wazuh indexer stores the resulting alerts, so a stalled server or a full indexer disk stops new findings from being written even though the dashboard still loads. Track service status, indexer cluster health and disk growth on each node, and set alert thresholds with your operations team based on your own capacity baseline. Finally, track finding counts by age, grouping open vulnerabilities by how long they have been detected. A growing share of old findings usually points to a triage backlog or an exception process that nobody is reviewing. Agree on a review cadence with the security owner and keep the trend visible in the same place as the health checks.

Back up three things beyond the indexer data itself. First, the server configuration, including the files that define the vulnerability detection module and any changes made through agent group configuration. Keep these under version control or in a configuration store so you can see who changed what and when. Second, custom settings for vulnerability detection, such as which content sources are enabled, how the offline repository is referenced, and any parameters you changed from defaults. Third, exception records. Each accepted risk, suppression or deferred remediation should be stored with the finding identifier, the justification, the named owner and a review date. A restore that recovers alerts but loses these records leaves analysts and auditors with no way to explain past decisions. Confirm your indexer snapshot approach against the Wazuh documentation for your version before relying on it.

Each 4.14 patch is a point to recheck detection behavior. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, and the latest of these is 4.14.9, released on 14 October 2026. After applying any patch, confirm that agents still report inventory, that the data source still updates, and that a known test finding still appears with the expected severity. Run the patch on a staging host with a representative set of agents first, and compare its results with production before promoting it. Read the release notes for changes that affect vulnerability detection before you schedule the change window, and record the outcome of each post-patch check so you can show what was verified and when.

Document four things so the process survives staff changes. Record the data source decision: whether detection uses the CTI platform, an offline repository or both, why that choice was made, and who approved it, since this shapes every later check. Write the update process for that source, including who pulls or imports updates, how often, and how a failed update is detected and escalated. Document the triage workflow: how severity is handled, who owns each decision, how exceptions are requested and reviewed, and what must be true before a finding is closed. Finally, keep evidence samples such as dated dashboard exports, sample findings with their triage history, and exception records. Confirm with your auditor or assessor which evidence formats and time periods they expect, since these depend on the framework and scope that apply to your organization.