Note: This preview of “Vulnerability Management Done Right with ProGet” reflects features and functionality planned for the upcoming ProGet 2026 release.

How PVRS Adds Context to CVSS for OSS Vulnerabilities

When reviewing OSS vulnerabilities in ProGet, CVSS scores are often the default guide for deciding what to do next. Vulnerabilities rated 8.0 or higher typically trigger immediate action: upgrade the dependency, block the package, or delay production approval, while lower-severity issues are often deferred or ignored. This makes sense when a vulnerability affects an exposed system that an attacker can directly interact with. But it makes less sense when the issue exists in an OSS library far removed from user input within an application. 

Treating all vulnerabilities this way leads to unnecessary upgrades, alert fatigue, and difficulty distinguishing real-world impact from theoretical risk. When everything is severe, nothing truly is. It’s not that CVSS is broken; it’s actually working exactly as designed. The issue is that it’s often misused as a prioritization tool. 

This chapter looks at why that gap exists and why PVRS is a better fit than CVSS for prioritizing fixes in open-source dependencies. PVRS approaches vulnerability prioritization through three contrasts: severity vs. risk, systems vs. libraries, and analysis vs. Action, shifting the focus from what could happen to what’s likely, and what needs attention first. 

Looking at Vulnerabilities Through the Right Lens 

Teams rely on CVSS scores to decide how urgently to remediate a vulnerability, using them to answer a question they weren’t designed for: “What should I do about this vulnerability?” Ignoring a “Critical” vulnerability feels irresponsible, and few teams have the time to deeply analyze every finding. CVSS does what it’s designed to do: describe worst-case severity in a consistent way across all software. Developers, however, must decide how urgently to act within their own environment; especially when the vulnerability resides in an OSS library rather than an exposed system.

This is the gap PVRS is designed to fill: it does not replace CVSS, but augments it by helping with the part that CVSS intentionally leaves out: risk analysis. This mismatch becomes clearer when viewed through three related lenses that separate what CVSS provides from what PVRS adds: 

1. Severity vs. Risk: CVSS measures theoretical damage while PVRS evaluates the likelihood of real-world exploitation

2. Systems vs. Libraries: CVSS treats all software as equally exposed, while PVRS accounts for how dependencies are actually used. 

3. Analysis vs. Action: CVSS offers objective scoring while PVRS focuses on guiding remediation decisions. 

These are not separate mismatches, rather perspectives on the same underlying issue: CVSS answers a very different question than the one that developers need answering: “How much damage could this cause in a worst case under ideal circumstances?” Developers, on the other hand, need to answer: “What’s the likelihood of exploitation and how urgently do I need to fix this?” 

Looking at each difference in more detail makes it clear how PVRS augments CVSS by answering the questions that CVSS leaves unanswered. This means teams can continue to use CVSS for what it does well, while using PVRS to perform the risk analysis that CVSS isn’t designed to offer. 

1. Severity vs Risk 

CVSS models severity, estimating the theoretical damage a vulnerability could cause if it were exploited under ideal conditions. It relies on a detailed formula defined in a specification spanning roughly 30–40 pages, evaluating factors such as impact to Confidentiality, Integrity, and Availability, along with characteristics of the attack like required privileges, complexity, and attack vector. 

What CVSS does not attempt to model is risk: how likely a vulnerability is to be exploited in a specific environment, if the necessary preconditions exist, or if exploitation would cause harm in that context. It also ignores cost and impact of remediation, and omits the environmental context required to assess it. This is by design: CVSS prioritizes global comparability over application-specific accuracy. 

Where PVRS Comes In 

PVRS performs the risk analysis teams still need after reading a CVSS score. It delivers environment-specific and usage-specific insight into how a vulnerability applies in real-world conditions, including how the software is actually used and how urgently the issue needs to be addressed. This connects vulnerability data to practical decision-making, helping you understand whether it’s likely to matter in your environment and how quickly you need to act. 

2. Systems vs Libraries 

CVSS models vulnerabilities across all types of software. This could be a complete system, such as an operating system or application, or a library used as a component within another system. From CVSS’s perspective, these are all pieces of software with vulnerabilities that could be exploited. In practice, however, systems and libraries have very different risk profiles. 

A vulnerability in a user-facing system is often exploitable by default. The system is directly exposed to user input, network traffic, or attacker interaction. A vulnerability in a library, on the other hand, is not exploitable by default. Exploitation usually depends on how the application uses that library, what data it passes to it, and whether that data can be influenced by an untrusted party. Imagine a vulnerability that allows arbitrary code execution when opening a malicious PDF: 

• System (e.g. Desktop PDF reader): As severe as it sounds. An attacker can email a crafted document to a user who then opens it, unaware of the risk. The results could range from installing keyloggers to stealing data or spreading access to other systems. Both technical severity and real-world risk are extremely high. 

• Library (e.g. Server-side PDF library): Only exploitable if the application parses PDFs supplied by untrusted users. Many applications use PDF libraries just to generate documents, not to read them. Even when parsing is enabled, inputs often come from trusted internal sources rather than random internet users. The vulnerability is severe in theory, but in many real situations it is not an immediate emergency. 

Where PVRS Comes In 

PVRS looks at how libraries are actually used in practice, analyzing risk based on realistic usage patterns rather than worst-case assumptions. This distinguishes between vulnerabilities that are theoretically severe and those that are meaningfully exploitable. Now, issues that truly require immediate remediation can be clearly identified and prioritized over those that don’t. This contextual risk reasoning is what teams attempt to do when reading CVSS scores, and often get wrong. 

3. Analysis vs Action 

Development teams will ultimately need to decide what to fix first. With only severity as guidance, they often translate this into priority. “High” or “Critical” scores become “fix now,” while lower scores are deferred or even ignored. Since many OSS vulnerabilities get High or Critical scores based on worst-case theoretical impact, developers end up with a blanket rule of “upgrade immediately”. Teams end up reacting to scores and wasting time on issues that pose no risk. 

CVSS provides an objective analysis of vulnerabilities that can be applied across all software. It focuses on describing the characteristics and potential impact of a vulnerability, without going into what should be done about it. Decisions about how and when to remediate are left to whoever is in charge. 

Where PVRS Comes In 

PVRS converts CVSS information into context-aware categories. It focuses on remediation and offers guidance on how urgently a vulnerability should be addressed based on context and real-world risk. 

This translates vulnerability data into clear actions and urgency, establishing meaningful prioritization instead of treating all severity scores the same. 

Making Vulnerability Scores Actionable 

CVSS is valuable for consistently describing worst-case vulnerability severity across software. Problems arise when its score is used to dictate urgency, especially for OSS libraries. Severity shows how bad something could be, not how likely it is to matter in a specific environment, how exposed the code is, or how much effort remediation warrants.

PVRS complements CVSS by adding that missing context. By focusing on real-world risk, library usage, and action, it helps teams turn vulnerability data into clear priorities. Used together, CVSS and PVRS show both how severe a vulnerability could be and how urgently it needs attention.

Understanding how PVRS adds context to CVSS helps clarify how vulnerabilities are prioritized, but it also raises an important question: what happens when something truly urgent appears? This is covered in our next chapter about surviving Category 5 vulnerabilities.