Learn Wazuh - Vulnerability Detection

#Introduction

In episode 8 you learned to act fast with active response and detect malware with rootcheck, YARA, and the malware scan module. But there's a class of risk that doesn't always come from malware: known vulnerabilities inside legitimate packages. Even official applications can carry holes that invite attackers.

Episode 9 covers Vulnerability Detection (VD). We'll see how Wazuh builds a vulnerability inventory on each agent, compares it against CVE feeds from NVD and OSV based on CPE, then presents the results through the Vulnerabilities dashboard. We'll also cover scan schedules and patch management on Windows.

By the end of this episode you can map the risk of an entire fleet in one view, without waiting for an attack to happen.

#What Is Vulnerability Detection

Vulnerability Detection is the Wazuh module that looks for vulnerabilities in installed software packages. The workflow starts with the agent collecting a package inventory: name, version, and vendor. The manager then matches that information against a CVE database updated periodically.

When a package version matches a certain CVE's criteria, Wazuh generates a vulnerability alert with a level matching the severity. It's important to understand that this module detects vulnerabilities in legitimate software, not attacker activity. The two complement each other: event detection captures what happened, VD captures what's at risk.

Before continuing, remember one basic property of VD: this module is purely data comparison, not behavioral analysis. There's no heuristic or machine learning inside it. The quality of results depends entirely on three things: the completeness of the agent inventory, the accuracy of the feed, and how fresh the CVE database is. If any one is weak, scan results can go astray.

Its way of working is like checking expiry dates in a warehouse. The warehouse keeper doesn't need to know how a product works; they just compare the date label on the packaging against a list of dates that are no longer safe. Wazuh does the same thing across thousands of packages, then concludes which products should be patched or replaced.

The advantage of this approach is broad coverage at low compute cost. An agent with hundreds of packages can be scanned in minutes. Its limitation is also clear: packages not tracked by the package manager, like manually downloaded binaries, will escape this comparison.

#Inventory and CPE Feeds

VD's heart has two parts: the package inventory on the agent side and the vulnerability database on the manager side. The agent builds a complete package list with versions from the system package manager, while the manager maintains a CVE database organized around CPE (Common Platform Enumeration).

CPE is a naming standard for software products and versions, shaped like cpe:2.3:a:apache:http_server:2.4.49. This format becomes the bridge language between installed packages and the vulnerability descriptions in the database. Wazuh uses feeds from NVD (National Vulnerability Database) plus OSV as a complement for newer vulnerabilities.

The comparison isn't just name matching, but matching affected version ranges. A CVE may state version 2.4.49 is vulnerable while 2.4.50 is safe. Wazuh evaluates whether the installed version falls within the vulnerable range, then generates an alert only if it's genuinely affected.

NVD is the primary source because it tracks thousands of CVEs with structured CVSS and CPE details. However, adding new entries to NVD sometimes takes time, so OSV serves as a complementary layer for newly announced vulnerabilities, especially those from the open source ecosystem. With two sources at once, the blind window between when a vulnerability is announced and when it appears in the database can be narrowed.

Remember that CPE doesn't always capture every product perfectly. Some packages have vendors that aren't consistently registered, or products whose naming differs between agent and feed. Such conditions are usually flagged as undeterminable vulnerabilities, and Wazuh sets them aside from alerts so they don't create noise.

#Enabling the Vulnerability Detector

The vulnerability detector isn't enabled automatically. You must define the module, the feed update schedule, and which operating systems are scanned in the vulnerability-detector section of the manager's ossec.conf.

<ossec_config>
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>12h</interval>
    <update_from_feed>yes</update_from_feed>
    <feed type="nvd" update_interval="6h">https://nvd.nist.gov/vuln/data-feeds</feed>
    <host_os>
      <distribution>almalinux</distribution>
    </host_os>
    <host_os>
      <distribution>ubuntu</distribution>
    </host_os>
  </vulnerability-detector>
</ossec_config>

The configuration above enables the module with a scan every 12 hours, refreshes the NVD feed every 6 hours, and scans AlmaLinux and Ubuntu hosts. The host_os list determines which operating systems join the scan; the rest are ignored. Each OS also has different needs: Windows uses dedicated data sources, while Linux distributions rely on their own package managers.

Once the configuration is ready, run systemctl restart wazuh-manager to activate the module. Give the first process time to fetch the feed and run the initial scan, because results don't appear instantly.

To make sure the module is really running, check the manager log with tail -f /var/ossec/logs/ossec.log and look for lines mentioning vulnerability-detector. The first run usually logs the feed fetch followed by each agent's scan results. If those lines don't appear, the configuration may not have been read yet or the first run's schedule hasn't arrived.

