Wazuh’s vulnerability detection lets you sift through the flood of alerts on your dashboard and spot real CVEs before they become a problem, all by turning on the built‑in scanner, fine‑tuning rules, and pulling in fresh feeds from NVD or other sources. The guide walks you through making sure the manager is running, checking that wazuh-modulesd is installed, and enabling the scanner with an interval that suits your update rhythm. You can silence noisy alerts by adding custom rules to local_rules.xml, map CVE scores to severity levels, and configure Wazuh to read external JSON feeds for the latest exploits. A real‑world example shows how adjusting these settings uncovered a Log4Shell alert buried under low‑severity noise, while the quick checklist at the end reminds you of each critical command and file edit needed to keep your alerts focused on genuine threats.

Wazuh Vulnerability Detection – Spot CVEs Before They Bite

If you’ve ever stared at the sea of alerts on your Wazuh dashboard and wondered which ones actually matter, this is for you. In a few minutes we’ll cover how to turn on the built‑in vulnerability scanner, fine‑tune the rule set so you stop seeing spam, and hook up external CVE feeds so your alerts stay fresh.

Wazuh Vulnerability Detection: The Basics

1. Make sure the manager is running

   sudo systemctl enable wazuh-manager
   sudo systemctl start wazuh-manager

You need a live manager to aggregate agent data; otherwise you’ll be chasing ghosts.

2. Verify the vulnerability module is installed

On Debian/Ubuntu:

   dpkg -l | grep wazuh-modulesd

If it’s missing, pull the package from Wazuh’s repo and install it. The module does all the heavy lifting for scanning.

3. Turn on the default scanner

Edit /var/ossec/etc/ossec.conf and locate <ossec_config>. Add or un‑comment:

   <vulnerability>
     <enabled>yes</enabled>
     <interval>86400</interval>
   </vulnerability>

The interval is in seconds – 86400 equals once per day. Pick a value that matches your update cadence; otherwise you’ll waste CPU on useless scans.

Customizing the Rule Set

You’ve probably noticed dozens of alerts about “Old library detected” that never actually caused problems. To tame those:

1. Open /var/ossec/etc/rules/local_rules.xml

Add a rule that ignores packages your team knows are safe:

   <group name="vulnerability,">
     <rule id="100200" level="0">
       <if_match>openssl(?!.*3\.0)</if_match>
       <description>Ignore OpenSSL 3.0 detection on servers that run legacy code.</description>
     </rule>
   </group>

Setting the level to 0 silences the alert entirely.

2. Leverage severity tags

Wazuh can map CVE scores to levels automatically if you enable cve in /var/ossec/etc/wazuh.conf. After enabling, a high‑score CVE will push the event to level 10; anything below 5 drops to level 3. This helps you focus on the real threats.

Feeding External CVE Sources

The built‑in scanner relies on local package lists, but if you want the latest CVEs (think new exploits that hit a zero‑day), pull them from the NVD or a third‑party feed:

1. Install curl and fetch the JSON feed

   curl -s https://nvd.nist.gov/feeds/json/cve/2.0/nvdcve-2.0-2023.json.gz | gunzip > /tmp/nvdcve-23.json

2. Configure Wazuh to read the file – edit /var/ossec/etc/ossec.conf and add:

   <cve>
     <path>/tmp/nvdcve-23.json</path>
     <update>86400</update>
   </cve>

3. Restart the manager

   sudo systemctl restart wazuh-manager

Now Wazuh will cross‑reference detected packages against the latest CVE list and raise a true alert if you’re vulnerable.

Real‑world Scenario

I once saw a server in a small dev shop flagged for CVE-2021-44228 (Log4Shell) after their Tomcat got an “update” that actually shipped the buggy version. The alert came through Wazuh’s vulnerability module, but it was buried under hundreds of low‑severity package alerts. After tweaking the rule set to ignore known safe packages and enabling daily CVE updates, the Log4Shell warning surfaced at level 10 and the devs patched Tomcat immediately.

Quick Checklist

Task	Command / File	Why
Ensure manager runs	systemctl enable/start wazuh-manager	Data needs to be collected
Enable vulnerability module	Edit ossec.conf, set yes	Turns on scanning
Set scan frequency	86400	Balances CPU and freshness
Silence false positives	Add rules in local_rules.xml	Reduces noise
Import external CVE feed	curl … gunzip > /tmp/nvdcve.json	Keeps alerts up‑to‑date

That’s the low‑down. Turn on the scanner, prune the rule set, hook into a fresh CVE feed, and watch your alert list shrink to real threats.