Hi Alex,

Thanks for this very detailed and open answer! It’s great to see your thought process, and I’d love to share our perspective on these points.

1. The Importance of the "Production" Stage & SCA

To answer your rhetorical question about why ProGet's information matters: for us, the "Production" stage is actually the most critical one.

The main reason is SCA (Software Composition Analysis). ProGet is our source of truth for what is currently live. Having an accurate, reliable SCA report of what is actually in production is vital for our security and compliance teams. If a "backward" promotion happens by mistake in ProGet, it corrupts this data, and our production SCA reports become incorrect. That is the core driver behind my request: keeping the Production stage clean and trustworthy.

2. Specialized Tools vs. "All-in-One" Platforms (Siloed CI/CD)

You are absolutely right that we (like many others) will soon be consolidating data from various parts of our system to build a global, unified dashboard of our CI/CD pipeline, which is currently scattered across multiple tools.

However, even though "all-in-one" platform tools (like GitLab or GitHub) exist, they tend to do a little bit of everything but master none. They are generalists. We believe there will always be a need for highly specialized, robust tools like ProGet to act as the ultimate source of truth for packages and builds. That’s why we want ProGet's state to be as foolproof as possible.

3. The Complexity of "Pipelines" and "Releases"

Regarding your scrapped 2026 "build pipelines" feature: you made a very good point. Introducing a heavy "Release" concept might indeed go too far for ProGet and add unnecessary friction, especially since many organizations have complex scenarios (for instance, having multiple different versions of the same product running in production simultaneously). A rigid pipeline model makes this hard to represent.

This is why a simpler, "opinionated" safety guardrail—like just preventing backward promotion (or making stages "forward-only")—might be a lighter, more elegant way to solve the problem without over-engineering a full pipeline manager.

4. Let's Connect!

If you are interested, Alex, I would be more than happy to send you an email with more details about our tooling ecosystem, how we integrate ProGet, and what our workflows look like. It might help you "connect the dots" with real-world use cases as you think about the future of ProGet.

Let me know if you'd like that, and what the best email address would be to reach you!

Best regards,
Fabrice

Hi everyone,

I’d like to open a discussion regarding the Build Promotion feature in ProGet.

Currently, as far as I can see, ProGet allows users to promote a build from any stage to any stage. While this offers a lot of flexibility, it also introduces a significant risk: the ability to promote a build "backward" (i.e., downgrading or promoting to a lower stage/previous environment).

The Problem

In many workflows, build promotion should strictly be a one-way street (forward-only). If a team needs to reproduce a production bug, they might want to deploy/promote a specific older build to a non-production environment (like Staging or QA). However, because the tool allows promotion from any stage to any stage, there is a high risk of accidentally performing an unwanted promotion (such as pushing an older/wrong version into a higher pipeline stage by mistake, or mixing up the promotion flow).

Allowing backward promotion bypasses the logical progression of a standard release pipeline (e.g., Build ➔ Integration ➔ QA ➔ Production).

Proposed Evolution

I believe ProGet should offer an option (or a default behavior) to restrict build promotions to forward-only. Once a build reaches a certain stage, it should not be allowed to be promoted "backward" to a prior stage in the pipeline.

️ Crucially, this restriction should apply to both the Web UI and the API to ensure that automated scripts or manual actions cannot bypass this safety guardrail.

This would:

1. Prevent accidental misconfigurations or human errors during hotfixes and debugging phases.
2. Ensure strict adherence to the defined pipeline lifecycle.

What are your thoughts on this? How do you currently handle this risk in your pipelines, and would you find such a restriction useful in ProGet?

Looking forward to your feedback!

Hi,

In proget 2023 I was able to export all vulnerable packages :

SELECT
      [Package_Name]
	  ,[Package_Versions]
	  ,[Score]
	  ,[ScoreSeverity_Text]
	  ,[AssessmentType_Name]
	  ,'' as WillBeAssessTo
	  ,[Assessment_Date]
	  ,[BlockDownload_Indicator]
	  ,[Description_Text]
	  ,[External_Id]
	  ,[Feed_Id]
	  ,[FeedType_Name]
	  ,[Severity_Code]
	  ,[Title_Text]
	  ,[Vulnerability_Id]
	  ,[VulnerabilitySource_Id]
	  ,[VulnerabilitySource_Name]      
  FROM [ProGet].[dbo].[Vulnerabilities_Extended]
  where [FeedType_Name] = 'nuget'
  order by Score desc

