That makes a lot of sense, thanks for the clear breakdown! So VulnDB is like the list of all possible dangers, and Mandiant is more like a spotlight showing which ones are actually moving towards your door right now.
But, maybe a dumb question - if Mandiant is about knowing *which* of my exposed servers is being targeted, doesn't my own vulnerability scanner already tell me what's exposed? Or is the key part that Mandiant knows about attacker activity before a scan would even find an exploit?
CloudNewbie
Your "phone book" analogy is close, but it's not about competitors. It's about actual attacker infrastructure they've observed targeting your specific tech stack.
Your scanner knows what's exposed. Mandiant knows which exposed assets are being actively hunted by groups using that exact vulnerability. That's the shift from "it's on the internet" to "it's in the crosshairs."
The problem is turning that "crosshairs" data into an action. If your scanner and ticketing system don't ingest that intel feed, you're just patching the noisy CVEs while the targeted one sits in a PDF report.
slow pipelines make me cranky
You've identified the core operational failure mode that plagues threat intel implementations. That perfect handoff between intelligence consumers and patch teams is the exception, not the rule.
The issue is architectural, not just organizational. The dashboard data lives in a different trust domain, often with different access controls, than the ticketing system the sysadmin uses. The sysadmin's workflow is optimized for volume throughput from a single source of truth, which is rarely the threat intel platform.
The fix isn't better reports, it's engineering the intel feed directly into the vulnerability management pipeline. That means mandating API integrations that push annotated findings into the same queue the sysadmin is already working. If it doesn't land in Jira or ServiceNow with the "active exploitation" tag, it functionally doesn't exist for the patching workflow.
Boring is beautiful
You're describing a sample bias as a feature, but call it "curated, high-signal." That's a generous spin.
If their client base is skewed toward mature, high-value targets, what's the intel worth for a mid-sized SaaS shop on a modern stack? You're paying a premium for a dataset that might tell you how banks are being attacked, while the next Log4j is hammering your entirely different tech stack.
It's not just about understanding the bias, it's about whether that bias renders the intel irrelevant for your specific threat model. A "known quantity" can still be the wrong quantity.
That's a really good point about bias. Maybe the value for a smaller shop isn't the specific bank-targeting malware, but seeing what *kind* of assets or services those groups go after first. If they're all going after a specific cloud misconfiguration that we also have, that's the signal.
But you're right, if your stack is totally different (like, all serverless vs. on-prem VMware), the intel might miss the mark completely. It feels like you'd need to know how your own setup overlaps with their data sources before buying in.