Vulnerability Scanning & Blocking

ProGet can automatically scan third-party open-source packages and container images for vulnerabilities, allowing you to assess the risk they may pose. This allows you to not only block packages or container images that you deem too risky for use, but also determine which of your Projects and Releases are affected by security vulnerabilities. You can also warn users about security vulnerabilities and receive alerts when new vulnerabilities are discovered.

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

Package Vulnerabilities

When the "vulnerability detection" feature is enabled on your feed, a "Vulnerabilities" tab will appear on packages and list the known vulnerabilities that were detected. Clicking on a vulnerability will provide information about the severity, reproduction details, remediation steps, and so on.

If you’ve enabled the built-in ProGet Vulnerability Central (PGVC), known vulnerabilities will be shown on all packages, even ones you haven't downloaded yet. However, if you're using a third-party source (such as OSS Index), packages will need to be downloaded first (i.e. cached or pulled to the feed) and an overnight vulnerability scan must happen.

When a package has a severe vulnerability, you’ll see this message on the overview page:

Blocking Vulnerable packages

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

Package blocking is configured on a feed-by-feed basis under SCA & Reporting > Vulnerabilities. When enabled on a feed, users will not be able to download blocked packages from the UI or using the API.

Attempts to download the package from the API will result in a "404" error.

A package will be blocked 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.

Assessing Vulnerabilities

Many vulnerabilities – even severe ones – will not have an impact on your applications.
For example, consider the vulnerability on the Newtonsoft.Json package in the screenshots above: Improper Handling of Exceptional Conditions in Newtonsoft.Json.

If you read the details of the vulnerability, you’ll see that applications that use that version of the package will be susceptible to a Denial of Attack if a malicious user is able to send a massive (9.5MB+) JSON request to an API.

For public-facing applications, that’s a pretty big deal – and an anonymous hacker could quickly disrupt your service. But for internal-use applications, these attacks are highly unlikely. And not only that, you can easily bypass the vulnerability by checking the size of the JSON request, setting a recursion limit in the Newtonsoft configuration, etc.

This is where vulnerability assessments come in: authorized users can assess these vulnerabilities, select an assessment type (Ignore, Caution, Block, etc.), and leave an optional comment explaining the decision.

Assessment Types & Expiry

ProGet has three built-in assessment types:

• Ignore indicates that the vulnerability report is not applicable or irrelevant and therefore allows packages to be downloaded
• Caution tells developers to be careful to avoid the vulnerability; packages can be downloaded, but a warning is issued on the web UI
• Blocked means that a vulnerability is too severe to allow use and packages cannot be downloaded

You can edit these types or create your own by going to "Admin Overview" > "Assessment Types" and clicking on "Create Assessment Type" to specify a name, expiration (days), color, whether or not to block packages, and an area for automatic assessment.

Auto assessment can be customized to your preferences, however if you’re unsure of what the best option is; we recommend the following auto assessment setup:

This configuration will ignore low score vulnerabilities that typically will not impact your security while critical vulnerabilities are immediately blocked for download.

Medium score vulnerabilities will be left unassessed in this case because these vulnerabilities should be reviewed by someone to determine if they are ignored, require caution, or—in rare cases—should be blocked. These medium score vulnerabilities do not typically require immediate action.

High score vulnerabilities are not blocked in this scenario—but should be treated with caution because they typically have a security flaw in a specific feature of the package, but may not be a feature that your application is leveraging.

Assessment Scores

Most vulnerabilities will have a simple "score" that rates the severity on a scale of 0.1 to 10.0 using a variety of factors. You can automatically assess vulnerabilities based on this score to either:

• Ignore or warn about low-score vulnerabilities
• Block high-score vulnerabilities

Note that when you configure this field on an assessment type, it will only apply to new, unassessed vulnerabilities. Auto-assessment rules will also not be applied to vulnerabilities with an expired assessment.

Blocked Packages

When this option is selected, packages that have vulnerabilities that were assessed with this assessment type will be blocked. By default, the "Blocked" assessment type will block packages.

You can either click on each vulnerability and assess them individually, bulk edit, or auto assess. We recommend using the auto assess feature so you can automate as much of the process as possible. The next step will show how to customize auto assessment and best practices.

Custom Vulnerability types

Creating and using custom vulnerability types can be very helpful when:

• You want different vulnerability expirations
• You want to tag vulnerabilities that may be treated or reviewed differently

For example: Let's say you want an auto assessment for high (7.0-8.9) to not block, but they require a critical review. To accomplish this, you could create a "Critical Review" assessment type that auto-assesses when a high vulnerability is located. Then a security admin can filter these on the Vulnerabilities page in ProGet to do critical reviews.

Expiry

:::(warning)Assessment types can be configured to expire, and the built-in types will expire in 90 days by default.:::

When an assessment expires, the vulnerability will be considered "unassessed" and may cause the package to be blocked or allowed, depending on whether unassessed vulnerabilities downloads are permitted on the feed.

This is primarily useful to temporarily allow packages. For example, you could temporarily allow Newtonsoft.Json 12.0.3 for 90 days by assessing it as "Caution"; once the assessment expires (and the feed is configured to block unassessed packages), the package will no longer be downloadable.

If you edit or remove the expiry rule on an assessment type, it will apply immediately to all vulnerabilities assessed with that type. This means that, depending on when the vulnerability was assessed, it may immediately expire or be valid.

Manual Vulnerability Records

You can also add a manual vulnerability record on a specific package version (or version ranges), or on a container image layer. You may wish to do this if you discover a vulnerability that isn't yet publicly disclosed.

To add manual records, navigate to the Vulnerabilities tab on the package or container image page then click the Add Vulnerability button to specify the feed, the package ID, and version(s) or the container image layer digest, and the details of the vulnerability.

Version Ranges

Manual vulnerability records may encompass multiple package versions using version range syntax, for example:

Note: versions must be specified out to their full value to match. For example, 2.0 will not match 2.0.0

Due to the inconsistency on container repository tags, container registries are not compatible with version ranges.

Vulnerability Sources

ProGet uses "Vulnerability Sources" to scan packages. You can configure these on Admin > Vulnerability Sources, and we recommend using only one vulnerability source at a time.

ProGet Vulnerability Central (PGVC)

ProGet Vulnerability Central (PGVC) aggregates leading vulnerability databases such as GitHub Security Advisories, PyPA and Global Security Database. It's bundled as an offline database in ProGet and is used to show which open source packages have which vulnerabilities. In most cases, PGVC will be enabled by default. If you enabled OSS Index in PG 2022 or earlier, it will be disabled.

Unlike third-party vulnerability services (e.g., OSS Index) that require the use of an API or an overnight download, PGVC's vulnerability data is available immediately, even to remote packages. If ProGet can connect to the Internet, it downloads PGVC updates daily. Otherwise, PGVC data is updated every time you update ProGet.

Third Party Vulnerability Sources

In addition to PGVC, ProGet also supports the use of third-party vulnerability sources such as OSS Index. ProGet runs a recurring job to scan your local (or Connector cached) packages. Note that remote Connector packages that are not cached locally cannot be scanned using a third-party vulnerability source, since ProGet must submit a list of all packages and versions to be queried, and this information is often not available from remote sources.

Information about vulnerabilities from a third-party source is not displayed on the Vulnerabilities tab unless the package is cached or otherwise stored locally and the nightly scan job has been run.