ProGet SBOM Scan Not Creating Vulnerability Issues for NPM Packages

_moep_

Hello ProGet Community,

I'm testing ProGet 25.0.13 with npm feeds and SBOM scans using pgutil. My goal is to trigger "Build Issues Detected" webhooks when vulnerable npm packages are detected.

Setup:

Docker-based ProGet instance, running on localhost:8888
Custom npm feed (npm-test) + npm proxy feed (npm-proxy) pointing to registry.npmjs.org
pgutil installed locally, scanning project vuln-demo
Vulnerable npm packages like qs@0.6.6 included

services:
  proget:
    image: proget.inedo.com/productimages/inedo/proget:25.0.13
    container_name: proget
    restart: unless-stopped
    ports:
      - "8888:80"
    volumes:
      - proget_packages:/var/proget/packages
      - proget_database:/var/proget/database
      - proget_backups:/var/proget/backups

volumes:
  proget_packages:
  proget_database:
  proget_backups:

Steps I took:

Created npm-test feed and published local demo packages.

Initialized npm project with vulnerable package(s):

npm init -y
npm install qs@0.6.6 lodash@4.17.23 minimist@0.0.8

Ran SBOM scan and audit via:

pgutil builds scan --source=local-api --input=package-lock.json --project-name="vuln demo" --version=1.0.0

Build shows in ProGet, SBOM published, audit runs, but no vulnerabilities are detected.
Promoted build to "Test" stage.

Problem:

Even packages known to be vulnerable (e.g., qs@0.6.6) do not produce any vulnerability issues.
As a result, the “Issues Opened on Build” webhook never fires, so my FastAPI integration never receives events.

Proxy feed exists, connector is unfiltered, but ProGet reports:

No Remote Metadata Provider was found for "pkg:npm/qs@0.6.6"
Audit/compliance logs: Warn, but Vulnerabilities: None.

Question:

How can I get ProGet to correctly identify vulnerabilities in npm packages from my SBOM scans?
Do I need additional metadata providers, connectors, or configuration for npm feeds to ensure that vulnerable packages trigger issues?

Thank you in advance for any guidance or configuration examples!

atripp

Hi @_moep_ ,

So there are quite a few "moving pieces" here.

Vulnerability -> Assessment -> Compliance -> Build Issue

Vulnerabilities & Assessments

First and foremost, when you navigate to qs@0.6.6 in the ProGet UI, you should see several vulnerabilities listed, such PGV-2287703. So, the "identification" is there as a result of the offline version of that database being included with ProGet.

But, ProGet is all about reducing noise while helping elevate real risks - and most vulnerabilities are theoretical, have no real-world exploits, would require a dedicated attacker, and would result tin no real damage.

A "Denial of Service from Prototype Pollution" is great example of such a vulnerability. The risks and problems introduced by reactively upgrading every dependency far exceed any benefits -- moreover, it "de-sensitizes" everyone to real security risks. The idea of "when everything is severe nothing is" is the same as "when everything is a priority, nothing is".

That's where Assessment comes in. In ProGet 2025 and earlier, a vulnerability is generally as "assessed" Ignored, Warn, or Blocked. PGV-2287703 will be assessed as Warn by default.

**NOTE this will be changing in ProGet 2025. **

Policies & Compliance

Next, there's the question of Compliance; the vulnerability assessment (among other things, like license, deprecation status, etc) will determines whether or not a package is Compliant, Noncompliant, or Warn.

Compliance rules are configured in policies. In ProGet 2025, by default, the "Warn" Assessment will not make a package Noncompliant. Just Warn.

Builds & Issues

A Build is considered Noncompliant if any of the packages are Noncompliant. A Noncomplaint build should be blocked from deploying to production.

This is where Issues come in: an issue may be created when a build is analyzed (try it out by clicking [analyze] in the UI) for a Noncompliant package. The purpose of these Issues are to effectively "override" the compliance status on a single package.

They are not informational; if you want a list of packages, vulnerabilities, licenses, just use pgutil builds audit to get that listing.

Long story short, I'd decide on a process you'd want to use before even considering web hooks for all this.

Also note that this mostly requires a paid license, so you may not even be getting functionality if you're on a free version

hope that helps,
Alana