Hi @Ashley ,
Thanks for the detailed information. I haven't set up an npm/pnpm environment to test this, but I wanted to share a few thoughts, and see if you can test something.
I doubt the encoding is an issue.
Idea 1: Different API Endpoints
There are two vulnerability APIs, and I think one is kind of deprecated? Anyway ProGet has never implemented that one.
If you haven't already, I'd make sure pnpm is calling the same endpoint.
Idea 2: Null Severity
In the example you provided, severity is only set on one of the three items. If this is the problem, then it would mean that pnpm is erroring when processing the resultset.
This will be trivial to verify: can you (temporarily) override the assessment of PGV-262413Y and PGV-262413X to be Contain? Then, run it again. You should see a "critical" serverity in the results then.
That being said, this is a bug. These vulnerabilities should be suppressed and not show up in the results at all; we'll fix that via PG-3317.
Idea 3: Nonnumeric Id
The other possibility; ProGet is using a string identifier, but npm is using an integer identifier. I suspect that npm used to do CVEs that field, but who knows. None of this is documented.
I'm not really sure how how test this without some kind of proxy/MITM interception, or reverse-engineering their source code.
Maybe this is a GitHub issue on the pnpm repository?
Thanks,
Steve