Vulnerability scanning

sai.pabbareddy

I am evaluating enterprise. Real detection engine, but its database doesn't fully overlap with NVD/Trivy, and its client-facing warnings are a periodic snapshot rather than real-time (re-verified). Live blocking, separately, is real-time.
Coverage gap
Microsoft.Build.Tasks.Core 17.7.2 → CVE-2025-26646 (HIGH per NVD, already known from our existing Trivy-based scanning) was not present at all in ProGet's database. Re-confirmed with the same isolated, ProGet-only source.

atripp

Hi @sai.pabbareddy ,

I'm not really sure what question you're asking?

CVE-2025-26646 has been in Inedo's database as PGV-2535204 since May 13, 2025.

However, under the default risk profile in ProGet, we rate this a Category 1 since there is effectively no risk posed by this vulnerability. It requires a malicious inside actor with access to modify the source code -- which is not a realistic threat actor.

As such, ProGet will not not "spam" developers via the NuGet client with needless warnings. This is all by design.

You can learn more about that here: https://guides.inedo.com/vulnerability-management/categories/

Thanks,
Alana

sai.pabbareddy

Alana,

Thanks for the clarification on CVE-2025-26646/Category 1 — that answered our question completely.
Following up with two more things we ran into during the same Enterprise trial evaluation, since we're trying to understand whether these are also intentional design choices or worth reporting as bugs.

Severity rating disagreement vs. NVD

System.Drawing.Common 4.5.0 → CVE-2021-24112. When first flagged in our instance, ProGet rated this "Moderate". NVD (and Trivy, which we currently run alongside our existing pipeline) rate the same CVE "Critical".

Is ProGet's risk rating here based on an independent assessment (similar to the Category-1 reasoning you gave for CVE-2025-26646), or is it meant to track NVD's CVSS score directly and this looks like a data/sync issue? If it's an independent assessment, is there somewhere we can see the reasoning behind it, the way PGV-2535204's Category-1 write-up explained the reasoning for that one?

Client-facing vulnerability warning doesn't seem to update in real time

We changed the assessment on a specific vulnerability four times in a row (Contain → Monitor → Contain → Monitor), and re-ran a fully cache-cleared dotnet restore after each change. The NU1902 warning shown to the NuGet client did not change to reflect any of those updates — it stayed the same throughout.

Separately, we confirmed that the actual blocking behavior (packages failing to download once assessed Noncompliant, withAllowNoncompliantDownloads=false) does react immediately/in real time to the same assessment changes. So the disconnect seems specific to the advisory/warning channel, not the enforcement channel.

Is the client-facing NU1902 advisory feed generated on a schedule (e.g., alongside the daily vulnerability database sync) rather than reflecting live assessment state? If so, is there a way to force/trigger a regeneration, or a recommended interval to expect it to catch up on its own?

Context: we're doing a structured Enterprise trial evaluation and documenting exactly this kind of behavior so we can give an accurate internal recommendation — appreciate you taking the time on the first question, it directly changed a conclusion in our write-up.

Thanks,
Sai