ProGet Documentation

Vulnerability Scanning and Blocking

When you incorporate third-party, open-source packages into your applications, you also incorporate those packages' security vulnerabilities.

Fortunately, security researchers are constantly inspecting these packages and publishing vulnerabilities they find in public security databases, such as the National Vulnerability Database. This allows both package authors and consumers to fix and patch as needed.

Unfortunately, managing vulnerabilities as a consumer is challenging, especially as an enterprise. Even if you were to carefully assess each third-party package for known vulnerabilities before allowing its use in applications, new security vulnerabilities are discovered all the time. This means you would need to constantly reassess all third-party packages for new security vulnerabilities.

This is where ProGet's vulnerability scanning and blocking comes in. We partner with two leading vulnerability scanning companies – Sona (Vor Security) and WhiteSource – to automatically scan third-party packages against vulnerability databases. You can also manually manage your vulnerabilities.

Vulnerability Scanning and Blocking Workflows

ProGet supports three different workflows for managing vulnerabilities

Manual Vor Security WhiteSource
Cost - $ $$$
Thoroughness * *** *****
Block vulnerable packages
Manually enter vulnerability reports - -
Assess vulnerability report within ProGet -
Automatically scan public databases -
Scan proprietary databases - -
Requires subscription - Sign Up Sign Up

See Integrating ProGet with Vor Security and Integrating ProGet with WhiteSource documentation for more details on those workflows.

Feeds and Vulnerability Configuration

A feed must be explicitly configured to use vulnerability scanning and blocking. While the end result is the same, the workflows use different features within ProGet:

  • Vulnerability sources are used for manually-and Vor Security- managed workflows; these add vulnerability records into ProGet which you must assess
  • Package access rules are used for WhiteSource-managed workflows; these block package downloads based on rules configured in WhiteSource

You can configure both on the Manage Feed page. If you don't see Vor Security as a vulnerability source, or WhiteSource as a package access rule, check Admin > Extensions to make sure those extensions are installed.

Vulnerability Reports and Assessments in ProGet

Both the manual and Vor Security workflows use vulnerability reports, which essentially identify that a particular package, or versioned range of packages, has a known vulnerability. This record is either manually entered, or is imported from Vor Security, based on packages in a particular feed.

All newly entered or imported vulnerability reports are considered unassessed, which means that packages matching the vulnerability will be blocked until the report is assessed. An assessment involves an authorized user reviewing the report, choosing an assessment type (Ignore, Caution, Block), and leaving an optional comment.

Assessment workflow

Assessment Expiry

Depending on the assessment type, the assessment may expire; this means that, unless it's reassessed, the vulnerability report will be considered unassessed after expiry.

This can be useful to temporarily allow a package, or to review usage of packages after a certain amount of time.

Custom Assessment Types

ProGet comes with three built-in assessment types:

  • Ignore; indicates that the vulnerability report is not applicable or irrelevant, and therefore allows for packages to be downloaded
  • Caution; developers should be careful to avoid the vulnerability; packages may be downloaded, but a warning is issued on the web ui
  • Blocked; vulnerability is too severe to allow use, and packages are prevented from being downloaded

You can edit or create your own assessment type, specifying a name, expiry date, severity (color), and whether or not packages would be blocked.