Vulnerability Scanning & Assessment

ProGet can identify vulnerabilities in open-source packages, assess the exploitation risk in your environment, and help you decide which actions to take and when. This lets you monitor vulnerabilities across your CI/CD pipeline and production environments, and optionally block risky packages from being downloaded.

This article explains how vulnerability detection works and how you can configure blocking rules and assessments when a package is found to be vulnerable.

Package Vulnerabilities

When a package has a vulnerability, you'll see a message on the overview page indicating the risk posed.

You can also see all vulnerabilities detected in packages under the SCA & Reporting tab.

Clicking on an entry will provide technical details about the vulnerability itself, the impacted packages and builds, and context-specific assessments with recommended action.

Blocking Vulnerable Packages

If you have a paid version of ProGet, you'll scan and block packages so that packages like this can't be used as well as assess vulnerabilities and comment as to why they're severe or okay for your organization.

Blocking Downloads

You can also block downloads of the package file itself by navigating to Feed > Policies & Blocking.

When enabled on a feed, users will not be able to download blocked packages from the UI or use the API. Attempts to download the package from the API will result in a 404 error when:

• A vulnerability was assessed as severe enough to prevent downloads
• The vulnerability is unassessed, and you enabled the "block unassessed" rule on the feed

Container Vulnerabilities

To scan containers for vulnerabilities, ProGet extracts and inspect the files within each container image layer and looks for vulnerable packages that are installed. The "Packages" and "Vulnerabilities" tab of a container image will show these:

Vulnerability Assessments

ProGet automatically assesses vulnerabilities with an assessment type that's intended to indicate the recommended response:

• Monitor: No immediate action is required. In previous versions of ProGet, this was labeled as "Ignore".
• Remediate: Plan to address the vulnerability in a scheduled release. This used to appear in ProGet as "Caution".
• Contain: Investigate the impact of the vulnerability and address as soon as reasonable. This used to appear as "Blocked".

See Understanding ProGet's Three Assessment Types to learn more about these responses.

Overriding Assessments

Even though your organization's risk profile is to assess vulnerabilities, you may wish to override the automatic assessments based on how your applications are used, and the real-world impact of the vulnerability in your environment.

Note that this functionality is limited to paid editions of ProGet. See Overriding Assessments & Default Behavior to learn more.

Creating Your Own Assessment Types

You can create your own assessment types or edit the built-in ones. This isn't appropriate for most organizations, but it can be helpful if you need to adding more granular types (such as ones that map to all five PVRS categories), or if you wish to implement a manual review for severe vulnerabilities instead of auto assessing them as "Contain".

To create a custom assessment type, navigate to "Administration" > "Vulnerabilities & Assessment Types" and select "Create Custom Assessment Type".

There are several options to consider when creating types:

• Apply to allows you to use PVRS Category or CVSS Scores to determine assessments
• Default expiry will cause the assessment to be considered "unassessed" after that many days, and unassessed vulnerabilities are considered Noncompliant by default
• Emitted severity controls whether or not vulnerabilities are emitted as part of the API and how default policy behavior in ProGet.

Malicious Packages

ProGet will also detect and automatically block known Malicious Packages.

Unlike a package with unintentional vulnerabilities (defects) that may open your applications to security exploits if used in a certain way, a malicious package is always unsafe to use because it was intentionally crafted to cause harm. As such, this blocking is automatic and cannot be configured.

In the unlikely event you need to override this behavior, you will need to:

1. Acquire a copy of the package file
2. Publish it to the feed
3. Set the Package Status to "Always Allow Download"

Malicious Package Database

ProGet is installed with a malicious package database that contains the names/versions of hundreds of thousands of known packages.

By default, this database is updated on a nightly basis by downloading an update from Inedo Security Labs. You can see the status of the database under Admin > Vulnerabilities & Assessment Types > Databases

Malicious Packages & Compliance

A malicious package is always considered noncompliant. In the unlikely event you'd want to override this behavior, you can work-around this behavior by publish a copy of the package to a feed and setting the Package Status to "Always Allow Download".

This means that:

• if a malicious package is included in a Build, the build will always be considered noncompliant
• if a malicious package is found in a feed, it will trigger notifiers as appropriate

ProGet 2025 and earlier

As the security and vulnerability management practices evolved over the years, so has ProGet. While earlier versions of ProGet will behave differently than what's documented here, the functionality and workflows remain conceptually similar.

See the archived documentation (github.com) to understand how earlier versions functioned, as well as the ProGet 2026 Upgrade Notes to learn what changed recently.