Generic Triage Doesn’t Work. Contextual Triage Does.

When alerts pile up, so do false priorities

In dozens of conversations with AppSec and development teams, the pattern is always the same.

Overwhelmed by alert volumes, teams fall back on the only available metric to sort them: severity scores.

It’s understandable. With hundreds or thousands of findings across dozens of applications, you need a starting point. Severity scores seem like a logical one.

But quickly, reality hits:

• Many “High” or “Critical” issues aren’t real threats.
• False positives eat up hours of developer time.
• And worse: actual security risks are left unaddressed, piling up as silent, invisible technical debt.

A debt that only grows over time—and becomes exponentially harder to resolve.

How did we end up here?

With an approach that treats all alerts the same, regardless of how (or if) they apply to your context: generic triage.

It’s time for something smarter.

The false promise of severity scores

Severity scores like CVSS (Common Vulnerability Scoring System) were built to offer a standard way to evaluate vulnerabilities. They look at:

• Technical impact (e.g., data confidentiality, system availability)
• Complexity of the attack
• Required privileges or user interaction

For example, the infamous Log4Shell (CVE-2021-44228) received a CVSS score of 10.0, the maximum possible—because it allows remote code execution without authentication.

But CVSS scores are generic by nature: they describe how dangerous a vulnerability can be, not whether it applies to your specific application.

To refine this, teams dealing with known vulnerabilities in open-source dependencies often combine CVSS with:

• KEV (Known Exploited Vulnerabilities) lists, such as those from CISA, to identify vulnerabilities currently exploited in the wild.
• EPSS (Exploit Prediction Scoring System), which uses data models to estimate the probability that a vulnerability will be exploited in the near future.

While this improves prioritization for dependency-related issues, it still leaves major gaps:

• It doesn’t account for whether the vulnerable code is reachable from your app.
• It ignores whether the issue is executed at runtime.
• It lacks visibility into whether the component is deployed in production or simply present in your build.

In other words, even with CVSS + KEV + EPSS, you still lack context.

That’s where the real prioritization should begin.

Why context changes everything

Let’s look at three cases, all flagged as High severity by traditional scanners—but with very different real-world implications.

Case 1: The real vulnerability

A deserialization flaw exists in a payment processing microservice. It’s exposed to the internet, reachable through user actions, and handles sensitive financial transactions.

→ This is a critical, real risk that must be addressed immediately.

Case 2: The ghost vulnerability

A transitive dependency includes a vulnerable function, flagged in a public CVE. But in your codebase, the function is never called, and the package is only used for internal dev tooling.

→ High severity score, but zero reachability and no business impact. This is noise.

Case 3: The false positive

A scanner detects a potential SQL injection in a search bar. In one application, user input is properly sanitized before reaching the database — no injection is possible. In another, the same function lacks input sanitization — making it a real vulnerability.

→ The exact same alert is raised in both cases. Only one of them is exploitable.

Generic triage can’t tell the difference. It treats all three issues as equal.

Contextual triage distinguishes between them—helping you focus on what’s real, and ignore what’s not.

How Glev brings context into triage

Glev’s contextual triage engine goes beyond severity by evaluating each alert through five real-world dimensions:

1. Reachability – Is the vulnerable code actually invoked in your application flow?
2. Exploitability – Is there a known exploit in the wild? Is it being actively targeted?
3. Business Impact – Does this vulnerability touch sensitive data or mission-critical logic?
4. Environmental Context – Is the issue present in production? Is it externally exposed?
5. Dependency Mapping – Is the issue in a direct dependency, or deeply nested and unused?

This lets us:

• Remove up to 95% of false positives
• Reprioritize alerts based on actual risk in your environment
• Help your teams focus on what matters, instead of chasing ghosts

Context is not a luxury—it’s a requirement

The future of AppSec isn’t just more scanning. It’s smarter remediation.

And remediation starts with understanding what truly matters.

Contextual triage helps you:

• Allocate developer time where it creates real impact
• Avoid alert fatigue and security friction
• Reduce the invisible security debt that generic triage hides

With Glev, you move from being alert-driven to being risk-driven.

And that’s what unlocks real security at the speed of development.

Let's finish with a little game to test your AppSec skills. Among the 4 following issues, could you tell which you should fix?