now I just found this request but I don't have the version but just the AffectedVersions_Text:

SELECT
      ppne.[Package_Name]
	  ,ppne.AffectedVersions_Text	  
	  ,pve.Score
	  ,pve.ScoreSeverity_Text
	  ,pve.AssessmentType_Name
	  ,'' as WillBeAssessTo
	  ,pve.Assessment_Date
	  ,pve.Details_Text 
	  ,[External_Id]
	  ,ppne.PackageType_Name 
	  ,pve.Severity_Code
	  ,pve.Summary_Text 
	  ,pve.PgvdId_Text
	  ,pve.CveId_Text 
	  ,pve.BlockDownload_Indicator 
  FROM ProGet.dbo.PgvdPackageNames_Extended as ppne
inner join ProGet.dbo.PgvdVulnerabilities_Extended as pve on pve.Pgvd_Id = ppne.Pgvd_Id 
  where ppne.PackageType_Name = 'nuget'
  order by pve.Score desc

Have you got any idea on how to request it like I did before ?

Many thanks for your help.

Regards,

Fabrice MEJEAN

Hi @atripp,

You forgot the "pgutil builds sbom command" that could be run just to generate an sbom file. In our case we block downloads on deprecated packages and vulnerable ones too. It's faster to do a check before restoring packages instead having an issue on package restore.

This request is also related to this one Request for Creation of API for Package Auditing Before Dependency Restoration. This way you will probably better understand my request.

Regards,

Fabrice MEJEAN

Hello everyone,

I would like to propose an enhancement to the pgutil tool that specifically addresses the need for generating a Software Bill of Materials (SBOM) or listing packages from a .NET solution. Currently, pgutil does not support packages.lock.json files from NuGet, which makes it challenging to resolve dependencies before a build is executed.

Adding support for packages.lock.json would greatly enhance the capabilities of pgutil, making it a more powerful tool for managing .NET projects. Thank you for considering this request, and I look forward to your thoughts!

Best regards,

Fabrice MEJEAN

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

Custom Metadata Provider : https://docs.inedo.com/docs/proget/sca/policies?utm_source=proget&utm_medium=product&utm_campaign=proget24_0#oss-metadata-updating-caching

Hi,

I'm intrusted on how to create a Custom OSS provider. On the documentation you don't explain what is the expected format, if it's an API ...

Could you explain how to implement it correctly please ?

Regards,

Fabrice MÉJEAN

Hi @stevedennis,

I agree with your proposal; it should allow me to meet my current needs.

Regarding obsolescence management, unfortunately, the majority of open-source components do not manage obsolescence, let alone end-of-life dates. That is why we mark all packages older than 3 years as obsolete. This allows us to verify that the open-source project is still alive, and that in case of a vulnerability, we are still able to carry out a corrective version upgrade. I will certainly create another post about this soon, but it gives you something to think about.

I would appreciate a YouTrack reference to track this feature.

Thank you again.

Fabrice MÉJEAN

Hello @stevedennis ,

You raise a good point. Indeed, we should consider adding the 'feed' parameter, as the concept of obsolescence is tied to it. This begs the question of whether it should remain this way or if it should be managed more globally, similar to how vulnerabilities are handled. However, that would go beyond a simple API addition.

On the other hand, I am absolutely fine with making multiple calls to achieve my goals, as long as ProGet can handle the load.

Additionally, I would like to ask about the use of 'pgutil packages audit' and whether it indicates compliant or non-compliant. Does this status utilize all the rules (license, vulnerability, and others), and is there a plan to provide insights into the reasons behind the result? If it takes into account all the rules, then the 'other rules' are dependent on the feed, making the 'feed' parameter essential.

Thank you for your thoughts on this matter. Looking forward to your feedback!

Best regards,

Fabrice MEJEAN