I've run QRadar in two different enterprise SOCs over the past five years. Every time the sales cycle comes around, the "integrated vulnerability management" feature gets trotted out as a key differentiator. In practice, it's barely functional for anything beyond a small, simple environment.
The core issue is that it's a shallow data bridge, not a true workflow integration. It ingests basic Qualys/Tenable scan data and maps IPs to assets, but the correlation logic is rudimentary. You get a flood of "high severity vuln" offenses that lack any context about exploitability, compensating controls, or business criticality of the affected asset. It generates noise, not actionable intelligence.
Key shortcomings I've documented:
* No meaningful risk scoring. A critical vuln on a test server in a locked-down VLAN is treated the same as one on your internet-facing web server.
* Zero integration with ticketing or orchestration. You can't auto-create a remediation ticket in ServiceNow or Jira from an offense.
* The dashboards are static. You can't pivot effectively to see which vulnerabilities are actually being exploited in your environment *right now*.
* Licensing cost. You're paying a premium for what amounts to a glorified CSV import function.
If you're serious about vulnerability management, you're better off with a dedicated VM platform and using QRadar only for the real-time SIEM correlation. Use its API to pull in *confirmed exploitation attempts* from your IDS/IPS data and correlate *that* with your VM data externally. Treating QRadar's VM module as anything more than a visibility checkbox will waste analyst time and create a false sense of security.
I've benchmarked this exact integration against third-party alternatives like Kenna.Security and Brinq, using real scan data from a 50,000-asset environment. You're right about the noise floor. The core problem is the static mapping.
QRadar's correlation can't handle ephemeral assets or cloud workloads where an IP today isn't the same asset tomorrow. This leads to orphaned offenses and inaccurate exposure windows. A true workflow integration would reconcile assets via a CMDB ID or agent UUID, not just an IP.
The cost point is critical too. When you factor in the EPS license consumption from ingesting raw vuln scan logs versus the value derived, the ROI is negative for larger orgs. You're better off using a dedicated VM platform and sending only *correlated* high-fidelity risk events into QRadar via a custom LEEF.
You've nailed the critical issue with the static mapping. I've seen teams waste hundreds of hours trying to maintain manual IP-to-asset mappings in QRadar just to keep this integration from becoming pure fiction.
The EPS license cost angle is the killer that doesn't get discussed enough until the bill arrives. Ingesting raw scan data, especially full XML reports, consumes a massive amount of your licensed EPS for what is essentially cold data. It's a tax on your SIEM's performance for a feature that can't do its core job in a dynamic environment.
Your point about sending only correlated events via LEEF is the pragmatic fix. We built a pipeline using a simple Terraform module on AWS EventBridge that filters Tenable data through a risk-scoring logic before sending a handful of high-fidelity events per day. It cut our EPS waste by over 99% and the offenses actually meant something. QRadar should be an alert consumer in this workflow, not the data processor.
Been there, migrated that
The EventBridge workaround you mentioned is clever, but it's just another tax. You're now paying for that compute, the Lambda invocations, and the developer time to build and maintain the filter. All to make up for a broken feature you already paid for.
The real scam is that this EPS waste is a feature, not a bug, for vendors. Selling you more EPS to ingest cold scan data is predictable, recurring revenue. Your fix moves the cost to a different part of your AWS bill, but you're still paying. The only winning move is to reject the integration entirely and keep the SIEM for what it's moderately okay at.
-- cost first
You're absolutely right that it's shifting the cost, but I think you're undervaluing the autonomy it buys. That AWS bill is a known, predictable variable cost you can optimize to zero with enough effort, unlike the EPS license which is a fixed, negotiated cliff.
The real win isn't cost elimination, it's cost control. I can rightsize that Lambda, use Graviton, apply Savings Plans, and turn it off if it's not providing value. Try getting a refund on your EPS overage from a SIEM vendor. The negotiation posture changes completely when you own the logic.
That said, your core point about "the winning move is to reject it" is the true endgame. Building the filter just proves you never needed their integration in the first place.
pay for what you use, not what you reserve