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 us, 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.

ProGet Vulnerability Central (PGVC)

PGVC is available as a preview feature in ProGet 2022.20.

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.

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.

Vulnerability Blocking Rules

Vulnerability blocking rules allow you to restrict the use of packages with known vulnerabilities. When ProGet identifies a package with a known vulnerability, an authorized user creates a vulnerability assessment that determines whether the package should be blocked.

ProGet can also automatically assess vulnerabilities based on a CVSS score.

Third Party Vulnerability Sources

In addition to PGVC, ProGet also supports the use of third-party vulnerability sources such as OSSIndex. 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.

Feeds & Download Blocking

After you set up a vulnerability source in ProGet, you can select which feeds you want to configure for vulnerability scanning and blocking by navigating to Reporting & SCA > Vulnerabilities:

When a feed is scanned from a vulnerability source, ProGet displays information about vulnerabilities in packages and can be configured to block downloads.

Assessing Vulnerabilities

Both the manual and OSS index workflows use vulnerability reports, which essentially state that a particular package or version range of packages has a known vulnerability. This record is either manually entered or imported from OSS Index based on the packages in a given feed.

For container reports, Clair attempts to determine which operating system (OS) was used to create a container image, and then uses this OS to check specific security databases for vulnerabilities. These vulnerabilities are then automatically associated with the affected layer of the container in the registry that Clair has configured to scan. Manual vulnerability entries can also be added to affected container layers by specifying the digest of the layer.

All newly entered or imported vulnerability reports are considered unassessed, which means that packages matching the vulnerability are blocked until the report is assessed. When an assessment is made, an authorized user reviews the report, selects an assessment type ( Ignore, Caution, Block ), and leaves an optional comment.

Assessment Expiry

An "assessment" you make for a vulnerability in a package or container image can be configured to expire. This means that when it expires, the vulnerability report is considered "unassessed" unless it's reassessed.

There are two main use cases for expiration.

• If you allow downloading packages or container images with unassessed vulnerabilities, it means that you can use an expiring assessment to temporarily block a package.
• If you block unrated vulnerabilities, it means that you can use an expiring assessment to temporarily unblock a package.

The reason for temporarily blocking or unblocking packages is due to the nature of security vulnerabilities. Just because a particular package or container image has a security vulnerability doesn't mean your application will use the vulnerable aspects. In fact, constantly switching to newer versions just to avoid reported vulnerabilities is often less secure - the newer versions have unknown vulnerabilities that you might exploit.

If you temporarily release packages and container images, you can periodically check how developers are using them. The usage might have changed.

Blocking a Package Download

Selecting Blocked prevents any packages within the version range or container images that contain the vulnerable layer from being downloaded. On the Vulnerabilities page or on the Vulnerabilities tab on the package or container image page, select the vulnerability, then Assess, and choose Blocked, optionally adding a comment.

When you access a package version within the specified range or a container image with an associated layer of the blocked vulnerability, Blocked is displayed where the download button would normally be located, and the package or container image cannot be downloaded through the associated feed API.

Note: The package version or container image is blocked for download, but may still appear in the search or list results.

Assessment Types

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 or create your own assessment type by going to 'Admin > Assessment Types' and specifying a name, expiration (days), color, whether or not to block packages, and an area for automatic assessment.

Automatically Assess Vulnerabilities

ProGet can automatically assess new vulnerabilities based on a vulnerability's CVE score. You can configure this by simply creating or editing the auto-assessment range on an assessment type.

Note that auto-assessment only applies to new vulnerabilities; if an assessment expires, it will not be automatically re-assessed.

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.

ProGet 2022 and Earlier

Projects and Releases, as well as vulnerability notifications are only available in ProGet 2022 and later.

ProGet Vulnerability Central (PGVC) is only available in ProGet 2022.20 and later.

The ability to Automatically Assess Vulnerabilities is only available in ProGet 6.0 and later.

In ProGet 6.0 and earlier, vulnerability sources were configured on the main Vulnerabilities tab and then on the Detection and Blocking tab of each feed.