pgutil doesn't support nuget lock files to generate sbom

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

atripp

Hi @fabrice-mejean,

Using packages.lock.json seemed to make the most sense to us too, but ultimately we decided not to use it for a few reasons.

First and foremost, none of the other .NET SBOM-generators seemed to use the packages.lock.json file. That's usually a sign that there's a "good reason" for us not to either.

From our perspective, pgutil builds scan is intended to be used in a CI environment, where dotnet build is run anyway and the assets file is already present. We don't have a use-case for an alternative workflow, where a build is not actually run.

In addition, packages.lock.json are still pretty niche and not widely used. You have to "go out of your way" to use it, and <PackageReference .../ > is by far the most common approach. It might be worth monitoring Issue #658 at CycloneDX/cyclonedx-dotnet to see anyone picks it up there.

Technically it's not all that complex to do, but it adds complexity and confusion... especially since most users will not be familiar with the differences between the lock and asset file. So it's not a good fit for pgutil builds scan.

HOWEVER, you could probably ~~write~~ ask ChatGPT to write a trivial PowerShell script that "Transforms" a lock file into a minimal SBOM document, and tweak it for what you want in ProGet. That same script could just upload the file to ProGet, or use pgutil as well.

Thanks,
Alana

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

atripp

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