Having spent the last six months migrating our endpoint security stack from a legacy AV to VMware Carbon Black Cloud, I've reached a conclusion that I need to test with the community. My deep-dive into the platform, especially during our data validation and integration phase, suggests that its vulnerability management module feels more like an acquired check-box feature for the sales sheet rather than a primary, robust offering you'd build a program around.
Let me walk through my methodical evaluation, which centered on three core areas: data quality, integration depth, and comparative value.
**On Data Quality and Enrichment:**
* The vulnerability data itself is surface-level. We're talking basic CVE IDs, severity scores (CVSS), and a patch status. It lacks the contextual enrichment I've seen in dedicated platforms—things like exploit availability (Is it weaponized?), active threat intelligence linking, or detailed remediation guidance beyond a vendor link.
* The scanning cadence and depth felt passive, tied heavily to the agent's normal telemetry rather than initiating deep, targeted vulnerability assessments. For critical assets, we needed more control.
**On Integration and Workflow:**
* While it's *there* in the console, the workflow to move from a detected vulnerability to a resolved ticket in our ITSM (we use Jira) was clunky. The API endpoints for vulnerabilities are a separate and less mature set from the core EDR telemetry APIs.
* We attempted to pipe findings into our risk-scoring dashboard, but the data model wasn't granular enough to weigh internal exposure effectively. It became a "list of issues" rather than a "prioritized action plan."
**On the Pricing and Value Angle:**
* This is the big one. When we evaluated the per-endpoint cost, bundling this feature made the suite appear more attractive. However, when I compared the capability depth to a dedicated VM tool like Qualys, Tenable, or even Rapid7 InsightVM, the difference was stark. It felt like we were paying a "suite tax" for a feature that wouldn't satisfy our compliance auditors on its own merits.
* For a small team with simple needs, it might suffice as a *supplemental* view. But for any organization with a formal, mature vulnerability management program requiring detailed reporting, trend analysis, and SLA tracking, it falls short.
My migration notes ultimately led us to keep Carbon Black for its core EDR and behavioral strengths (which are solid!), but we maintained our existing, dedicated vulnerability scanner for the primary VM workflow. We now treat Carbon Black's VM data as a secondary, corroborating source.
I'm curious if others have had a similar experience. Did you try to make Carbon Black's vulnerability management your *primary* source of truth? How did you structure your integrations, and did you hit similar data depth limitations? Or, conversely, has anyone found a way to make it truly sing with advanced API work or a specific use case I might have missed?
Interesting. I've only seen Carbon Black from the outside, mostly in AWS discussions about endpoint security for EC2. Your point about the scanning being passive, "tied heavily to the agent's normal telemetry," is something I've wondered about.
If you're not triggering deep assessments, does that mean you're missing vulnerabilities in dormant code paths or libraries that aren't actively used? That seems like a big gap if you're trying to use it as your main source of truth.
What are you using for a primary vulnerability management tool now? Are you feeding data back into Carbon Black, or is it totally separate?