@rhessinger Could you please review this pull request (or assign it to someone else)? We are transitioning to pnpm in response to the recent npm supply chain attacks. However, I noticed that pgutil currently does not recognize the dependency list with pnpm. I have added parsing support for pnpm-lock.yaml, similar to the existing package-lock.json parsing. I have tested these changes against several of our repositories and the results look good.

@dkimmich-onventis thanks for the PR! We didn't get a chance to review due to the short week last week (Thanksgiving), but we'll make sure to review this week!

My main hesitation here is this section:

            public static string Description => "Type of package to audit for vulnerabilities";
            public static string[] ValidValues => ["apk", "deb", "maven", "nuget", "conda", "cran", "helm", "npm", "pypi", "rpm", "gem", "pnpm"];
        }

In particular, lumping pnpm as a "Type of package". Maybe it's better to add as a flag or simply look for pnpm-lock.yaml and use that. I don't know, but we'll discuss!

@apxltd no problem, thanks for checking!

I added pnpm to that list because there is a mapping from the values of this list to the DependencyScannerType enum:

So I thought it makes sense to extend this list. I understand your hesitation, however I think this option is more a "type of package manager/format" than a "type of package".

Hi @dkimmich-onventis,

I just reviewed the code myself. As @apxltd mentioned, the biggest concern is adding pnpm as a package type, when it is really just npm. The package types in audit and the DependencyScannerType are meant to line up with package types and not tools.

The best way to handle this would be include the pnpm lock file in the NpmDependencyScanner and to trigger it to use the pnpm scanner code when the SourcePath.EndsWith("pnpm-lock.yaml"). Another option would be to add a property to CreateDependencyScannerArgs to trigger scanning for pnpm-lock.yaml files instead of package-lock.json files. We do a similar thing with NuGet when determining whether to use a .sln or a .slnx file.

The Auto Detection can also be used, but just pointing it to the npm scanner type and passing the direct lock file path as the source path.

Thanks,
Rich

Hi @dkimmich-onventis,

We discussed this as a team in our dev meeting today. We decided that we will handle making these changes based on your scanner. Once I have implemented the changes, I will reach out for you to review and test.

Thanks,
Rich

@rhessinger Thanks for the updates, sounds good!

Hi @dkimmich-onventis,

I'm going to close this pull request and continue it on PR #29. Please refer to comments on there.

Thanks,
Rich