Hi @fabrice-mejean , Thanks so much for the detailed information and offer to connect further! Very interested in that and I will definitely take you up on that :) Please give me a little time for that; I've got some travel coming up and then a bunch of other things... so I'd like to connect when I can really focus on some of these future things. . Cheers, Alex

Hi @fabrice-mejean , It's no longer possible to query this information from the database. As you've noticed, ProGet now uses a version range (i.e. AffectedVersions_Text ) to determine whether a package is vulnerable or not. So instead of 4.2.3 it's now 4.2.3-4.2.8 or [4.2.*) or something like that. Unfortunately it's not practical/feasible to parse this information unless you were to rewrite a substantial amount of ecosystem-specific parsing logic - this would be basically impossible to do in a SQL query. Instead, you'll need to use the upcoming pgutil packages meatdata command to see what vulnerabilities a particular packages has. You can also use Notifiers to address newly-discovered vulnerabilities. Thanks, Alana

Hi @fabrice-mejean , I definitely understand where you're coming from.... both commands basically work off the assets file, which is generated at build time. But your workflow is not common... the standard for SBOM generation is post-build. Doing it pre-build checking requires that packages.lock.json is used, which not many use... it's hard for us to advocate this workflow when most users don't care about saving time in this stage. I know we could add a "switch" or something to pgutil, but we learned "the hard way" that adding lots of complex alternative/branching paths to pgscan made for very difficult to maintain/understand code, so we want to keep the utility as simple as possible. Thanks, Alana

Oh ok, I was thinking that we could create a private metadata provider if we want deprecate our own packages without doing it on each feeds. So it will not help me. Thanks

Hi @pmsensi, Correct -- it'll be whatever data is on the "Dependencies" tab in ProGet, which is basically whatever is in the manifest file (.nuspec, etc). Thanks, Alana