When your server security scanner reports hundreds of CVEs every week, you need a system that surfaces the genuinely dangerous vulnerabilities without making you read every advisory. Priority 5 rules—the highest severity tier in most vulnerability management tools—let you filter for remotely exploitable flaws with known public exploits, active campaigns, or pre-auth vectors. I built this triage ruleset after watching teams waste hours scrolling through medium-risk library updates while a critical RCE sat unpatched for three days.
This guide walks through the entire setup from choosing a scanner to writing the filter logic to testing the workflow.
What you need before you start
You'll configure rules in a vulnerability scanner that supports custom severity mappings. Open-source options include OpenVAS, Trivy, or OWASP Dependency-Check. Commercial platforms like Tenable, Qualys, or Rapid7 also work. The commands below assume a Linux environment with root or sudo access.
Make sure you have:
- A working vulnerability scanner already installed and running scans
- Access to the scanner's rule engine or API
- A notification channel (email, Slack webhook, ticketing system) to route priority alerts
- SSH access to the servers you're scanning
You don't need a dedicated SIEM or expensive correlation engine. A basic cron job and a shell script will handle most hosting environments.
Step 1: Define what makes a CVE priority 5
Not every CVSS 9.8 bug deserves the same urgency. Start by deciding your own criteria. In support tickets I handled, the usual culprit was mixing base score with real-world context.
Here's the filter I use:
- Base CVSS score ≥ 9.0 or CVSS ≥ 7.5 with an exploit available in Metasploit, ExploitDB, or a public PoC
- Network vector (AV:N in CVSS v3) meaning remote exploitation without local access
- No authentication required (PR:N) or only low privileges needed
- Affects a service exposed to the internet (check with
ss -tulnor firewall rules) - Vendor has released a patch or a workaround you can implement now
If a CVE meets three of those five, it goes into priority 5. Adjust the thresholds for your risk appetite, but write them down before you configure anything.
Step 2: Pull the CVE feed
Most scanners sync with the National Vulnerability Database automatically, but you want enrichment sources too. Download the CISA Known Exploited Vulnerabilities catalog and the EPSS (Exploit Prediction Scoring System) feed. Both are JSON and update daily.
curl -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
curl -o epss.csv https://api.first.org/data/v1/epss
CISA KEV lists CVEs with active exploitation. EPSS gives probability scores (0.0–1.0) that a CVE will be exploited in the wild within thirty days. Store these files where your scanner can reference them—/var/lib/vuln-feeds/ works.
Refresh them daily via cron:
0 2 * * * /usr/local/bin/update-vuln-feeds.sh
Your update script just re-runs those two curl commands and logs the timestamp.
Step 3: Write the priority filter
Now you translate your criteria into the scanner's query language. I'll show OpenVAS and a generic API example.
OpenVAS filter
OpenVAS uses a tag-based system. Create a new filter in the web UI under Configuration → Filters → New Filter. Name it "Priority 5 - Critical RCE" and paste:
severity>9.0 and vulnerability_type~"Remote Code Execution" and solution_type="VendorFix"
That catches high-scoring RCE flaws with patches available. For more nuance, export results via gvm-cli and parse with jq:
gvm-cli socket --xml "<get_results filter='severity>9.0'/>" > results.xml
xmlstarlet sel -t -m "//result" -v "nvt/@oid" -n results.xml | while read oid; do
# Check CISA KEV for this CVE
grep -q "$oid" /var/lib/vuln-feeds/kev.json && echo "$oid" >> priority5.txt
done
That loops through your scan results and flags any OID present in the CISA catalog.
API-based filter (generic)
If your scanner has a REST API, fetch results and filter in Python or bash. Here's a Python snippet:
import requests
import json
response = requests.get("https://scanner.example.com/api/vulnerabilities", headers={"Authorization": "Bearer YOUR_TOKEN"})
vulns = response.json()
kev_list = json.load(open("/var/lib/vuln-feeds/kev.json"))
kev_cves = {v["cveID"] for v in kev_list["vulnerabilities"]}
priority5 = [v for v in vulns if v["cvss"] >= 9.0 or v["cve"] in kev_cves]
with open("/var/log/priority5.json", "w") as f:
json.dump(priority5, f, indent=2)
Run this after every scan finishes. You now have a clean list of the vulnerabilities that need action today.
Step 4: Route alerts to the right channel
Don't dump priority 5 findings into the same email inbox as medium-risk dependency updates. Create a dedicated Slack channel, a PagerDuty integration, or a ticketing queue.
For Slack, use a webhook:
#!/bin/bash
PRIORITY5_FILE="/var/log/priority5.json"
WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
if [ -s "$PRIORITY5_FILE" ]; then
COUNT=$(jq 'length' "$PRIORITY5_FILE")
MESSAGE="⚠️ $COUNT critical CVEs detected. Review: https://scanner.example.com/reports/latest"
curl -X POST -H "Content-Type: application/json" -d "{\"text\":\"$MESSAGE\"}" "$WEBHOOK"
fi
Schedule this script to run after your scan cron job. Adjust the timing so the alert fires within fifteen minutes of scan completion.
For email, pipe the JSON through mail with a red-flag subject line:
jq -r '.[] | "\(.cve): \(.description)"' /var/log/priority5.json | mail -s "[CRITICAL] Priority 5 CVEs" [email protected]
Keep the message body short. Include the CVE ID, affected package, and a link to your patching runbook.
Step 5: Automate the first response
Once a priority 5 CVE lands, you want automatic containment while a human investigates. Write a response playbook that the alert can trigger.
Example actions:
- Block external access to the vulnerable service using
iptablesor Cloudflare WAF - Restart the service with a known-good older binary if a patch isn't available yet
- Enable stricter rate limits on the affected endpoint
- Take a filesystem snapshot before applying patches
Here's a simple containment script triggered by your alert:
#!/bin/bash
VULN_SERVICE="$1" # e.g., "apache2" or "nginx"
echo "Blocking external traffic to $VULN_SERVICE"
iptables -I INPUT -p tcp --dport 80 -j DROP
iptables -I INPUT -p tcp --dport 443 -j DROP
echo "Snapshot taken at $(date)" >> /var/log/priority5-actions.log
lvcreate -L 5G -s -n snap-$(date +%s) /dev/vg0/root
echo "Service $VULN_SERVICE isolated. Manual review required."
This buys you time to test the vendor patch in staging before rolling it to production. Don't auto-apply patches to live servers—I've seen that break more things than it fixes.
So what about false positives?
Priority 5 rules will flag some CVEs that don't apply to your environment. A vulnerability in a PHP extension you don't use, or a Windows-only bug on your all-Linux fleet.
Build a suppression list. Track CVEs you've reviewed and dismissed:
echo "CVE-2024-12345" >> /etc/vuln-scanner/suppressed.txt
Update your filter to skip anything in that file:
grep -v -f /etc/vuln-scanner/suppressed.txt /var/log/priority5.json > /var/log/priority5-filtered.json
Document why you suppressed each CVE. "Not applicable—service not installed" or "Mitigated by WAF rule 4827." Future you will thank current you.
Step 6: Test the entire pipeline
Before you trust this in production, inject a fake high-severity CVE and verify every stage fires.
Add a dummy entry to your scanner results or edit the JSON feed:
{
"cve": "CVE-9999-TEST",
"cvss": 10.0,
"description": "Test RCE vulnerability",
"affected_package": "test-pkg",
"solution": "Upgrade to test-pkg 2.0"
}
Run your filter script. Check that:
- The fake CVE appears in
/var/log/priority5.json - The alert fires in Slack or email within the expected window
- Your containment script executes (or would execute, if you're testing in dry-run mode)
- The finding shows up in your ticketing system with the right priority label
Fix any gaps before you enable the rules for real scans.
Step 7: Document the workflow and schedule reviews
Write a one-page runbook that explains:
- What triggers a priority 5 alert
- Who gets paged (on-call rotation or specific team)
- The containment steps to run immediately
- Where to find patch instructions for each OS or service
- How to suppress a false positive
Store it in your internal wiki or a Git repo alongside the scripts. Update it every time you add a new data source or change a threshold.
Review your priority 5 criteria quarterly. Threat landscapes shift. A CVE that was theoretical six months ago might have Metasploit modules now. Adjust your CVSS cutoffs or exploit-availability checks to match current risk.
Keeping the system running
Once you've deployed this, you'll need to maintain the feeds and tune the filters. Set a calendar reminder to check the suppression list every month—old suppressions might become relevant again if a new exploit drops.
Monitor your alert volume. If you're getting ten priority 5 notifications a day, your thresholds are too loose. Aim for one or two per week. That keeps the urgency real and prevents alert fatigue.
Rotate your on-call team through the triage process so everyone understands how the rules work. The person writing patches shouldn't be the only one who knows how to read the output.
FAQ
Q: Can I use this with Windows servers?
Yes. Replace apt or yum commands with wusa.exe for patches, and adjust service control with sc.exe or PowerShell. The logic and feeds stay the same.
Q: What if my scanner doesn't support custom filters?
Parse the results with jq, xmlstarlet, or a Python script. Most scanners output JSON or XML. Build the filter outside the tool.
Q: How do I handle CVEs with no patch available?
Apply a workaround if the vendor published one (config change, firewall rule). If no workaround exists, isolate the service or take it offline until a fix ships. Document the decision in your ticketing system.
Q: Should I include CVSS v2 scores?
No. CVSS v3 and v3.1 are more accurate for network-facing risks. Ignore v2 unless you're stuck with legacy tooling that only reports it.
Q: What's the difference between EPSS and CISA KEV?
EPSS predicts future exploitation probability using machine learning. CISA KEV lists CVEs with confirmed real-world exploitation. Use KEV for immediate action and EPSS to prioritize patching order for everything else.
What to check first when alerts stop firing
If your priority 5 alerts go quiet for more than a week, verify the feeds are still updating. Check the timestamp in /var/lib/vuln-feeds/kev.json. If it's stale, your cron job failed or the upstream URL changed.
Run a manual scan and compare the output to your filter logic. A scanner update might have changed field names or severity mappings. Test your parsing scripts after every scanner upgrade.
Finally, confirm your notification channel is still reachable. Slack webhooks expire if the app gets removed. Email addresses change. Check the delivery logs and send a test message monthly to catch silent failures early.