Block recently published - Metadata filter ?

[jens.viebig_4541]

Hi we have some trouble to configure an npm feed

We have a ProGet Enterprise instance up and running

In addition to the standard malicious package blocking feature of ProGet,
for npm I have set a policy to block packages which are just recently published on npmjs in the last 24-48 hours.
This policy would prevent most malicious packages even entering our system before they get discovered.
See also: https://veln.sh/blog/mean-time-to-detection-malicious-npm for common detection timelines

Why is only blocking discovered malicious packages not enough:
The standard malicious blocking from proget would only work after-the-fact when a package is officially detected as malicious, which also means, at that point they are also already removed online from the official repo. So that means this proget mechanism would only catch packages which were already used by us in builds/caches or dev environments which means we could already be compromised.

So why it sounds good in theory to block new packages for at least a day, there are some operational issues with this.
Unfortunately ProGet does not remove blocked packages from the repository metadata (P.S. Competitor Sonatype paid version does: https://help.sonatype.com/en/policy-compliant-component-selection.html). Which means that dependencies (or sub-dependencies of dependencies deep in the dependency tree) with are defined by version range could still try to use a new dependency version which is blocked and then fail.

This has already caused issues for our team causing errors consuming packages

How are others dealing with this ?
Are there plans to support metadata filtering for blocked packages ?

[apxltd]

Hi @jens-viebig_4541 ,

In very early versions of ProGet, we would filter specific versions from connectors (i.e. remote feeds/repositories) but it caused all sorts of problems due to client (i.e. npm, nuget, etc.) behavior and server API (npmjs.com, nuget.org) limitations. But the biggest problem was Developer Experience, and the fact that the behavior was simply befuddling.

When "random" versions suddenly go missing from the API, users will see a totally different dependency resolution result. Sometimes it would yield build failures.

Troubleshooting this is an pain in the ass, especially for those nested dependencies, since the client provides no useful information. They can see the versions of "their packages" are both in npmjs.com and ProGet. The end result is end users saying, dependency resolution with ProGet is broken, so we just use npmjs.com instead.

Long story short, I don't image we will return to filtering specific versions. It just causes more problems for everyone for no real benefit.

Addressing Malicious Packages

As for addressing malicious packages, this is simply a risk you have to accept. The question is how much Developer Experience you want to sacrifice to minimize the risk.

First, you really can't rely on malicious packages ever being discovered . I mean, just look at the XZ Utils (CVE-2024-3094) backdoor; that kind of code could be in any library you're using now. So, the first step has nothing to do with Malicious Packages... but it's to make sure all of your apps are deployed under a Minimally Viable Security Posture (MSVP) and track which dependencies go where using ProGet's SCA capabilities.

That said, if you do absolutely nothing, chances are you will be totally fine. As we wrote in Changes to Malicious Package Handling in 2025.20 and Beyond: the overwhelming majority of malicious packages are basically bot-created spam that no one will ever see, let alone use. These packages don’t rely on typos, but instead random, “package-sounding” names generated by some LLM.

In addition, Microsoft/GitHub seems to be undoing the braindead npm design descision to run arbitrary scripts at install time. I'm shocked that terrible idea survived this long. So, that will significantly reduce the attack vector, as developer machines can no longer be compromised by simply installing a package.

Noncompliance for Recently Published Packages

That said, the risk of harm caused by newly-published malicious packages pale in comparison to the real harm caused by regressions from constant upgrades. There's about a 0% chance of being harmed by a malicious package, but nearly a 100% chance of having problems when your developers always upgrade.

So, it's a good idea to say newly published packages (like 30 days, not 1 day) are noncompliant. You'll just need to figure out how to balance Developer Experience with that. We have a lot of options, from using Package Approval Workflows (pretty heavy handed) to allowing exceptions for single packages.

We do not recommend blocking noncompliant packages, especially for npm. Instead, use pgutil builds scan as discussed here: https://guides.inedo.com/vulnerability-management/containment/

I understand that pnpm has some kind of rule you can configure to not resolve "newer" dependencies. So you could just set that to like 31 days, and set ProGet's to like 29 days. Or 15 days, 14 days.

But a single day isn't going to do anything for you, except provide a false sense of security while maintaining the real risk of regressions from a "always upgrade" culture.

--

Finally... as for what Sonatype does, I'm skeptical. Based on the many customers that migrated from Nexus to ProGet, there's a rather large gap in advertised features and functionality, especially when it comes to stuff like this. Just taking a quick look, that feature looks defunct anyway and likely doesn't get much/any use.

Regardless, filtering versions from feeds causes problems than it solves, so it really doesn't make sense to do.

Hope that helps,

Alex