Posts made by jens.viebig_4541

Thanks for the detailed answers, but this also contradicts your own recommendations from:

https://blog.inedo.com/inedo/recently-published-aged-packages-and-upcoming-proget-2026-changes

"Guideline: Block New and Warn for Aged
In general, we recommend blocking newly-published packages and creating exceptions for on a case-by-case basis when needed. This allows early adopters to find catastrophic failures, discover maliciously-published versions, and possibly even uncover other vulnerabilities/bugs as well.

However, we recommend warning for aged packages instead of blocking them. The main reason is that a developer is unlikely to choose an old version for a new project (which is where you’d want the download blocked), but a legacy application that suddenly can’t build will be headache to troubleshoot later. Note that you can always use vulnerability rules to ensure that vulnerable aged packages are still blocked."

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 ?

Hi,
i had already downloaded log4j-core with the "bad" version. I would have expected this to be an immediate action but as you described it is tied to a scheduled job triggered by vulnerability update.

Looking at the feed and packages today shows me that the auto assessment of all the downloaded packages was done overnight.

But does this mean the auto-blocking will never work the first time a package is downloaded? The auto blocking will always only kick in after the next vulnerability update ??

I hope that logic does not apply to the malicious package blocking as well...

We have a Proget Enterprise trial instance and are soon buying a license (ProGet Version 2025.23 (Build 11) (Docker/ Linux))

I wanted to test/evaluate the "Automatic Assessment" functionality
There seems to be a missing link in my setup and the documentation
I have the default assessment types which specifies and automatic assessment rule of setting vulnerabilities with score 9.0 -> 10.0 as Blocked

Now i have setup a maven feed, and downloaded log4j-core 2.14.1 which has a known vulnerability with score 10.0
I would have expected proget to set the assessment automatically to "Blocked" and block the download but it is shown as Unassessed and can be downloaded!

What am I missing ?

Screenshot 2026-04-21 145157.png