#Per Operating System Configuration

The operating system selection in the host_os block is the main gateway to configuration. Every agent whose OS matches one of the listed distributions is scanned, while non-matches are silently skipped. The following example adds Windows and macOS to the previous configuration.

  <host_os>
    <distribution>windows</distribution>
  </host_os>
  <host_os>
    <distribution>macos</distribution>
  </host_os>

The distribution name must match what Wazuh recognizes. For Linux, use names like ubuntu, debian, rhel, centos, almalinux, suse, or arch; for Microsoft servers use windows, and for Apple desktops use macos. Misspelling a distribution name means that agent will never be scanned without a clear error message.

The scanned data also differs by operating system. On Linux, the agent reads the package list from dpkg, RPM, or another package manager. On Windows, the agent uses Windows Management Instrumentation to collect the application and update list. On macOS, the agent scans packages registered in Homebrew. Each path has its own strengths and limitations in terms of data completeness.

#Scan Schedules

Wazuh gives this module two separate schedules. The first is interval: how often agent scans run. The second is update_interval on the feed element: how often the manager's CVE database is reloaded from the source.

Tight schedules speed up discovering new packages, but also add load to agents and manager. A 12-hour interval is a common starting point. For environments with very frequent package changes, a shorter interval can be considered with careful load monitoring.

Feed updates have their own rules of thumb. Downloading the feed on every scan isn't an efficient choice; it's far better to load the database on a longer interval, say 6 or 12 hours, then let scans use the already-stored database. This consistency also matters so results across agents can be compared against the same vulnerability database.

Besides the automatic schedule, Wazuh runs a scan when the module first activates and whenever an agent reconnects after a long disconnection. These scenarios keep the inventory fresh without manual intervention, so newly added fleet members are scanned immediately without waiting for the next schedule.

#The Vulnerabilities Dashboard

All alerts from this module are displayed on the Vulnerabilities dashboard in the Wazuh dashboard. You open it from the main navigation menu, then select the Vulnerability Detection page to see a summary in cards and charts.

The summary at the top usually shows the total number of vulnerabilities, how many are open or resolved, and the breakdown by severity such as critical, high, medium, and low. From there you can see the agents with the most vulnerabilities and the most frequent CVEs, so priorities are set immediately.

Click a vulnerability to open its CVE details: a short description, CVSS score, attack vector, affected products, and vendor references. This information is very helpful when you must decide which package to handle first. Filters by agent name, CVE, or severity can be used to narrow the list.

This dashboard is an aggregation of alerts, not separate storage. That means old results are only visible if their alerts still exist in the index. The index retention policy on the manager determines how far back you can see history, so make sure the retention duration matches your audit needs.

#Windows Patch Management

In Windows environments, this module plays a dual role: detecting application vulnerabilities while also watching the completeness of system patches. The agent collects the list of installed updates and compares it against the newest updates known to the feed, so notifications appear for patches that haven't been applied.

Wazuh doesn't replace WSUS or group policy, but it acts as a second set of eyes ensuring the patching process runs as planned. Its workflow is simple: observe the list of missing patches in the dashboard, install patches in staging first, then apply to production. After deployment, the next rescan will show the related vulnerabilities are gone.

A vulnerability appearing after a rescan doesn't always mean something went wrong; a new CVE can appear for the same product. That's why a healthy practice is recording a baseline: how many open vulnerabilities before a change, and how many after. The difference is what shows whether the patching process is effective.

One thing that's often overlooked is the time between a patch becoming available and deployment completing. The longer the gap stays open, the bigger the exploit risk. With this module's alarms, you can set closure targets, for example critical patches done within days, then monitor compliance regularly from the same dashboard.

#Conclusion

Vulnerability Detection completes the detection toolkit with a dimension that's rarely seen: risk lying dormant inside legitimate software. You now know this module works by comparing the package inventory from agents against CVE databases from NVD and OSV based on CPE, scans each agent according to the distributions registered in host_os, and presents all findings through the Vulnerabilities dashboard.

Key takeaways:

• VD compares installed packages against the CVE database, not attacker activity.
• Agents build the inventory from the package manager; the manager maintains CPE-based NVD and OSV feeds.
• The vulnerability-detector module must be enabled with a host_os list defining the scanned operating systems.
• Each OS configuration differs: Linux via dpkg or RPM, Windows via WMI, macOS via Homebrew.
• The scan schedule is controlled by interval, while the CVE feed is controlled by update_interval.
• The Vulnerabilities dashboard groups alerts by severity and makes remediation prioritization easy.
• On Windows, the module helps monitor patch completeness and compliance with closure targets.

In the next episode we'll see how findings like these connect to broader audit and cloud security needs. See you there!