Overview

When working with open-source dependencies in ProGet, vulnerabilities are surfaced alongside severity scores, often appearing as high or critical. The challenge isn’t identifying these issues, but understanding what they actually mean in the context of your applications.

Not every vulnerability represents real risk. A flaw only matters when it can be exploited in a way that impacts your system. Without this context, teams tend to treat all vulnerabilities as urgent, leading to blind upgrades and unnecessary regressions.

Vulnerability Management Done Right with ProGet focuses on closing this gap by helping teams understand vulnerability data more effectively and shift the focus from:

❌ “How severe is this?”

to:

✔ “Does this actually matter, and what should we do about it?”

Vulnerabilities vs. Exploits

A vulnerability is an unintentional flaw in software, typically introduced through a coding mistake or design oversight. It’s an unintended byproduct of building complex systems rather than malicious code. Think of it like a poorly designed lock: the weakness is there regardless of whether anyone tries to exploit it. Vulnerabilities are simply potential problems, not active threats. Yet teams often treat them like viruses or malware even though they’re fundamentally different. A virus is intentionally harmful software designed to exploit weakness, more like a thief trying to break in.

A vulnerability only becomes a real risk when an attacker is able to exploit it to cause harm. Context matters: a weak lock on a front door poses far more risk than the same lock on a filing cabinet inside a locked office.

In practice, many teams rely on tools like repository scanners or automated dependency updates. These tools prioritize detection over understanding, flooding teams with alerts tied to severity scores that are based on hypothetical worst-case scenarios. In response, organizations introduce stricter controls, like manually curated package feeds or blocking vulnerable dependencies, which make development more difficult without actually reducing risk. Even remediation can backfire, since upgrades can introduce regressions that pose more risk than the vulnerability itself.

The alternative is to prioritize what’s realistically exploitable over what’s theoretically severe. A severity score can tell you how bad a vulnerability could be in a worst-case scenario, but not whether it poses a real threat to your applications. Answering that question, and knowing how to respond once you have, is what drives everything in this guide.

Managing Vulnerabilities Proactively 

This guide helps teams move from reactive vulnerability management to a structured approach based on real-world risk. Each article covers one part of that approach:

Prioritizing Vulnerabilities 

What are PVRS & PVRS Categories?: How ProGet helps you determine what to fix, and when to fix it.  

Comparing PVRS vs CVSS: Why severity scores fall short for OSS libraries and how to prioritize vulnerabilities based on actual risk, not worst-case scenarios.   

Responding to Critical Vulnerabilities 

Preparing for a Category 5 Vulnerability: How to prepare for and respond to the most critical vulnerabilities that require immediate action.   

Containing and Customizing 

Blocking & Containing Vulnerable Packages: Why blocking vulnerable packages isn’t enough and how a containment-based approach better addresses real-world exposure.  

How to Assess: Monitor, Remediate, Contain: How ProGet’s assessment types offer guidance to respond appropriately based on risk.   

Overriding Assessments & Default Behavior: How to override or customize vulnerability assessments to your environment so remediation guidance reflects how your applications actually use dependencies.  

Together, these concepts form a practical framework for prioritizing vulnerabilities, reducing unnecessary disruption, and responding with confidence.

Applying Context at Scale

A better approach to vulnerability management considers how software is used, your attack surface, and what an attack could realistically do. That’s easy enough to apply to a single vulnerability, but it raises an obvious question: how do you apply that reasoning consistently across the hundreds of open-source dependencies your applications rely on? PVRS categories address this by adding real-world context to CVSS scores, so you can see which vulnerabilities need attention without assessing each one individually. 

New to PVRS? Start with PVRS Categories to learn what ProGet’s categories mean and how they’re assigned.