Vulnerability Research

CVSS Is Broken. Here's What We Use Instead.

Legacy scanners match version numbers to CVE IDs. We need to talk about why that's not enough — and what actually works.

Marcus Webb, VP of Security Research
Marcus Webb
VP of Security Research
Jan 14, 2025 11 min read
Abstract visualization of context-aware vulnerability management and risk prioritization

It's 2:47am. Your SIEM just fired an alert. Your vulnerability scanner's last report — which took 68 hours to generate — shows CVE-2024-XXXX as Critical on 14 hosts. You open the report. It shows the CVE number, the CVSS score (9.8), and the affected package version. That's it. No context. No confirmation that the package is actually loaded. No indication of whether the service is externally reachable. You're flying blind.

This scenario plays out thousands of times a night in SOCs around the world. The fundamental architecture of modern vulnerability management is built on an assumption that made sense in 2010 but is dangerously inadequate today: the assumption that a vulnerable package version equals a vulnerable asset.

How Legacy Scanners Actually Work (and Why It's a Problem)

Most enterprise vulnerability scanners operate on a primitive version-matching paradigm. They authenticate to a host, enumerate installed packages (e.g., via dpkg or rpm), query a remote CVE database, and spit out a report based on CVSS scores.

# Typical Legacy Scanner Output
CRITICAL: CVE-2023-38545
Asset: prod-api-04
CVSS: 9.8
Package: curl 7.81.0-1ubuntu1.13
Remediation: Update to curl 7.81.0-1ubuntu1.14

This output tells you what is installed, but it tells you nothing about how it is running.

It misses critical contextual questions: Is the package loaded into memory? Is the vulnerable binary in the execution path of a running service? Is that service bound to 0.0.0.0 or just 127.0.0.1? Does the vulnerable code path require authenticated access? Without this context, a scanner will confidently tell you that an isolated internal database server and your public-facing API gateway carry the exact same risk profile.

What Context-Aware Assessment Actually Means

Context-aware assessment abandons the "version matching" paradigm in favor of "state evaluation." Instead of asking what is installed, it asks what is executing, who is executing it, and who can reach it.

If a severe vulnerability exists in a specific Apache module, a context-aware system doesn't just check the Apache version. It reads httpd.conf to see if the module is loaded. It checks the running process tree to ensure Apache is active. It inspects network sockets to see if the port is open to the internet.

Want to see context-aware assessment in action?

Stop managing false positives. Let our AI read your configs.

The Osquery Telemetry Advantage

To achieve context awareness, you need extreme visibility into the operating system without the overhead of heavy proprietary agents. This is where Osquery comes in. Osquery exposes the operating system as a high-performance relational database.

Instead of running a bash script to parse outputs, you can query the exact state of the machine in milliseconds. Here is what a contextual query looks like when determining if a listening process is actually exposed:

SELECT
p.name, p.pid, p.cmdline, lp.port, lp.address, u.username
FROM processes p
JOIN listening_ports lp ON p.pid = lp.pid
JOIN users u ON p.uid = u.uid
WHERE lp.address != '127.0.0.1'
AND lp.port IN (SELECT port FROM listening_ports WHERE port < 1024);

This single query reveals what legacy scanners cannot: exactly which privileged processes are listening on external interfaces. It turns theoretical vulnerabilities into deterministic, actionable risk profiles.

How AI Changes the Equation

Collecting deep telemetry is only half the solution; analyzing it at enterprise scale is the hard part. This is where modern LLMs — specifically Google's Vertex AI — revolutionize the workflow.

At Artemes AI, we use a principle called "Zero Hallucination." The AI is not allowed to guess. It is fed deterministic telemetry from Osquery (the running state) and raw configuration files. The AI's job is purely to correlate. It reads the CVE specification, reads your actual nginx.conf, and makes a binary determination: "Is this specific vulnerable execution path physically reachable in this specific environment?"

Practical Implications for Your SecOps Team

When you switch from version-matching to context-aware assessment, the impact on the engineering team is immediate. Triage time drops precipitously. Alert fatigue vanishes because every alert generated is deterministic.

"We went from 847 findings on a Tuesday morning to 12 actionable ones. We closed all 12 in the same sprint because the system provided the exact bash commands to fix them."

Security engineering shifts from a reactive posture of arguing with developers over false positives to a proactive posture of hardening architecture.

Conclusion

The era of PDF vulnerability reports filled with thousands of unverified CVEs is over. The technology now exists to interrogate the live state of your infrastructure, correlate it autonomously, and generate exact remediation code.

If this resonates with how you think about vulnerability management, Artemes AI is currently accepting early access partners. Let's stop triaging noise and start fixing actual vulnerabilities.

Marcus Webb, VP of Security Research

Marcus Webb

VP of Security Research

12 years in offensive security and vulnerability research. Former red team lead for global financial institutions. Marcus runs the adversarial testing function at Artemes AI, ensuring the AI engine never hallucinates.

CVSS
Risk Scoring
Context-Aware Scanning
Found this useful? Share it.