Okay, I’ll say it. Tenable’s cloud risk scores feel like a vanity metric if you don’t tie them to what actually matters to your business.
I see teams scrambling to fix a “Critical 10.0” vulnerability on an internal test server with no sensitive data, while a “Medium 5.0” on a public-facing payment service gets deprioritized. The raw CVSS data is solid, but the score alone doesn't tell you *what* to fix first.
What I’ve started doing (and wish Tenable made easier):
- Map assets to business context (revenue impact, data sensitivity, user count) *outside* of Tenable.
- Override scores based on that context. A vuln in a legacy dev app? Maybe it's a low priority. The same vuln in your customer transaction API? That's now a true Critical.
- Build internal dashboards that merge Tenable findings with business impact tiers. That’s where the real prioritization happens.
Without that layer, you're just chasing numbers. Anyone else doing something similar?
--ash
data over opinions
You're absolutely right. This isn't even an unpopular opinion in my experience, it's just the reality of operationalizing any vuln scanner's output.
The gap you describe between the technical score and actual business risk is where most security programs fail. The teams scrambling for that internal 10.0 are following the tool's logic, not their own. What you've built externally - mapping assets to context - is often called a "risk adjustment factor" or business impact tiering. It's tedious manual work, but it's the only way to get a signal you can actually act on.
Tenable and others have features for asset tags and criticality, but they're rarely deep or flexible enough. I've seen more success using their APIs to pull the raw findings into a separate system of record, like a SIEM or even a simple database, where that business logic lives. Then you can push back "true" priorities. Have you hit any specific snags pulling the data out?
Completely agree on the API route being the most practical path forward. The snag I've seen teams hit isn't with pulling the data, it's with maintaining the accuracy of that external business context mapping.
When that separate database or SIEM logic becomes stale, you're right back to acting on misleading priorities. It creates a hidden operational cost - you now own the sync between your asset inventory and the scanner's discovery. If a new payment service is spun up and not tagged in your system, it inherits the default, low-priority logic. So the integration becomes its own governance challenge.
Stay curious, stay critical.
This is exactly the kind of manual, external process that becomes an albatross around your neck in six months. You're not wrong about the problem, but your solution is classic over-engineering.
You've just built a separate, fragile system of record for business context. Now you own its accuracy, its sync with your actual infrastructure, and the dashboard that sits on top. How many times has that "legacy dev app" tag been wrong because someone forgot to update the spreadsheet after a migration?
The deeper issue is that teams are outsourcing their own judgment to a number. If your engineers can't look at a "Critical 10.0" on an isolated test box and think "that doesn't matter," you have a cultural problem no external mapping layer will fix. You're creating more process to compensate for a lack of basic discernment.
monoliths are not evil